Back to Details

map-systems

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
When this skill is invoked:
当调用此技能时：

Parse Arguments

解析参数

Two modes:
  • No argument: 
    /map-systems
    — Run the full decomposition workflow (Phases 1-5) to create or update the systems index.
  • next
    : 
    /map-systems next
    — Pick the highest-priority undesigned system from the index and hand off to 
    /design-system
    (Phase 6).
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.
两种模式：
  • 无参数：
    /map-systems
    — 运行完整的分解工作流（阶段1-5）以创建或更新系统索引。
  • next
    ：
    /map-systems next
    — 从索引中选择优先级最高的未设计系统，并移交至
    /design-system
    （阶段6）。
同时解析评审模式（本次运行仅设置一次，适用于所有关卡生成）：
  1. 如果传入
    --review [full|lean|solo]
    → 使用该值
  2. 否则读取
    production/review-mode.txt
    → 使用该文件中的值
  3. 否则 → 默认使用
    lean
完整的检查规则请参见
.claude/docs/director-gates.md
。

Phase 1: Read Concept (Required Context)

阶段1：读取概念（必要上下文）

Read the game concept and any existing design work. This provides the raw material for systems decomposition.
Required:
  • Read 
    design/gdd/game-concept.md
    — fail with a clear message if missing:
    "No game concept found at 
    design/gdd/game-concept.md
    . Run 
    /brainstorm
    first to create one, then come back to decompose it into systems."
Optional (read if they exist):
  • Read 
    design/gdd/game-pillars.md
    — pillars constrain priority and scope
  • Read 
    design/gdd/systems-index.md
    — if exists, resume from where it left off (update, don't recreate from scratch)
  • Glob 
    design/gdd/*.md
    — check which system GDDs already exist
If the systems index already exists:
  • Read it and present current status to the user
  • Use 
    AskUserQuestion
    to ask: "The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?"
    • Options: "Update the index with new systems", "Design the next undesigned system", "Review and revise priorities"
读取游戏概念及现有设计成果。这为系统分解提供原始素材。
必填项：
  • 读取
    design/gdd/game-concept.md
    — 若文件缺失则给出明确提示：
    "未在
    design/gdd/game-concept.md
    路径下找到游戏概念。请先运行
    /brainstorm
    创建游戏概念，再返回进行系统分解。"
可选项（若存在则读取）：
  • 读取
    design/gdd/game-pillars.md
    — 核心支柱会约束优先级与范围
  • 读取
    design/gdd/systems-index.md
    — 若文件存在，从当前进度继续（更新而非从头创建）
  • 匹配
    design/gdd/*.md
    — 检查已存在的系统GDD文件
若系统索引已存在：
  • 读取索引并向用户展示当前状态
  • 使用
    AskUserQuestion
    询问： "系统索引已存在，包含[N]个系统（其中[M]个已设计，[K]个未启动）。您希望执行什么操作？"
    • 选项："向索引中添加新系统"、"设计下一个未完成的系统"、"评审并调整优先级"

Phase 2: Systems Enumeration (Collaborative)

阶段2：系统枚举（协作式）

Extract and identify all systems the game needs. This is the creative core of the skill — it requires human judgment because concept docs rarely enumerate every system explicitly.
提取并识别游戏所需的所有系统。这是本技能的创意核心——由于概念文档很少明确列举每个系统，因此需要人工判断。

Step 2a: Extract Explicit Systems

步骤2a：提取显性系统

Scan the game concept for directly mentioned systems and mechanics:
  • Core Mechanics section (most explicit)
  • Core Loop section (implies what systems drive each loop tier)
  • Technical Considerations section (networking, procedural generation, etc.)
  • MVP Definition section (required features = required systems)
扫描游戏概念文档，找出直接提及的系统与机制：
  • 核心机制章节（最明确）
  • 核心循环章节（暗示驱动各循环层级的系统）
  • 技术考量章节（网络、程序化生成等）
  • MVP定义章节（必备功能=必备系统）

Step 2b: Identify Implicit Systems

步骤2b：识别隐性系统

For each explicit system, identify the hidden systems it implies. Games always need more systems than the concept doc mentions. Use this inference pattern:
  • "Inventory" implies: item database, equipment slots, weight/capacity rules, inventory UI, item serialization for save/load
  • "Combat" implies: damage calculation, health system, hit detection, status effects, enemy AI, combat UI (health bars, damage numbers), death/respawn
  • "Open world" implies: streaming/chunking, LOD system, fast travel, map/minimap, point of interest tracking, world state persistence
  • "Multiplayer" implies: networking layer, lobby/matchmaking, state synchronization, anti-cheat, network UI (ping, player list)
  • "Crafting" implies: recipe database, ingredient gathering, crafting UI, success/failure mechanics, recipe discovery/learning
  • "Dialogue" implies: dialogue tree system, dialogue UI, choice tracking, NPC state management, localization hooks
  • "Progression" implies: XP system, level-up mechanics, skill tree, unlock tracking, progression UI, progression save data
Explain in conversation text why each implicit system is needed (with examples).
针对每个显性系统，识别其隐含的隐藏系统。游戏所需的系统总是多于概念文档提及的数量。请使用以下推理模式：
  • "背包系统"意味着：物品数据库、装备槽位、重量/容量规则、背包UI、物品序列化（用于存档/读档）
  • "战斗系统"意味着：伤害计算、生命值系统、命中检测、状态效果、敌人AI、战斗UI（血条、伤害数值）、死亡/重生机制
  • "开放世界"意味着：流式加载/区块化、LOD系统、快速旅行、地图/小地图、兴趣点追踪、世界状态持久化
  • "多人游戏"意味着：网络层、大厅/匹配系统、状态同步、反作弊、网络UI（延迟、玩家列表）
  • " crafting系统"意味着：配方数据库、素材收集、制作UI、成功/失败机制、配方解锁/学习
  • "对话系统"意味着：对话树系统、对话UI、选择追踪、NPC状态管理、本地化钩子
  • "成长系统"意味着：XP系统、升级机制、技能树、解锁追踪、成长UI、成长存档数据
在对话中解释每个隐性系统的必要性（附示例）。

Step 2c: User Review

步骤2c：用户评审

Present the enumeration organized by category. For each system, show:
  • Name
  • Category
  • Brief description (1 sentence)
  • Whether it was explicit (from concept) or implicit (inferred)
Then use 
AskUserQuestion
to capture feedback:
  • "Are there systems missing from this list?"
  • "Should any of these be combined or split?"
  • "Are there systems listed that this game does NOT need?"
Iterate until the user approves the enumeration.
按类别整理枚举结果并展示。每个系统需包含：
  • 名称
  • 类别
  • 简要描述（1句话）
  • 来源（来自概念文档的显性系统，或推断出的隐性系统）
然后使用
AskUserQuestion
收集反馈：
  • "列表中是否遗漏了某些系统？"
  • "是否有系统需要合并或拆分？"
  • "列表中是否包含本游戏不需要的系统？"
迭代直至用户批准枚举结果。

Phase 3: Dependency Mapping (Collaborative)

阶段3：依赖映射（协作式）

For each system, determine what it depends on. A system "depends on" another if it cannot function without that other system existing first.
为每个系统确定其依赖项。如果系统A没有系统B就无法运行，则系统A"依赖于"系统B。

Step 3a: Map Dependencies

步骤3a：映射依赖关系

For each system, list its dependencies. Use these dependency heuristics:
  • Input/output dependencies: System A produces data System B needs
  • Structural dependencies: System A provides the framework System B plugs into
  • UI dependencies: Every gameplay system has a corresponding UI system that depends on it (but UI is designed after the gameplay system)
为每个系统列出其依赖项。请使用以下依赖启发式规则：
  • 输入/输出依赖：系统A生成系统B所需的数据
  • 结构依赖：系统A提供系统B可接入的框架
  • UI依赖：每个玩法系统都有对应的UI系统依赖于它（但UI系统在玩法系统之后设计）

Step 3b: Sort by Dependency Order

步骤3b：按依赖顺序排序

Arrange systems into layers:
  1. Foundation: Systems with zero dependencies (designed and built first)
  2. Core: Systems depending only on Foundation systems
  3. Feature: Systems depending on Core systems
  4. Presentation: UI and feedback systems that wrap gameplay systems
  5. Polish: Meta-systems, tutorials, analytics, accessibility
将系统分为多个层级：
  1. 基础层：无依赖的系统（最先设计与构建）
  2. 核心层：仅依赖基础层系统的系统
  3. 功能层：依赖核心层系统的系统
  4. 展示层：包裹玩法系统的UI与反馈系统
  5. 优化层：元系统、教程、分析、无障碍功能

Step 3c: Detect Circular Dependencies

步骤3c：检测循环依赖

Check for cycles in the dependency graph. If found:
  • Highlight them to the user
  • Propose resolutions (interface abstraction, simultaneous design, breaking the cycle by defining a contract between the two systems)
检查依赖图中的循环。若发现循环：
  • 向用户高亮显示
  • 提出解决方案（接口抽象、同步设计、通过定义两个系统间的契约打破循环）

Step 3d: Present to User

步骤3d：向用户展示

Show the dependency map as a layered list. Highlight:
  • Any circular dependencies
  • Any "bottleneck" systems (many others depend on them — these are high-risk)
  • Any systems with no dependents (leaf nodes — lower risk, can be designed late)
Use 
AskUserQuestion
to ask: "Does this dependency ordering look right? Any dependencies I'm missing or that should be removed?"
Review mode check — apply before spawning TD-SYSTEM-BOUNDARY:
  • solo
    → skip. Note: "TD-SYSTEM-BOUNDARY skipped — Solo mode." Proceed to priority assignment.
  • lean
    → skip (not a PHASE-GATE). Note: "TD-SYSTEM-BOUNDARY skipped — Lean mode." Proceed to priority assignment.
  • full
    → spawn as normal.
After dependency mapping is approved, spawn 
technical-director
via Task using gate TD-SYSTEM-BOUNDARY (
.claude/docs/director-gates.md
) before proceeding to priority assignment.
Pass: the dependency map summary, layer assignments, bottleneck systems list, any circular dependency resolutions.
Present the assessment. If REJECT, revise the system boundaries with the user before moving to priority assignment. If CONCERNS, note them inline in the systems index and continue.
以分层列表形式展示依赖图。重点高亮：
  • 任何循环依赖
  • 任何"瓶颈"系统（许多其他系统依赖它——风险较高）
  • 任何无依赖项的系统（叶节点——风险较低，可后期设计）
使用
AskUserQuestion
询问："这个依赖顺序是否合理？是否有遗漏或需要移除的依赖项？"
评审模式检查 — 在生成TD-SYSTEM-BOUNDARY前应用：
  • solo
    → 跳过。备注："TD-SYSTEM-BOUNDARY已跳过——Solo模式。" 继续进行优先级分配。
  • lean
    → 跳过（非PHASE-GATE）。备注："TD-SYSTEM-BOUNDARY已跳过——Lean模式。" 继续进行优先级分配。
  • full
    → 正常生成。
依赖映射获批准后，在进行优先级分配前，通过任务生成
technical-director
并使用关卡TD-SYSTEM-BOUNDARY（
.claude/docs/director-gates.md
）。
传递内容：依赖映射摘要、层级分配、瓶颈系统列表、循环依赖解决方案。
展示评估结果。若被拒绝，先与用户调整系统边界，再进行优先级分配。若有疑问，将其内联记录在系统索引中并继续。

Phase 4: Priority Assignment (Collaborative)

阶段4：优先级分配（协作式）

Assign each system to a priority tier based on what milestone it's needed for.
根据系统所需的里程碑，为每个系统分配优先级层级。

Step 4a: Auto-Assign Based on Concept

步骤4a：基于概念自动分配

Use these heuristics for initial assignment:
  • MVP: Systems mentioned in the concept's "Required for MVP" section, plus their Foundation-layer dependencies
  • Vertical Slice: Systems needed for a complete experience in one area
  • Alpha: All remaining gameplay systems
  • Full Vision: Polish, meta, and nice-to-have systems
使用以下启发式规则进行初始分配：
  • MVP：概念文档"MVP必备"章节提及的系统，及其基础层依赖项
  • 垂直切片：在某一领域实现完整体验所需的系统
  • Alpha：所有剩余玩法系统
  • 完整愿景：优化、元系统与锦上添花的系统

Step 4b: User Review

步骤4b：用户评审

Present the priority assignments in a table. For each tier, explain why systems were placed there.
Use 
AskUserQuestion
to ask: "Do these priority assignments match your vision? Which systems should be higher or lower priority?"
Explain reasoning in conversation: "I placed [system] in MVP because the core loop requires it — without [system], the 30-second loop can't function."
"Why" column guidance: When explaining why each system was placed in a priority tier, mix technical necessity with player-experience reasoning. Do not use purely technical justifications like "Combat needs damage math" — connect to player experience where relevant. Examples of good "Why" entries:
  • "Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)"
  • "Ballista's punch-through identity is established here — this stat definition is what makes it feel different from Archer"
  • "Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices"
Pure technical necessity ("X depends on Y") is insufficient alone when the system directly shapes player experience.
Review mode check — apply before spawning PR-SCOPE:
  • solo
    → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to writing the systems index.
  • lean
    → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to writing the systems index.
  • full
    → spawn as normal.
After priorities are approved, spawn 
producer
via Task using gate PR-SCOPE (
.claude/docs/director-gates.md
) before writing the index.
Pass: total system count per milestone tier, estimated implementation volume per tier (system count × average complexity), team size, stated project timeline.
Present the assessment. If UNREALISTIC, offer to revise priority tier assignments before writing the index. If CONCERNS, note them and continue.
以表格形式展示优先级分配结果。为每个层级解释系统分配的原因。
使用
AskUserQuestion
询问："这些优先级分配是否符合您的预期？哪些系统需要提高或降低优先级？"
在对话中解释理由："我将[系统]归为MVP，因为核心循环需要它——没有[系统]，30秒的循环无法运行。"
"原因"列指导：解释每个系统分配至某优先级层级的原因时，需结合技术必要性与玩家体验逻辑。请勿仅使用纯技术理由，如"战斗系统需要伤害计算"——需尽可能关联玩家体验。优秀的"原因"示例：
  • "核心循环必备——没有它，放置决策将毫无意义（支柱2：放置即谜题）"
  • "弩炮的穿透特性在此定义——该属性是它与弓箭手的核心区别"
  • "所有经济决策的基础——玩家必须理解升级成本才能做出有意义的放置选择"
当系统直接影响玩家体验时，纯技术必要性（"X依赖于Y"）不足以作为理由。
评审模式检查 — 在生成PR-SCOPE前应用：
  • solo
    → 跳过。备注："PR-SCOPE已跳过——Solo模式。" 继续编写系统索引。
  • lean
    → 跳过（非PHASE-GATE）。备注："PR-SCOPE已跳过——Lean模式。" 继续编写系统索引。
  • full
    → 正常生成。
优先级获批准后，在编写索引前，通过任务生成
producer
并使用关卡PR-SCOPE（
.claude/docs/director-gates.md
）。
传递内容：每个里程碑层级的系统总数、每个层级的预估实现量（系统数×平均复杂度）、团队规模、既定项目 timeline。
展示评估结果。若不切实际，主动提出调整优先级层级后再编写索引。若有疑问，记录后继续。

Step 4c: Determine Design Order

步骤4c：确定设计顺序

Combine dependency sort + priority tier to produce the final design order:
  1. MVP Foundation systems first
  2. MVP Core systems second
  3. MVP Feature systems third
  4. Vertical Slice Foundation/Core systems
  5. ...and so on
This is the order the team should write GDDs in.
结合依赖排序+优先级层级，生成最终设计顺序：
  1. 首先是MVP基础层系统
  2. 其次是MVP核心层系统
  3. 然后是MVP功能层系统
  4. 垂直切片的基础层/核心层系统
  5. …以此类推
这是团队编写GDD的顺序。

Phase 5: Create Systems Index (Write)

阶段5：创建系统索引（写入）

Step 5a: Draft the Document

步骤5a：起草文档

Using the template at 
.claude/docs/templates/systems-index.md
, populate the systems index with all data from Phases 2-4:
  • Fill the enumeration table
  • Fill the dependency map
  • Fill the recommended design order
  • Fill the high-risk systems
  • Fill progress tracker (all systems "Not Started" initially, unless GDDs already exist)
使用
.claude/docs/templates/systems-index.md
中的模板，填充阶段2-4的所有数据以生成系统索引：
  • 填充枚举表
  • 填充依赖映射
  • 填充推荐设计顺序
  • 填充高风险系统
  • 填充进度追踪器（初始状态为所有系统"未启动"，除非已存在GDD）

Step 5b: Approval

步骤5b：审批

Present a summary of the document:
  • Total systems count by category
  • MVP system count
  • First 3 systems in the design order
  • Any high-risk items
Ask: "May I write the systems index to 
design/gdd/systems-index.md
?"
Wait for approval. Write the file only after "yes."
Review mode check — apply before spawning CD-SYSTEMS:
  • solo
    → skip. Note: "CD-SYSTEMS skipped — Solo mode." Proceed to Phase 7 next steps.
  • lean
    → skip (not a PHASE-GATE). Note: "CD-SYSTEMS skipped — Lean mode." Proceed to Phase 7 next steps.
  • full
    → spawn as normal.
After the systems index is written, spawn 
creative-director
via Task using gate CD-SYSTEMS (
.claude/docs/director-gates.md
).
Pass: systems index path, game pillars and core fantasy (from 
design/gdd/game-concept.md
), MVP priority tier system list.
Present the assessment. If REJECT, revise the system set with the user before GDD authoring begins. If CONCERNS, record them in the systems index as a 
> **Creative Director Note**
at the top of the relevant tier section.
展示文档摘要：
  • 按类别统计的系统总数
  • MVP系统数量
  • 设计顺序中的前3个系统
  • 任何高风险项
询问："是否允许我将系统索引写入
design/gdd/systems-index.md
？"
等待批准。仅在收到"是"后写入文件。
评审模式检查 — 在生成CD-SYSTEMS前应用：
  • solo
    → 跳过。备注："CD-SYSTEMS已跳过——Solo模式。" 继续阶段7的下一步。
  • lean
    → 跳过（非PHASE-GATE）。备注："CD-SYSTEMS已跳过——Lean模式。" 继续阶段7的下一步。
  • full
    → 正常生成。
系统索引写入后，通过任务生成
creative-director
并使用关卡CD-SYSTEMS（
.claude/docs/director-gates.md
）。
传递内容：系统索引路径、游戏核心支柱与核心幻想（来自
design/gdd/game-concept.md
）、MVP优先级层级系统列表。
展示评估结果。若被拒绝，先与用户调整系统集，再开始编写GDD。若有疑问，在系统索引相关层级顶部以
> **创意总监备注**
的形式记录。

Step 5c: Update Session State

步骤5c：更新会话状态

After writing, create 
production/session-state/active.md
if it does not exist, then update it with:
  • Task: Systems decomposition
  • Status: Systems index created
  • File: design/gdd/systems-index.md
  • Next: Design individual system GDDs
Verdict: COMPLETE — systems index written to 
design/gdd/systems-index.md
. If the user declined: Verdict: BLOCKED — user did not approve the write.
写入完成后，若
production/session-state/active.md
不存在则创建，然后更新以下内容：
  • 任务：系统分解
  • 状态：系统索引已创建
  • 文件：design/gdd/systems-index.md
  • 下一步：设计单个系统GDD
结论：完成 — 系统索引已写入
design/gdd/systems-index.md
。 若用户拒绝：结论：阻塞 — 用户未批准写入操作。

Phase 6: Design Individual Systems (Handoff to /design-system)

阶段6：设计单个系统（移交至/design-system）

This phase is entered when:
  • The user says "yes" to designing systems after creating the index
  • The user invokes 
    /map-systems [system-name]
  • The user invokes 
    /map-systems next
在以下情况进入本阶段：
  • 用户在创建索引后表示要设计系统
  • 用户调用
    /map-systems [system-name]
  • 用户调用
    /map-systems next

Step 6a: Select the System

步骤6a：选择系统

  • If a system name was provided, find it in the systems index
  • If 
    next
    was used, pick the highest-priority undesigned system (by design order)
  • If the user just finished the index, ask: "Would you like to start designing individual systems now? The first system in the design order is [name]. Or would you prefer to stop here and come back later?"
Use 
AskUserQuestion
for: "Start designing [system-name] now, pick a different system, or stop here?"
  • 若提供了系统名称，在系统索引中查找
  • 若使用
    next
    ，选择优先级最高的未设计系统（按设计顺序）
  • 若用户刚完成索引，询问： "您现在想要开始设计单个系统吗？设计顺序中的第一个系统是[名称]。还是希望先到此为止，之后再继续？"
使用
AskUserQuestion
询问："现在开始设计[系统名称]，选择其他系统，还是到此为止？"

Step 6b: Hand Off to /design-system

步骤6b：移交至/design-system

Once a system is selected, invoke the 
/design-system [system-name]
skill.
The 
/design-system
skill handles the full GDD authoring process:
  • Gathers context from game concept, systems index, and dependency GDDs
  • Creates a file skeleton immediately
  • Walks through all 8 required sections one at a time (collaborative, incremental)
  • Cross-references existing docs to prevent contradictions
  • Routes to specialist agents for domain expertise
  • Writes each section to file as soon as it's approved
  • Runs 
    /design-review
    when complete
  • Updates the systems index
Do not duplicate the /design-system workflow here. This skill owns the systems index; 
/design-system
owns individual system GDDs.
选定系统后，调用
/design-system [system-name]
技能。
/design-system
技能负责完整的GDD编写流程：
  • 从游戏概念、系统索引与依赖GDD中收集上下文
  • 立即创建文件框架
  • 逐步完成所有8个必填章节（协作式、增量式）
  • 交叉引用现有文档以避免矛盾
  • 向领域专家代理寻求专业支持
  • 章节获批准后立即写入文件
  • 完成后运行
    /design-review
  • 更新系统索引
请勿在此重复/design-system的工作流。 本技能负责系统索引；
/design-system
负责单个系统GDD。

Step 6c: Loop or Stop

步骤6c：循环或停止

After 
/design-system
completes, use 
AskUserQuestion
:
  • "Continue to the next system ([next system name])?"
  • "Pick a different system?"
  • "Stop here for this session?"
If continuing, return to Step 6a.
/design-system
完成后，使用
AskUserQuestion
询问：
  • "继续设计下一个系统（[下一个系统名称]）？"
  • "选择其他系统？"
  • "本次会话到此为止？"
若继续，返回步骤6a。

Phase 7: Suggest Next Steps

阶段7：建议下一步操作

After the systems index is created (or after designing some systems), present next actions using 
AskUserQuestion
:
  • "Systems index is written. What would you like to do next?"
    • [A] Start designing GDDs — run 
      /design-system [first-system-in-order]
    • [B] Run 
      /gate-check systems-design
      — triggers the CD-SYSTEMS and TD-SYSTEM-BOUNDARY gates automatically for a formal director sign-off on the system set
    • [C] Stop here for this session
The gate-check option ([B]) is worth highlighting: running 
/gate-check systems-design
triggers both the CD-SYSTEMS and TD-SYSTEM-BOUNDARY gates, catching scope issues, missing systems, and boundary problems before they're locked in across many documents. It is optional but recommended for new projects.
After any individual GDD is completed:
  • "Run 
    /design-review design/gdd/[system].md
    in a fresh session to validate quality"
  • "Run 
    /gate-check systems-design
    when all MVP GDDs are complete"
系统索引创建完成后（或设计完部分系统后），使用
AskUserQuestion
展示后续操作：
  • "系统索引已编写完成。您接下来想要做什么？"
    • [A] 开始编写GDD — 运行
      /design-system [设计顺序中的第一个系统]
    • [B] 运行
      /gate-check systems-design
      — 自动触发CD-SYSTEMS与TD-SYSTEM-BOUNDARY关卡，正式让总监对系统集进行签字确认
    • [C] 本次会话到此为止
需重点突出关卡检查选项([B])：运行
/gate-check systems-design
会同时触发CD-SYSTEMS与TD-SYSTEM-BOUNDARY关卡，在多个文档锁定前发现范围问题、遗漏系统与边界问题。这是可选操作，但对新项目推荐使用。
单个GDD完成后：
  • "在新会话中运行
    /design-review design/gdd/[system].md
    以验证质量"
  • "所有MVP GDD完成后运行
    /gate-check systems-design
    "

Collaborative Protocol

协作协议

This skill follows the collaborative design principle at every phase:
  1. Question -> Options -> Decision -> Draft -> Approval at every step
  2. AskUserQuestion at every decision point (Explain -> Capture pattern):
    • Phase 2: "Missing systems? Combine or split?"
    • Phase 3: "Dependency ordering correct?"
    • Phase 4: "Priority assignments match your vision?"
    • Phase 5: "May I write the systems index?"
    • Phase 6: "Start designing, pick different, or stop?" then hand off to 
      /design-system
  3. "May I write to [filepath]?" before every file write
  4. Incremental writing: Update the systems index after each system is designed
  5. Handoff: Individual GDD authoring is owned by 
    /design-system
    , which handles incremental section writing, cross-referencing, design review, and index updates
  6. Session state updates: Write to 
    production/session-state/active.md
    after each milestone (index created, system designed, priorities changed)
Never auto-generate the full systems list and write it without review. Never start designing a system without user confirmation. Always show the enumeration, dependencies, and priorities for user validation.
本技能在每个阶段均遵循协作设计原则：
  1. 每个步骤均遵循提问->选项->决策->起草->审批流程
  2. 每个决策点均使用
    AskUserQuestion
    （解释->收集模式）：
    • 阶段2："是否遗漏系统？是否需要合并或拆分？"
    • 阶段3："依赖顺序是否正确？"
    • 阶段4："优先级分配是否符合您的预期？"
    • 阶段5："是否允许我写入系统索引？"
    • 阶段6："开始设计、选择其他系统，还是到此为止？" 然后移交至
      /design-system
  3. 每次写入文件前均询问**"是否允许我写入[文件路径]？"**
  4. 增量式写入：每个系统设计完成后更新系统索引
  5. 移交：单个GDD编写由
    /design-system
    负责，该技能处理增量式章节编写、交叉引用、设计评审与索引更新
  6. 会话状态更新：每个里程碑（索引创建、系统设计完成、优先级调整）后写入
    production/session-state/active.md
禁止自动生成完整系统列表并直接写入而不经过评审。 禁止未获用户确认就开始设计系统。 必须向用户展示枚举结果、依赖关系与优先级以获取验证。

Context Window Awareness

上下文窗口感知

If context reaches or exceeds 70% at any point, append this notice:
Context is approaching the limit (≥70%). The systems index is saved to 
design/gdd/systems-index.md
. Open a fresh Claude Code session to continue designing individual GDDs — run 
/map-systems next
to pick up where you left off.
若任何时刻上下文达到或超过70%，请附加以下提示：
上下文即将达到上限（≥70%）。 系统索引已保存至
design/gdd/systems-index.md
。请开启新的Claude Code会话继续设计单个GDD — 运行
/map-systems next
即可从当前进度继续。

Recommended Next Steps

推荐下一步操作

  • Run 
    /design-system [first-system-in-order]
    to author the first GDD (use design order from the index)
  • Run 
    /map-systems next
    to always pick the highest-priority undesigned system automatically
  • Run 
    /design-review design/gdd/[system].md
    in a fresh session after each GDD is authored
  • Run 
    /gate-check pre-production
    when all MVP GDDs are authored and reviewed
  • 运行
    /design-system [设计顺序中的第一个系统]
    编写首个GDD（使用索引中的设计顺序）
  • 运行
    /map-systems next
    自动选择优先级最高的未设计系统
  • 每个GDD编写完成后，在新会话中运行
    /design-review design/gdd/[system].md
  • 所有MVP GDD编写并评审完成后运行
    /gate-check pre-production