创建架构决策记录（Architecture Decision Record, ADR），记录重大技术决策及其背景、备选方案和影响后果。每个重大技术选择都应有对应的 ADR。
根据描述创建结构化的缺陷报告，或分析代码以识别潜在缺陷。确保每份缺陷报告包含完整的复现步骤、严重程度评估和上下文信息。
通过分析复杂度、依赖关系、历史速度和风险因素来估算任务工作量。生成包含置信水平的结构化估算。
运行本地化工作流：提取字符串、验证本地化就绪状态、检查硬编码文本，并生成可供翻译的字符串表。
生成全面的里程碑进度审查，包括功能完成度、质量指标、风险评估和推进/暂停建议。在里程碑检查点或评估里程碑截止日期的准备情况时使用。
为新加入项目的贡献者或代理生成上下文感知的入职文档。总结项目状态、架构、规范以及与指定角色或领域相关的当前优先级。
| name | map-systems |
| description | 将游戏概念拆解为独立系统，映射依赖关系，确定设计优先级，并创建系统索引。 |
| argument-hint | [可选: 'next' 以选择最高优先级的未设计系统，或系统名称以交接给 /design-system] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite |
当此技能被调用时：
两种模式：
/map-systems — 运行完整的拆解工作流（阶段 1-5）以创建或更新系统索引。next：/map-systems next — 从索引中选择最高优先级的未设计系统并交接给 /design-system（阶段 6）。读取游戏概念和任何已有的设计工作。这为系统拆解提供了原始材料。
必需：
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] 个未开始）。您希望做什么？"
提取并识别游戏需要的所有系统。这是本技能的核心创意环节 — 它需要人工判断，因为概念文档很少明确列举每个系统。
扫描游戏概念中直接提及的系统和机制：
对于每个显式系统，识别它所暗示的隐藏系统。游戏需要的系统总是比概念文档中提到的多。使用以下推理模式：
在对话中解释为什么需要每个隐式系统（附示例）。
按类别组织展示枚举结果。对于每个系统，展示：
然后使用 AskUserQuestion 收集反馈：
迭代直到用户批准枚举结果。
对于每个系统，确定它依赖什么。如果系统 A 没有系统 B 就无法运行，则系统 A "依赖" 系统B。
对于每个系统，列出其依赖项。使用以下依赖启发式规则：
将系统排列为层级：
检查依赖图中的循环。如果发现：
以分层列表形式展示依赖图。高亮：
使用 AskUserQuestion 询问："这个依赖顺序看起来正确吗？是否有遗漏或应移除的依赖？"
根据每个系统所需的里程碑，将其分配到优先级层级。
使用以下启发式规则进行初始分配：
以表格形式展示优先级分配。对于每个层级，解释为什么将系统放在那里。
使用 AskUserQuestion 询问："这些优先级分配符合您的愿景吗？哪些系统应该更高或更低优先级？"
在对话中解释推理："我将 [系统] 放在 MVP 中，因为核心循环需要它 — 没有 [系统]，30 秒循环无法运行。"
结合依赖排序 + 优先级层级得出最终设计顺序：
这就是团队应该按此顺序编写 GDD 的顺序。
使用 .claude/docs/templates/systems-index.md 中的模板，用阶段 2-4 的所有数据填充系统索引：
展示文档摘要：
询问："可以将系统索引写入 design/gdd/systems-index.md 吗？"
等待批准。仅在 "同意" 后写入文件。
写入后，更新 production/session-state/active.md：
当以下情况进入此阶段：
/map-systems [system-name]/map-systems nextnext，选择最高优先级的未设计系统（按设计顺序）使用 AskUserQuestion 询问："现在开始设计 [系统名称]，选择其他系统，还是先停在这里？"
选择系统后，调用 /design-system [system-name] 技能。
/design-system 技能负责完整的 GDD 编写流程：
/design-review不要在这里重复 /design-system 的工作流。 此技能拥有系统索引；/design-system 拥有各系统GDD。
/design-system 完成后，使用 AskUserQuestion：
如果继续，返回步骤 6a。
系统索引创建后（或设计了一些系统后），建议适当的后续操作：
/design-system [系统名称] 编写下一个系统的 GDD"/design-review [路径] 以验证质量"/gate-check pre-production 检查是否准备好开始构建"/prototype [系统] 原型化最高风险的系统"/sprint-plan new 计划第一个实现 Sprint"本技能在每个阶段遵循协作设计原则：
AskUserQuestion（解释 -> 捕获模式）：
/design-system/design-system 负责，它处理增量部分写入、交叉引用、设计审查和索引更新production/session-state/active.md绝不要在未经审核的情况下自动生成完整系统列表并写入。 绝不要在未经用户确认的情况下开始设计系统。 始终展示枚举、依赖和优先级供用户验证。