Back to Details

brainstorm

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
When this skill is invoked:
  1. Parse the argument for an optional genre/theme hint (e.g., 
    roguelike
    , 
    space survival
    , 
    cozy farming
    ). If 
    open
    or no argument, start from scratch. Also resolve the review mode (once, store for all gate spawns this run):
    1. If 
      --review [full|lean|solo]
      was passed → use that
    2. Else read 
      production/review-mode.txt
      → use that value
    3. Else → default to 
      lean
    See 
    .claude/docs/director-gates.md
    for the full check pattern.
  2. Check for existing concept work:
    • Read 
      design/gdd/game-concept.md
      if it exists (resume, don't restart)
    • Read 
      design/gdd/game-pillars.md
      if it exists (build on established pillars)
  3. Run through ideation phases interactively, asking the user questions at each phase. Do NOT generate everything silently — the goal is collaborative exploration where the AI acts as a creative facilitator, not a replacement for the human's vision.
    Use 
    AskUserQuestion
     at key decision points throughout brainstorming:
    • Constrained taste questions (genre preferences, scope, team size)
    • Concept selection ("Which 2-3 concepts resonate?") after presenting options
    • Direction choices ("Develop further, explore more, or prototype?")
    • Pillar ranking after concepts are refined Write full creative analysis in conversation text first, then use 
      AskUserQuestion
      to capture the decision with concise labels.
    Professional studio brainstorming principles to follow:
    • Withhold judgment — no idea is bad during exploration
    • Encourage unusual ideas — outside-the-box thinking sparks better concepts
    • Build on each other — "yes, and..." responses, not "but..."
    • Use constraints as creative fuel — limitations often produce the best ideas
    • Time-box each phase — keep momentum, don't over-deliberate early
调用此Skill时：
  1. 解析参数，获取可选的类型/主题提示（例如 
    roguelike
    、
    space survival
    、
    cozy farming
    ）。如果参数为
    open
    或无参数，则从零开始构思。同时确定评审模式（本次运行中所有关卡生成均使用该模式）：
    1. 如果传入
      --review [full|lean|solo]
      → 使用该指定模式
    2. 否则读取
      production/review-mode.txt
      → 使用该文件中的值
    3. 否则 → 默认使用
      lean
      模式
    完整的检查规则请参见
    .claude/docs/director-gates.md
    。
  2. 检查现有概念成果：
    • 若
      design/gdd/game-concept.md
      文件存在则读取（继续构思，不重新开始）
    • 若
      design/gdd/game-pillars.md
      文件存在则读取（基于已确立的核心支柱进行拓展）
  3. 交互式完成构思阶段，在每个阶段向用户提问。请勿静默生成所有内容——目标是协作式探索，AI扮演创意引导者的角色，而非替代人类的创意愿景。
    在头脑风暴的关键决策点使用
    AskUserQuestion
    ：
    • 约束性偏好问题（类型偏好、项目范围、团队规模）
    • 概念选择（展示选项后询问“哪2-3个概念最能引起你的共鸣？”）
    • 方向选择（“深入开发、探索更多方向，还是制作原型？”）
    • 概念细化后的支柱排序 先在对话文本中撰写完整的创意分析，再使用
      AskUserQuestion
      以简洁标签记录决策。
    需遵循的专业工作室头脑风暴原则：
    • 暂缓评判——探索阶段没有糟糕的想法
    • 鼓励新奇想法——跳出常规的思考能催生更好的概念
    • 互相启发——采用“是的，而且……”的回应方式，而非“但是……”
    • 将约束转化为创意动力——限制条件往往能催生最佳创意
    • 为每个阶段设定时间限制——保持节奏，早期阶段不要过度纠结

Phase 1: Creative Discovery

第一阶段：创意探索

Start by understanding the person, not the game. Ask these questions conversationally (not as a checklist):
Emotional anchors:
  • What's a moment in a game that genuinely moved you, thrilled you, or made you lose track of time? What specifically created that feeling?
  • Is there a fantasy or power trip you've always wanted in a game but never quite found?
Taste profile:
  • What 3 games have you spent the most time with? What kept you coming back? (Ask this as plain text — the user must be able to type specific game names freely. Do NOT put this in an AskUserQuestion with preset options.)
  • 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 
    AskUserQuestion
    for this — constrained choice.)
Practical constraints (shape the sandbox before brainstorming). Bundle these into a single multi-tab 
AskUserQuestion
with these exact tab labels:
  • Tab "Experience" — "What kind of experience do you most want players to have?" (Challenge & Mastery / Story & Discovery / Expression & Creativity / Relaxation & Flow)
  • Tab "Timeline" — "What's your realistic development timeline?" (Weeks / Months / 1-2 years / Multi-year)
  • Tab "Dev level" — "Where are you in your dev journey?" (First game / Shipped before / Professional background)
Use exactly these tab names — 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. Read the brief back and confirm it captures their intent.
首先了解创作者，而非直接构思游戏。以对话方式提出以下问题（不要用清单形式）：
情感锚点：
  • 游戏中有没有哪个时刻真正打动你、让你兴奋不已或沉浸其中无法自拔？具体是什么带来了这种感受？
  • 有没有一种幻想或爽点是你一直想在游戏中体验，但始终没找到的？
偏好画像：
  • 你投入时间最多的3款游戏是什么？是什么让你反复游玩？ （以纯文本形式提问——用户必须能够自由输入具体游戏名称。请勿将此问题放入带有预设选项的
    AskUserQuestion
    中。）
  • 你喜欢哪些游戏类型？避开哪些类型？原因是什么？
  • 你更喜欢具有挑战性、休闲放松、讲述故事还是能让你自由表达的游戏？（使用
    AskUserQuestion
    提问——提供限定选项。）
实际约束（在头脑风暴前划定范围）。将这些问题整合到一个多标签页的
AskUserQuestion
中，标签页名称必须严格如下：
  • 标签页"Experience"——“你最希望玩家获得什么样的体验？”（挑战与精通 / 故事与探索 / 表达与创意 / 放松与心流）
  • 标签页"Timeline"——“你实际的开发时间线是怎样的？”（数周 / 数月 / 1-2年 / 多年）
  • 标签页"Dev level"——“你的开发处于什么阶段？”（首次开发游戏 / 已发布过作品 / 专业开发背景）
必须使用上述标签页名称——不得重命名或重复。
整合答案，形成一份创意简报——3-5句话总结创作者的情感目标、偏好画像和约束条件。向创作者复述简报并确认是否准确传达了他们的意图。

Phase 2: Concept Generation

第二阶段：概念生成

Using the creative brief as a foundation, generate 3 distinct concepts that each take a different creative direction. Use these ideation techniques:
Technique 1: Verb-First Design Start with the core player verb (build, fight, explore, solve, survive, create, manage, discover) and build outward from there. The verb IS the game.
Technique 2: Mashup Method Combine two unexpected elements: [Genre A] + [Theme B]. The tension between the two creates the unique hook. (e.g., "farming sim + cosmic horror", "roguelike + dating sim", "city builder + real-time combat")
Technique 3: Experience-First Design (MDA Backward) Start from the desired player emotion (aesthetic goal from MDA framework: sensation, fantasy, narrative, challenge, fellowship, discovery, expression, submission) and work backward to the dynamics and mechanics that produce it.
For each concept, present:
  • Working Title
  • Elevator Pitch (1-2 sentences — must pass the "10-second test")
  • Core Verb (the single most common player action)
  • Core Fantasy (the emotional promise)
  • Unique Hook (passes the "and also" test: "Like X, AND ALSO Y")
  • Primary MDA Aesthetic (which emotion dominates?)
  • Estimated Scope (small / medium / large)
  • Why It Could Work (1 sentence on market/audience fit)
  • Biggest Risk (1 sentence on the hardest unanswered question)
Present all three. Then use 
AskUserQuestion
to capture the selection.
CRITICAL: This MUST be a plain list call — no tabs, no form fields. Use exactly this structure:
AskUserQuestion(
  prompt: "Which concept resonates with you? You can pick one, combine elements, or ask for fresh directions.",
  options: [
    "Concept 1 — [Title]",
    "Concept 2 — [Title]",
    "Concept 3 — [Title]",
    "Combine elements across concepts",
    "Generate fresh directions"
  ]
)
Do NOT use a 
tabs
field here. The 
tabs
form is for multi-field input only — using it here causes an "Invalid tool parameters" error. This is a plain 
prompt
+ 
options
call.
Never pressure toward a choice — let them sit with it.
以创意简报为基础，生成3个截然不同的概念，每个概念采用不同的创意方向。使用以下构思技巧：
技巧1：动词优先设计 从核心玩家动作动词（建造、战斗、探索、解谜、生存、创造、管理、发现）入手，向外拓展。动词就是游戏的核心。
技巧2：混搭法 结合两个意想不到的元素：[类型A] + [主题B]。两者之间的张力形成独特的吸引力。（例如：“农场模拟 + 克苏鲁恐怖”、“roguelike + 恋爱模拟”、“城市建造 + 实时战斗”）
技巧3：体验优先设计（逆向MDA） 从期望的玩家情感出发（MDA框架中的美学目标：感官刺激、幻想、叙事、挑战、社交、探索、表达、顺从），反向推导产生该情感的动态机制和玩法。
每个概念需包含：
  • 暂定标题
  • 电梯游说（1-2句话——必须通过“10秒测试”）
  • 核心动词（玩家最常执行的单一动作）
  • 核心幻想（情感承诺）
  • 独特吸引力（通过“而且还有”测试：“像X游戏，而且还有Y元素”）
  • 主要MDA美学（哪种情感占主导？）
  • 预估范围（小型 / 中型 / 大型）
  • 可行性分析（1句话说明市场/受众适配性）
  • 最大风险（1句话说明最棘手的未解决问题）
展示所有三个概念。然后使用
AskUserQuestion
记录用户的选择。
重要提示：此处必须使用纯列表调用——不得使用标签页或表单字段。严格使用以下结构：
AskUserQuestion(
  prompt: "哪个概念最能引起你的共鸣？你可以选择一个、融合多个概念的元素，或者要求生成新方向。",
  options: [
    "Concept 1 — [Title]",
    "Concept 2 — [Title]",
    "Concept 3 — [Title]",
    "Combine elements across concepts",
    "Generate fresh directions"
  ]
)
请勿在此处使用
tabs
字段。
tabs
表单仅用于多字段输入——在此处使用会导致“无效工具参数”错误。这是一个纯
prompt
+ 
options
调用。
切勿催促用户做出选择——让他们充分考虑。

Phase 3: Core Loop Design

第三阶段：核心循环设计

For the chosen concept, use structured questioning to build the core loop. The core loop is the beating heart of the game — if it isn't fun in isolation, no amount of content or polish will save the game.
30-Second Loop (moment-to-moment):
Ask these as 
AskUserQuestion
calls — 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 3-4 options that fit the concept's genre and tone, plus a free-text escape (
    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 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?)
5-Minute Loop (short-term goals):
  • What structures the moment-to-moment play into cycles?
  • Where does "one more turn" / "one more run" psychology kick in?
  • What choices does the player make at this level?
Session Loop (30-120 minutes):
  • What does a complete session look like?
  • Where are the natural stopping points?
  • What's the "hook" that makes them think about the game when not playing?
Progression Loop (days/weeks):
  • How does the player grow? (Power? Knowledge? Options? Story?)
  • What's the long-term goal? When is the game "done"?
Player Motivation Analysis (based on Self-Determination Theory):
  • Autonomy: How much meaningful choice does the player have?
  • Competence: How does the player feel their skill growing?
  • Relatedness: How does the player feel connected (to characters, other players, or the world)?
针对选定的概念，通过结构化提问构建核心循环。核心循环是游戏的心脏——如果单独体验时毫无乐趣，再多的内容或打磨也无法挽救游戏。
30秒循环（即时体验）：
以
AskUserQuestion
调用形式提出以下问题——根据选定的概念生成选项，不要硬编码：
  1. 核心动作手感——提示：“核心动作的主要手感是什么？”生成3-4个符合概念类型和风格的选项，外加一个自由文本选项（
    我来描述
    ）。
  2. 关键设计维度——确定该特定概念最重要的设计变量（例如：世界反应性、节奏、玩家自主性）并询问相关问题。生成与概念匹配的选项。始终包含自由文本选项。
收集答案后进行分析：这个动作本身是否令人满足？是什么让它感觉良好？（音频反馈、视觉效果、时机把控、战术深度？）
5分钟循环（短期目标）：
  • 是什么将即时体验划分为循环周期？
  • “再来一局”/“再来一轮”的心理效应在何处体现？
  • 玩家在此层面会做出哪些选择？
会话循环（30-120分钟）：
  • 完整的游戏会话是什么样的？
  • 自然的暂停点在哪里？
  • 是什么“钩子”让玩家在不玩游戏时也会想起它？
成长循环（数天/数周）：
  • 玩家如何成长？（实力？知识？选择？故事？）
  • 长期目标是什么？游戏何时“完成”？
玩家动机分析（基于自我决定理论）：
  • 自主性：玩家拥有多少有意义的选择？
  • 胜任感：玩家如何感受到自己技能的提升？
  • 关联性：玩家如何感受到与角色、其他玩家或游戏世界的联系？

Phase 4: Pillars and Boundaries

第四阶段：核心支柱与边界

Game pillars are used by real AAA studios (God of War, Hades, The Last of Us) to keep hundreds of team members making decisions that all point the same direction. Even for solo developers, pillars prevent scope creep and keep the vision sharp.
Collaboratively define 3-5 pillars:
  • Each pillar has a name and one-sentence definition
  • Each pillar has a design test: "If we're debating between X and Y, this pillar says we choose __"
  • Pillars should feel like they create tension with each other — if all pillars point the same way, they're not doing enough work
Then define 3+ anti-pillars (what this game is NOT):
  • Anti-pillars prevent the most common form of scope creep: "wouldn't it be cool if..." features that don't serve the core vision
  • Frame as: "We will NOT do [thing] because it would compromise [pillar]"
Pillar confirmation: After presenting the full pillar set, use 
AskUserQuestion
:
  • Prompt: "Do these pillars feel right for your game?"
  • Options: 
    [A] Lock these in
    / 
    [B] Rename or reframe one
    / 
    [C] Swap a pillar out
    / 
    [D] Something else
If the user selects B, C, or D, make the revision, then use 
AskUserQuestion
again:
  • Prompt: "Pillars updated. Ready to lock these in?"
  • Options: 
    [A] Lock these in
    / 
    [B] Revise another pillar
    / 
    [C] Something else
Repeat until the user selects [A] Lock these in.
Review mode check — apply before spawning CD-PILLARS and AD-CONCEPT-VISUAL:
  • solo
    → skip both. Note: "CD-PILLARS skipped — Solo mode. AD-CONCEPT-VISUAL skipped — Solo mode." Proceed to Phase 5.
  • lean
    → skip both (not PHASE-GATEs). Note: "CD-PILLARS skipped — Lean mode. AD-CONCEPT-VISUAL skipped — Lean mode." Proceed to Phase 5.
  • full
    → spawn as normal.
After pillars and anti-pillars are agreed, spawn BOTH 
creative-director
AND 
art-director
via Task in parallel before moving to Phase 5. Issue both Task calls simultaneously — do not wait for one before starting the other.
  • creative-director
     — gate CD-PILLARS (
    .claude/docs/director-gates.md
    ) Pass: full pillar set with design tests, anti-pillars, core fantasy, unique hook.
  • art-director
     — gate AD-CONCEPT-VISUAL (
    .claude/docs/director-gates.md
    ) Pass: game concept elevator pitch, full pillar set with design tests, target platform (if known), any reference games or visual touchstones the user mentioned.
Collect both verdicts, then present them together using a two-tab 
AskUserQuestion
:
  • Tab "Pillars": present creative-director feedback. Options mirror the standard CD-PILLARS handling — 
    Lock in as-is
    / 
    Revise [specific pillar]
    / 
    Discuss further
    .
  • Tab "Visual anchor": 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.
If the creative-director returns CONCERNS or REJECT on pillars, resolve pillar issues before asking for the visual anchor selection — visual direction should flow from confirmed pillars.
游戏核心支柱被真正的AAA工作室（如《战神》、《哈迪斯》、《最后生还者》）用于确保数百名团队成员的决策方向一致。即使是独立开发者，核心支柱也能防止范围蔓延，保持创意愿景清晰。
协作定义3-5个核心支柱：
  • 每个支柱包含名称和一句话定义
  • 每个支柱包含设计测试：“如果我们在X和Y之间做选择，这个支柱要求我们选择__”
  • 支柱之间应形成张力——如果所有支柱方向一致，它们就没有发挥应有的作用
然后定义3个以上反支柱（游戏不包含的内容）：
  • 反支柱用于防止最常见的范围蔓延：“如果加入[功能]会不会很酷……”这类不符合核心愿景的功能
  • 表述方式：“我们不会做[某事]，因为它会损害[核心支柱]”
支柱确认：展示完整的支柱集后，使用
AskUserQuestion
：
  • 提示：“这些支柱是否符合你的游戏定位？”
  • 选项：
    [A] 锁定这些支柱
    / 
    [B] 重命名或重构某个支柱
    / 
    [C] 替换某个支柱
    / 
    [D] 其他需求
如果用户选择B、C或D，进行修改后再次使用
AskUserQuestion
：
  • 提示：“支柱已更新。是否准备锁定？”
  • 选项：
    [A] 锁定这些支柱
    / 
    [B] 修改另一个支柱
    / 
    [C] 其他需求
重复此过程直到用户选择[A] 锁定这些支柱。
评审模式检查——在生成CD-PILLARS和AD-CONCEPT-VISUAL之前应用：
  • solo
    → 跳过两者。备注：“CD-PILLARS已跳过——Solo模式。AD-CONCEPT-VISUAL已跳过——Solo模式。”进入第五阶段。
  • lean
    → 跳过两者（非PHASE-GATE关卡）。备注：“CD-PILLARS已跳过——Lean模式。AD-CONCEPT-VISUAL已跳过——Lean模式。”进入第五阶段。
  • full
    → 正常生成。
在核心支柱和反支柱达成一致后，在进入第五阶段前，通过Task并行生成
creative-director
和
art-director
。同时发起两个Task调用——不要等待一个完成后再启动另一个。
  • creative-director
     —— 关卡CD-PILLARS（
    .claude/docs/director-gates.md
    ） 提交内容：包含设计测试的完整支柱集、反支柱、核心幻想、独特吸引力。
  • art-director
     —— 关卡AD-CONCEPT-VISUAL（
    .claude/docs/director-gates.md
    ） 提交内容：游戏概念电梯游说、包含设计测试的完整支柱集、目标平台（若已知）、用户提及的任何参考游戏或视觉参考点。
收集两个评审结果，然后使用双标签页的
AskUserQuestion
一起展示：
  • 标签页**"Pillars"**：展示创意总监的反馈。选项遵循标准CD-PILLARS处理方式——
    保持原样锁定
    / 
    修改[特定支柱]
    / 
    进一步讨论
    。
  • 标签页**"Visual anchor"**：展示艺术总监提出的2-3个命名视觉方向选项。选项：每个命名方向（每个选项对应一个方向） + 
    融合多个方向的元素
    + 
    描述我自己的方向
    。
用户选择的视觉锚点（命名方向或自定义描述）将被存储为视觉标识锚点——它会被写入游戏概念文档，并成为美术设定集的基础。
如果创意总监对支柱提出疑问或拒绝，需先解决支柱问题，再询问视觉锚点选择——视觉方向应基于已确认的支柱。

Phase 5: Player Type Validation

第五阶段：玩家类型验证

Using the Bartle taxonomy and Quantic Foundry motivation model, validate who this game is actually for:
  • Primary player type: Who will LOVE this game? (Achievers, Explorers, Socializers, Competitors, Creators, Storytellers)
  • Secondary appeal: Who else might enjoy it?
  • Who is this NOT for: Being clear about who won't like this game is as important as knowing who will
  • Market validation: Are there successful games that serve a similar player type? What can we learn from their audience size?
使用Bartle分类法和Quantic Foundry动机模型，验证游戏的目标受众：
  • 核心玩家类型：谁会爱上这款游戏？（成就者、探索者、社交者、竞争者、创作者、叙事爱好者）
  • 次要吸引力：还有哪些玩家可能喜欢它？
  • 非目标受众：明确谁不会喜欢这款游戏，与明确目标受众同样重要
  • 市场验证：是否有成功的游戏服务类似的玩家类型？我们可以从它们的受众规模中学到什么？

Phase 6: Scope and Feasibility

第六阶段：范围与可行性

Ground the concept in reality:
  • Target platform: Use 
    AskUserQuestion
    — "What platforms are you targeting for this game?" 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 
    AskUserQuestion
    — "Do you already have an engine you work in?" 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?
  • Content scope: Estimate level/area count, item count, gameplay hours
  • MVP definition: What's the absolute minimum build that tests "is the core loop fun?"
  • Biggest risks: Technical risks, design risks, market risks
  • Scope tiers: What's the full vision vs. what ships if time runs out?
Review mode check — apply before spawning TD-FEASIBILITY:
  • solo
    → skip. Note: "TD-FEASIBILITY skipped — Solo mode." Proceed directly to scope tier definition.
  • lean
    → skip (not a PHASE-GATE). Note: "TD-FEASIBILITY skipped — Lean mode." Proceed directly to scope tier definition.
  • full
    → spawn as normal.
After identifying biggest technical risks, spawn 
technical-director
via Task using gate TD-FEASIBILITY (
.claude/docs/director-gates.md
) before scope tiers are defined.
Pass: core loop description, platform target, engine choice (or "undecided"), list of identified technical risks.
Present the assessment to the user. If HIGH RISK, offer to revisit scope before finalising. If CONCERNS, note them and continue.
Review mode check — apply before spawning PR-SCOPE:
  • solo
    → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to document generation.
  • lean
    → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to document generation.
  • full
    → spawn as normal.
After scope tiers are defined, spawn 
producer
via Task using gate PR-SCOPE (
.claude/docs/director-gates.md
).
Pass: full vision scope, MVP definition, timeline estimate, team size.
Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP definition or scope tiers before writing the document.
  1. Generate the game concept document using the template at 
    .claude/docs/templates/game-concept.md
    . Fill in ALL sections from the brainstorm conversation, including the MDA analysis, player motivation profile, and flow state design sections.
    Include a Visual Identity Anchor section in the game concept document with:
    • The selected visual direction name
    • The one-line visual rule
    • The 2-3 supporting visual principles with their design tests
    • The color philosophy summary
    This section is the seed of the art bible — it captures the "everything must move" decision before it can be forgotten between sessions.
  2. Use 
    AskUserQuestion
    for write approval:
  • 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 section to revise using 
AskUserQuestion
with options: 
Elevator Pitch
/ 
Core Fantasy & Unique Hook
/ 
Pillars
/ 
Core Loop
/ 
MVP Definition
/ 
Scope Tiers
/ 
Risks
/ 
Something else — I'll describe
After revising, show the updated section as a diff or clear before/after, then use 
AskUserQuestion
— "Ready to write the updated concept document?" Options: 
[A] Yes — write it
/ 
[B] Revise another section
Repeat until the user selects [A].
If yes, generate the document using the template at 
.claude/docs/templates/game-concept.md
, fill in ALL sections from the brainstorm conversation, and write the file, creating directories as needed.
Scope consistency rule: The "Estimated Scope" field in the Core Identity table must match the full-vision timeline from the Scope Tiers section — not just say "Large (9+ months)". Write it as "Large (X–Y months, solo)" or "Large (X–Y months, team of N)" so the summary table is accurate.
  1. Suggest next steps (in this order — this is the professional studio pre-production pipeline). List ALL steps — do not abbreviate or truncate:
Path A — Design-First (recommended if the concept is well-defined):
  1. "Run 
    /setup-engine
    to configure the engine and populate version-aware reference docs"
  2. "Run 
    /art-bible
    to create the visual identity specification — do this BEFORE writing GDDs. The art bible is required before the Technical Setup gate. It gates asset production and shapes technical architecture decisions (rendering, VFX, UI systems)."
  3. "Use 
    /design-review design/gdd/game-concept.md
    to validate concept completeness before going downstream"
  4. "Discuss vision with the 
    creative-director
    agent for pillar refinement"
  5. "Decompose the concept into individual systems with 
    /map-systems
    — maps dependencies, assigns priorities, and creates the systems index"
  6. "Author per-system GDDs with 
    /design-system
    — guided, section-by-section GDD writing for each system identified in step 5"
  7. "Plan the technical architecture with 
    /create-architecture
    — produces the master architecture blueprint and Required ADR list"
  8. "Record key architectural decisions with 
    /architecture-decision (×N)
    — write one ADR per decision in the Required ADR list from 
    /create-architecture
    "
  9. "Run 
    /architecture-review
    — bootstraps the TR registry and Requirements Traceability Matrix from your GDDs and ADRs (required before the Pre-Production gate)"
  10. "Validate readiness to advance with 
    /gate-check
    — phase gate before committing to production"
Path B — Prototype-First (use if the core mechanic is unproven or the concept needs validation):
  1. "Run 
    /setup-engine
    to configure the engine"
  2. "Run 
    /prototype [core-mechanic]
    — validate the core idea is fun before writing any GDDs (1–3 days throwaway code)"
  3. "If prototype PROCEEDS: run 
    /art-bible
    , then continue with Path A steps 5–10 above, using prototype learnings to inform your GDDs"
  4. "If prototype PIVOTS: return to 
    /brainstorm
    with the learnings and reshape the concept"
  5. "After full design and architecture, build the 
    /vertical-slice
    to validate production readiness before committing to sprints"
  6. Output a summary with the chosen concept's elevator pitch, pillars, primary player type, engine recommendation, biggest risk, and file path.
Verdict: COMPLETE — game concept created and handed off for next steps.
让概念落地：
  • 目标平台：使用
    AskUserQuestion
    ——“你这款游戏的目标平台是什么？” 选项：
    PC (Steam / Epic)
    / 
    Mobile (iOS / Android)
    / 
    Console
    / 
    Web / Browser
    / 
    Multiple platforms
    记录答案——它直接影响引擎推荐，并将传递给
    /setup-engine
    。 若相关，备注平台影响（例如：移动端优先推荐Unity；主机平台Godot存在局限性；网页端Godot导出更顺畅）。
  • 引擎经验：使用
    AskUserQuestion
    ——“你已经有常用的引擎了吗？” 选项：
    Godot
    / 
    Unity
    / 
    Unreal Engine 5
    / 
    无偏好——帮我决定
    • 如果用户选择某个引擎 → 记录为他们的偏好并继续。不要质疑他们的选择。
    • 如果选择“无偏好” → 告知用户：“本次会话结束后运行
      /setup-engine
      ——它会根据你的概念和目标平台引导你完成完整的决策过程。”此处不要给出推荐。
  • 美术流程：美术风格是什么？劳动强度如何？
  • 内容范围：预估关卡/区域数量、物品数量、游戏时长
  • MVP定义：测试“核心循环是否有趣”的最小可行版本是什么？
  • 最大风险：技术风险、设计风险、市场风险
  • 范围层级：完整愿景是什么？如果时间不足，哪些内容会优先发布？
评审模式检查——在生成TD-FEASIBILITY之前应用：
  • solo
    → 跳过。备注：“TD-FEASIBILITY已跳过——Solo模式。”直接进入范围层级定义。
  • lean
    → 跳过（非PHASE-GATE关卡）。备注：“TD-FEASIBILITY已跳过——Lean模式。”直接进入范围层级定义。
  • full
    → 正常生成。
在确定最大技术风险后，在定义范围层级之前，通过Task使用关卡TD-FEASIBILITY（
.claude/docs/director-gates.md
）生成
technical-director
。
提交内容：核心循环描述、目标平台、引擎选择（或“未决定”）、已识别的技术风险列表。
向用户展示评估结果。如果是高风险，在最终确定前提供重新审视范围的选项。如果有疑问，记录下来并继续。
评审模式检查——在生成PR-SCOPE之前应用：
  • solo
    → 跳过。备注：“PR-SCOPE已跳过——Solo模式。”进入文档生成阶段。
  • lean
    → 跳过（非PHASE-GATE关卡）。备注：“PR-SCOPE已跳过——Lean模式。”进入文档生成阶段。
  • full
    → 正常生成。
在定义范围层级后，通过Task使用关卡PR-SCOPE（
.claude/docs/director-gates.md
）生成
producer
。
提交内容：完整愿景范围、MVP定义、时间线预估、团队规模。
向用户展示评估结果。如果不切实际，在撰写文档前提供调整MVP定义或范围层级的选项。
  1. 使用
    .claude/docs/templates/game-concept.md
    中的模板生成游戏概念文档    。填充头脑风暴对话中的所有部分，包括MDA分析、玩家动机画像和心流状态设计部分。
    在游戏概念文档中加入视觉标识锚点部分，包含：
    • 选定的视觉方向名称
    • 一句话视觉规则
    • 2-3个支持性视觉原则及其设计测试
    • 色彩理念总结
    这部分是美术设定集的雏形——它记录了“所有元素必须具有动态感”这类决策，避免在会话间隔中被遗忘。
  2. 使用
    AskUserQuestion
    获取写入许可：
  • 提示：“游戏概念已准备就绪。是否可以写入
    design/gdd/game-concept.md
    ？”
  • 选项：
    [A] 是——写入
    / 
    [B] 暂不——先修改某个部分
如果选择[B]：使用
AskUserQuestion
询问要修改的部分，选项为：
电梯游说
/ 
核心幻想与独特吸引力
/ 
核心支柱
/ 
核心循环
/ 
MVP定义
/ 
范围层级
/ 
风险
/ 
其他——我来描述
修改后，以差异对比或清晰的前后版本展示更新部分，然后使用
AskUserQuestion
——“是否准备写入更新后的概念文档？” 选项：
[A] 是——写入
/ 
[B] 修改另一个部分
重复此过程直到用户选择[A]。
如果同意，使用
.claude/docs/templates/game-concept.md
中的模板生成文档，填充头脑风暴对话中的所有部分，并写入文件，必要时创建目录。
范围一致性规则：核心信息表中的“预估范围”字段必须与范围层级部分中的完整愿景时间线匹配——不能只写“大型（9个月以上）”。应写为“大型（X–Y个月，独立开发）”或“大型（X–Y个月，N人团队）”，确保摘要表准确。
  1. 建议后续步骤（按此顺序——这是专业工作室的预生产流程）。列出所有步骤——不得缩写或省略：
路径A——设计优先（若概念已明确，推荐此路径）：
  1. “运行
    /setup-engine
    配置引擎并填充版本感知参考文档”
  2. “运行
    /art-bible
    创建视觉标识规范——在撰写GDD之前完成此步骤。**美术设定集是技术设置关卡的前置要求。**它管控资产生产并影响技术架构决策（渲染、特效、UI系统）。”
  3. “使用
    /design-review design/gdd/game-concept.md
    验证概念完整性，再进入下游流程”
  4. “与
    creative-director
    Agent讨论愿景，优化核心支柱”
  5. “使用
    /map-systems
    将概念分解为独立系统——映射依赖关系、分配优先级并创建系统索引”
  6. “使用
    /design-system
    撰写每个系统的GDD——为步骤5中识别的每个系统提供分节引导式GDD撰写”
  7. “使用
    /create-architecture
    规划技术架构——生成主架构蓝图和必填ADR列表”
  8. “使用
    /architecture-decision (×N)
    记录关键架构决策——为
    /create-architecture
    生成的必填ADR列表中的每个决策撰写一份ADR”
  9. “运行
    /architecture-review
    ——从你的GDD和ADR中引导生成TR注册表和需求追溯矩阵（进入预生产关卡前必填）”
  10. “运行
    /gate-check
    验证推进准备情况——进入生产前的阶段关卡”
路径B——原型优先（若核心机制未经验证或概念需要验证，使用此路径）：
  1. “运行
    /setup-engine
    配置引擎”
  2. “运行
    /prototype [core-mechanic]
    ——在撰写任何GDD之前验证核心创意是否有趣（1–3天的一次性代码）”
  3. “如果原型验证通过：运行
    /art-bible
    ，然后继续路径A的步骤5–10，利用原型经验优化GDD”
  4. “如果原型需要调整：带着经验返回
    /brainstorm
    重塑概念”
  5. “完成设计和架构后，制作
    /vertical-slice
    验证生产准备情况，再进入迭代开发”
  6. 输出摘要，包含选定概念的电梯游说、核心支柱、核心玩家类型、引擎推荐、最大风险和文件路径。
结论：完成——游戏概念已创建并移交至后续流程。

Context Window Awareness

上下文窗口感知

This is a multi-phase skill. If context reaches or exceeds 70% during any phase, append this notice to the current response before continuing:
Context is approaching the limit (≥70%). The game concept document is saved to 
design/gdd/game-concept.md
. Open a fresh Claude Code session to continue if needed — progress is not lost.
这是一个多阶段Skill。如果在任何阶段上下文达到或超过70%，在继续之前将以下通知附加到当前响应中：
**上下文即将达到限制（≥70%）。**游戏概念文档已保存至
design/gdd/game-concept.md
。如有需要，开启新的Claude Code会话继续——进度不会丢失。

Recommended Next Steps

推荐后续步骤

After the game concept is written, follow the pre-production pipeline in order:
  1. /setup-engine
    — configure the engine and populate version-aware reference docs
  2. /art-bible
    — establish visual identity before writing any GDDs
  3. /map-systems
    — decompose the concept into individual systems with dependencies
  4. /design-system [first-system]
    — author per-system GDDs in dependency order
  5. /create-architecture
    — produce the master architecture blueprint
  6. /architecture-review
    — bootstrap TR registry and Requirements Traceability Matrix
  7. /gate-check pre-production
    — validate readiness before committing to production
游戏概念撰写完成后，按顺序遵循预生产流程：
  1. /setup-engine
    ——配置引擎并填充版本感知参考文档
  2. /art-bible
    ——在撰写任何GDD之前确立视觉标识
  3. /map-systems
    ——将概念分解为带有依赖关系的独立系统
  4. /design-system [first-system]
    ——按依赖顺序撰写每个系统的GDD
  5. /create-architecture
    ——生成主架构蓝图
  6. /architecture-review
    ——引导生成TR注册表和需求追溯矩阵
  7. /gate-check pre-production
    ——验证进入生产的准备情况