Menu
将游戏概念拆解为独立系统，映射依赖关系，确定设计优先级，并创建系统索引。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
创建架构决策记录（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绝不要在未经审核的情况下自动生成完整系统列表并写入。 绝不要在未经用户确认的情况下开始设计系统。 始终展示枚举、依赖和优先级供用户验证。