diff --git a/runtime/agents/art-director.toml b/runtime/agents/art-director.toml index a57184e..65e1e2e 100644 --- a/runtime/agents/art-director.toml +++ b/runtime/agents/art-director.toml @@ -58,17 +58,16 @@ plain text. Follow the **Explain -> Capture** pattern: 1. **Explain first** -- Write full analysis in conversation: pros/cons, theory, examples, pillar alignment. 2. **Capture the decision** -- Use Codex `request_user_input` with concise labels and - short descriptions. User picks an option or uses the free-form Other path. + short descriptions. User picks an option or uses a free-form/custom option. **Codex `request_user_input` requirements:** - Ask 1-3 short questions per call. - Each question must include `header` (12 or fewer characters), `id` (snake_case), - `question` (one sentence), and 2-3 mutually exclusive options. + `question` (one sentence), and 2-5 mutually exclusive options. - Each option must include `label` (1-5 words) and `description` (one short sentence). - Add "(Recommended)" to your preferred option's label when you make a recommendation. -- Do not add an explicit Other option in Codex app runs; the client supplies the - free-form Other path. For app-server integrations, the equivalent free-form - option is represented by `isOther`. +- Use the full meaningful choice set when it fits within five options. +- Use a free-form/custom option when the decision benefits from custom input. - For open-ended questions or file-write confirmations, use conversation instead. - If running as a Codex custom-agent subagent, structure text so the orchestrator can present the decision through `request_user_input`. diff --git a/runtime/agents/creative-director.toml b/runtime/agents/creative-director.toml index 6aeabdf..ff06bf8 100644 --- a/runtime/agents/creative-director.toml +++ b/runtime/agents/creative-director.toml @@ -158,13 +158,12 @@ Follow the **Explain → Capture** pattern: **Codex `request_user_input` requirements:** - Ask 1-3 short questions per call. - Each question must include `header` (12 or fewer characters), `id` (snake_case), - `question` (one sentence), and 2-3 mutually exclusive options. + `question` (one sentence), and 2-5 mutually exclusive options. - Each option must include `label` (1-5 words) and `description` (one short sentence with the key trade-off). - Add "(Recommended)" to your preferred option's label when you make a recommendation. -- Do not add an explicit Other option in Codex app runs; the client supplies the - free-form Other path. For app-server integrations, the equivalent free-form - option is represented by `isOther`. +- Use the full meaningful choice set when it fits within five options. +- Use a free-form/custom option when the decision benefits from custom input. - For open-ended context gathering, use conversation instead. - If running as a Codex custom-agent subagent, structure text so the orchestrator can present the decision through `request_user_input`. diff --git a/runtime/agents/producer.toml b/runtime/agents/producer.toml index a0e2bdd..597411b 100644 --- a/runtime/agents/producer.toml +++ b/runtime/agents/producer.toml @@ -63,13 +63,12 @@ Follow the **Explain → Capture** pattern: **Codex `request_user_input` requirements:** - Ask 1-3 short questions per call. - Each question must include `header` (12 or fewer characters), `id` (snake_case), - `question` (one sentence), and 2-3 mutually exclusive options. + `question` (one sentence), and 2-5 mutually exclusive options. - Each option must include `label` (1-5 words) and `description` (one short sentence with the key trade-off). - Add "(Recommended)" to your preferred option's label when you make a recommendation. -- Do not add an explicit Other option in Codex app runs; the client supplies the - free-form Other path. For app-server integrations, the equivalent free-form - option is represented by `isOther`. +- Use the full meaningful choice set when it fits within five options. +- Use a free-form/custom option when the decision benefits from custom input. - For open-ended context gathering, use conversation instead. - If running as a Codex custom-agent subagent, structure text so the orchestrator can present the decision through `request_user_input`. diff --git a/runtime/agents/technical-director.toml b/runtime/agents/technical-director.toml index 3f868e1..6861a4c 100644 --- a/runtime/agents/technical-director.toml +++ b/runtime/agents/technical-director.toml @@ -63,13 +63,12 @@ Follow the **Explain → Capture** pattern: **Codex `request_user_input` requirements:** - Ask 1-3 short questions per call. - Each question must include `header` (12 or fewer characters), `id` (snake_case), - `question` (one sentence), and 2-3 mutually exclusive options. + `question` (one sentence), and 2-5 mutually exclusive options. - Each option must include `label` (1-5 words) and `description` (one short sentence with the key trade-off). - Add "(Recommended)" to your preferred option's label when you make a recommendation. -- Do not add an explicit Other option in Codex app runs; the client supplies the - free-form Other path. For app-server integrations, the equivalent free-form - option is represented by `isOther`. +- Use the full meaningful choice set when it fits within five options. +- Use a free-form/custom option when the decision benefits from custom input. - For open-ended context gathering, use conversation instead. - If running as a Codex custom-agent subagent, structure text so the orchestrator can present the decision through `request_user_input`. diff --git a/skills/brainstorm/DETAILS.md b/skills/brainstorm/DETAILS.md index 39bf1cb..9e3902e 100644 --- a/skills/brainstorm/DETAILS.md +++ b/skills/brainstorm/DETAILS.md @@ -31,16 +31,19 @@ When this skill is invoked: Codex structured input requirements: - Ask 1-3 short questions per `request_user_input` call. - Each question must include `header` (12 or fewer characters), `id` (snake_case), - `question` (one sentence), and 2-3 mutually exclusive `options`. + `question` (one sentence), and 2-5 mutually exclusive `options`. - Each option must include `label` (1-5 words) and `description` (one short sentence). - Put the recommended option first and suffix its label with `(Recommended)` when there is a recommendation. - - Do not add an explicit `Other` option in Codex app runs; the client supplies the - free-form Other path. For app-server integrations, the equivalent free-form - option is represented by `isOther`. - - If a choice list has more than 3 useful options, split it into a first - 2-3 option category question plus a follow-up `request_user_input` call, - or rely on the Codex free-form Other path for uncommon cases. + - Prefer the full studio choice set when it has 4-5 meaningful options. + Do not compress `Relaxation & Flow`, `Multi-year`, `Generate fresh + directions`, `Combine elements`, `Rename/reframe`, or similar expressive + choices into a generic fallback. + - Use a free-form escape such as `I'll describe it` or `Something else` + when the choice benefits from custom input. For app-server integrations, + represent that escape with the runtime's free-form option support. + - Only split a choice into follow-up questions when it would exceed 5 options + or when the answer naturally needs a second, more precise question. Professional studio brainstorming principles to follow: - Withhold judgment — no idea is bad during exploration @@ -69,7 +72,8 @@ conversationally (not as a checklist): - Are there genres you love? Genres you avoid? Why? - Do you prefer games that challenge you, relax you, tell you stories, or let you express yourself? *(Use `request_user_input` for this — constrained choice. - Use 2-3 grouped options plus Codex's free-form Other path.)* + Preserve the four distinct choices: challenge, story/discovery, expression, + and relaxation/flow.)* **Practical constraints** (shape the sandbox before brainstorming). Bundle these into one Codex `request_user_input` call with three questions: @@ -82,9 +86,10 @@ Bundle these into one Codex `request_user_input` call with three questions: "id": "target_experience", "question": "What kind of experience do you most want players to have?", "options": [ - {"label": "Challenge", "description": "Players seek mastery, pressure, and earned wins."}, - {"label": "Story", "description": "Players seek discovery, drama, and authored moments."}, - {"label": "Expression", "description": "Players seek creativity, agency, or relaxed flow."} + {"label": "Challenge & Mastery", "description": "Players seek mastery, pressure, and earned wins."}, + {"label": "Story & Discovery", "description": "Players seek discovery, drama, and authored moments."}, + {"label": "Expression & Creativity", "description": "Players seek creativity, agency, or self-authorship."}, + {"label": "Relaxation & Flow", "description": "Players seek comfort, flow, and low-pressure immersion."} ] }, { @@ -94,7 +99,8 @@ Bundle these into one Codex `request_user_input` call with three questions: "options": [ {"label": "Weeks", "description": "A jam-scale prototype or tiny polished game."}, {"label": "Months", "description": "A focused indie scope with selective polish."}, - {"label": "1+ years", "description": "A larger project that needs strong scope control."} + {"label": "1-2 years", "description": "A larger project that needs strong scope control."}, + {"label": "Multi-year", "description": "A long production that needs milestones and strict risk control."} ] }, { @@ -104,14 +110,15 @@ Bundle these into one Codex `request_user_input` call with three questions: "options": [ {"label": "First game", "description": "Keep systems simple and learning-friendly."}, {"label": "Shipped before", "description": "Use moderate scope and proven patterns."}, - {"label": "Professional", "description": "Assume stronger production and technical context."} + {"label": "Professional background", "description": "Assume stronger production and technical context."} ] } ] } ``` -Do not use tabs or more than three options per question in Codex. +Use these three question headers as the Codex-native equivalent of the original +multi-tab form. Do not rename or duplicate them. **Synthesize** the answers into a **Creative Brief** — a 3-5 sentence summary of the person's emotional goals, taste profile, and constraints. @@ -151,9 +158,9 @@ For each concept, present: Present all three. Then use Codex `request_user_input` to capture the selection. -**CRITICAL**: Codex `request_user_input` only supports 1-3 short questions and -2-3 options per question. Do not use tabs, form fields, or a 5-option list. -Use exactly this shape: +Use a single plain choice question with all five decision paths. Do not split +the three concepts from `Combine elements` and `Generate fresh directions`; +those two choices are part of the creative selection moment. ```json { @@ -161,29 +168,19 @@ Use exactly this shape: { "header": "Concept", "id": "concept_choice", - "question": "Which concept is the strongest starting point?", + "question": "Which concept resonates with you? You can pick one, combine elements, or ask for fresh directions.", "options": [ {"label": "Concept 1", "description": "[Title] — [one-line reason it fits]."}, {"label": "Concept 2", "description": "[Title] — [one-line reason it fits]."}, - {"label": "Concept 3", "description": "[Title] — [one-line reason it fits]."} - ] - }, - { - "header": "Next move", - "id": "concept_next_move", - "question": "How should we proceed with that direction?", - "options": [ - {"label": "Develop it", "description": "Use the selected concept as the foundation."}, - {"label": "Combine", "description": "Blend the selected concept with elements from another."}, - {"label": "Fresh set", "description": "Generate three new directions from the brief."} + {"label": "Concept 3", "description": "[Title] — [one-line reason it fits]."}, + {"label": "Combine elements", "description": "Blend elements across concepts."}, + {"label": "Generate fresh directions", "description": "Generate three new directions from the brief."} ] } ] } ``` -If the user wants a custom blend, use the Codex free-form Other path. - Never pressure toward a choice — let them sit with it. --- @@ -199,9 +196,9 @@ isolation, no amount of content or polish will save the game. Ask these with Codex `request_user_input` — derive the options from the chosen concept, don't hardcode them: -1. **Core action feel** — prompt: "What's the primary feel of the core action?" Generate exactly 2-3 options that fit the concept's genre and tone. Use the Codex free-form Other path for custom answers. +1. **Core action feel** — prompt: "What's the primary feel of the core action?" Generate 3-4 options that fit the concept's genre and tone, plus a free-text escape such as `I'll describe it`. -2. **Key design dimension** — identify the most important design variable for this specific concept (e.g., world reactivity, pacing, player agency) and ask about it. Generate exactly 2-3 options that match the concept. Use the Codex free-form Other path for custom answers. +2. **Key design dimension** — identify the most important design variable for this specific concept (e.g., world reactivity, pacing, player agency) and ask about it. Generate options that match the concept. Always include a free-text escape. After capturing answers, analyze: Is this action intrinsically satisfying? What makes it feel good? (Audio feedback, visual juice, timing satisfaction, tactical depth?) @@ -248,12 +245,12 @@ Then define **3+ anti-pillars** (what this game is NOT): **Pillar confirmation**: After presenting the full pillar set, use Codex `request_user_input`: - Prompt: "Do these pillars feel right for your game?" -- Options: `[A] Lock these in` / `[B] Revise one` / `[C] Discuss further` +- Options: `[A] Lock these in` / `[B] Rename or reframe one` / `[C] Swap a pillar out` / `[D] Something else` -If the user selects B or C, make the revision or discuss the concern, then use +If the user selects B, C, or D, make the revision, then use Codex `request_user_input` again: - Prompt: "Pillars updated. Ready to lock these in?" -- Options: `[A] Lock these in` / `[B] Revise another` / `[C] Discuss further` +- Options: `[A] Lock these in` / `[B] Revise another pillar` / `[C] Something else` Repeat until the user selects [A] Lock these in. @@ -272,8 +269,8 @@ Repeat until the user selects [A] Lock these in. Collect both verdicts, then present them together using one Codex `request_user_input` call with up to two questions: -- Question **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in` / `Revise one` / `Discuss`. -- Question **"Visual"**: present the art-director's 2-3 named visual direction options. If there are three named directions, use those three options and rely on the Codex free-form Other path for combine/custom answers. If there are only two named directions, use those two plus `Combine`. +- Question **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in as-is` / `Revise [specific pillar]` / `Discuss further`. +- Question **"Visual"**: present the art-director's 2-3 named visual direction options. Options: each named direction (one per option) + `Combine elements across directions` + `Describe my own direction`. The user's selected visual anchor (the named direction or their custom description) is stored as the **Visual Identity Anchor** — it will be written into the game-concept document and becomes the foundation of the art bible. @@ -301,12 +298,12 @@ who this game is actually for: Ground the concept in reality: - **Target platform**: Use Codex `request_user_input` — "What platforms are you targeting for this game?" - Options: `PC` / `Mobile` / `Console/Web`. Use the Codex free-form Other path for multiple platforms or a specific store target. + Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms` Record the answer — it directly shapes the engine recommendation and will be passed to `$setup-engine`. Note platform implications if relevant (e.g., mobile means Unity is strongly preferred; console means Godot has limitations; web means Godot exports cleanly). - **Engine experience**: Use Codex `request_user_input` — "Do you already have an engine you work in?" - Options: `Godot` / `Unity` / `Unreal`. Use the Codex free-form Other path for "No preference" or another engine. + Options: `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide` - If they pick an engine → record it as their preference and move on. Do NOT second-guess it. - If "No preference" → tell them: "Run `$setup-engine` after this session — it will walk you through the full decision based on your concept and platform target." Do not make a recommendation here. - **Art pipeline**: What's the art style and how labor-intensive is it? @@ -358,10 +355,11 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi - Prompt: "Game concept is ready. May I write it to `design/gdd/game-concept.md`?" - Options: `[A] Yes — write it` / `[B] Not yet — revise a section first` -If [B]: ask which area to revise using Codex `request_user_input` with 2-3 -category options such as `Identity`, `Loop`, and `Scope/Risks`, then ask a -follow-up question if the category needs narrowing. Use the Codex free-form -Other path for a custom section. +If [B]: ask which section to revise using Codex `request_user_input` with up to +five options at a time. Start with: +`Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / +`MVP, Scope, or Risks`. If the user chooses the final grouped option, ask a +follow-up with `MVP Definition` / `Scope Tiers` / `Risks` / `Something else`. After revising, show the updated section as a diff or clear before/after, then use Codex `request_user_input` — "Ready to write the updated concept document?" Options: `[A] Yes — write it` / `[B] Revise another section` diff --git a/skills/setup-engine/DETAILS.md b/skills/setup-engine/DETAILS.md index fa314ba..4c0cfa5 100644 --- a/skills/setup-engine/DETAILS.md +++ b/skills/setup-engine/DETAILS.md @@ -13,10 +13,12 @@ Codex structured input requirements: short questions conversationally and wait for the user's reply. - Ask 1-3 short questions per call. - Each question must have `header` (12 or fewer characters), `id` in snake_case, - a one-sentence `question`, and 2-3 mutually exclusive options. + a one-sentence `question`, and 2-5 mutually exclusive options. - Each option must have a 1-5 word `label` and one short `description`. - Put the recommended option first and suffix its label with `(Recommended)`. -- Do not add an explicit Other option; the Codex app supplies the free-form path. +- Use the full meaningful choice set when it fits within five options. Do not + split engine, platform, or tradeoff choices merely to force three options. +- Use a free-form/custom option when the decision benefits from custom input. - For open-ended values such as exact game descriptions or custom constraints, ask conversationally instead of forcing a multiple-choice form. @@ -84,10 +86,7 @@ If no engine is specified, run an interactive engine selection process: **Question 1 — Prior experience** (ask this first, always, via Codex `request_user_input`): - Prompt: "Have you worked in any of these engines before?" -- Because Codex choice inputs support 2-3 options per question, split this into - one or two questions: - - First ask `I know one engine` / `I know several` / `No prior engine experience`. - - If they know one engine, ask which: `Godot` / `Unity` / `Unreal Engine 5`. +- Options: `Godot` / `Unity` / `Unreal Engine 5` / `I know several` / `No prior engine experience` - If they pick a specific engine → recommend that engine. Prior experience outweighs all other factors. Confirm with them and skip the matrix. - If "None" or "Multiple" → continue to the questions below. @@ -95,9 +94,7 @@ If no engine is specified, run an interactive engine selection process: **Question 2 — Target platform** (ask this second, always, via Codex `request_user_input` — platform eliminates or heavily weights engines before any other factor): - Prompt: "What platforms are you targeting for this game?" -- Split into 2-3 options per call when needed. For example, ask: - `PC or console` / `Mobile` / `Web or mixed`, then ask a follow-up if the - answer needs more precision. +- Options: `PC` / `Mobile` / `Console` / `Web` / `Multiple platforms` - Platform rules that feed directly into the recommendation: - Mobile → Unity strongly preferred; Unreal is a poor fit; Godot is viable for simple mobile - Console → Unity or Unreal; Godot console support requires third-party publishers or significant extra work @@ -153,11 +150,11 @@ Do NOT use a simple scoring matrix that eliminates engines. Instead, reason thro 3. Name the best alternative and when to choose it instead 4. Explicitly state: "This is a starting point, not a verdict — you can always switch engines between projects." 5. Use Codex `request_user_input` to confirm: "Does this recommendation feel right, or would you like to explore a different engine?" - - Keep the first call to 2-3 options, e.g. `[Primary engine] (Recommended)` / `[Alternative engine]` / `Explore further`. - - If the user wants the third engine or a custom route, handle that as a follow-up conversationally. + - Include the primary engine, best alternative, remaining third engine when relevant, and `Explore further` when the tradeoffs need discussion. + - Keep the recommendation first and mark it with `(Recommended)`. **If the user picks "Explore further":** -Use Codex `request_user_input` with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Split topics across multiple calls if more than three options are useful. Always include at minimum: +Use Codex `request_user_input` with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Use up to five options. Always include at minimum: - The primary engine's specific limitations for this concept (e.g., "How far can Godot 3D actually go for [genre]?") - The alternative engine's specific tradeoffs for this concept - Language choice impact on this concept's technical challenges