create-architecture

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,docs.density

已在上方解析——按原样使用；--review 会覆盖 review_mode。无块 → 默认值见 .claude/docs/config-resolution.md。

创建架构

此技能会生成 docs/architecture/architecture.md——主架构文档，将所有已批准的 GDD 转化为具体的技术蓝图。 它位于设计与实现之间，必须在开始规划 sprint 之前创建。

与 /architecture-decision 的区别：ADR 记录单个决策点。 此技能创建整个系统的蓝图，为 ADR 提供背景。

完整的检查模式请参见 .claude/docs/director-gates.md。各个门禁定义位于 .claude/docs/director-gates/[gate-id].md——启动的 Agent 会读取自己的门禁文件；父会话不要读取该文件。

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （collaborative 始终提问 · guided 仅在重大事项上提问 · autonomous 记录后继续； automation_always_ask 类别始终提示）。

docs.density——它控制各个章节的深度，而 workflow 控制哪些章节存在。modes.rigor 会同时设置两者；若只想调整深度，请显式设置 docs.density：terse（默认值，通过 rigor: minimal 设置）= 分层图 + 决策要点， 不写长篇说明；balanced = 图示 + 对层级选择的段落说明 （rigor: standard）；thorough = 完整文字说明，涵盖各层的理由、权衡和 考虑过的替代方案。对你编写的每个章节都应用此设置。

workflow（参见 .claude/docs/workflow-modes.md）：

• full — 完整架构：所有层级、模块所有权、数据流、API 边界、完整 ADR 审查。
• standard — 简化版：仅系统层级图和关键 ADR 列表。
• minimal — 非必需。仍可自愿运行。

参数模式：

• 无参数 / full：完整的引导式流程——从头到尾涵盖所有章节
• layers：仅聚焦于系统分层图
• data-flow：仅聚焦于模块间的数据流
• api-boundaries：仅聚焦于 API 边界定义
• adr-audit：仅审查现有 ADR 中与引擎兼容性相关的缺漏

---

阶段 0：加载所有上下文

现在读取 references/0-load-context.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 1：系统分层映射

现在读取 references/1-layers.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 2：模块所有权映射

现在读取 references/2-module-ownership.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 3：数据流

现在读取 references/3-data-flow.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 4：API 边界

现在读取 references/4-api-boundaries.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 5：ADR 审查 + 可追溯性检查

现在读取 references/5-adr-audit.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 6：缺失 ADR 列表

现在读取 references/6-missing-adrs.md 并遵循其中说明——本阶段的步骤位于该文件中，而非此处。如果对话在本阶段被压缩或恢复，请重新读取该文件。

阶段 7：编写主架构文档

现在阅读 references/7-write.md 并遵循其中的说明——本阶段的步骤在该文件中，而不在此处。如果在本阶段对话被压缩或恢复，请再次阅读该文件。

阶段 8：交接

现在阅读 references/8-handoff.md 并遵循其中的说明——本阶段的步骤在该文件中，而不在此处。如果在本阶段对话被压缩或恢复，请再次阅读该文件。

协作协议

适用于 collaborative 模式（默认模式）。 有关 guided 和 autonomous 模式，请参阅 .claude/docs/automation-modes.md——以下规则 说明了协作模式的要求，并非通用行为。

此技能在每个阶段都遵循协作设计原则：

1. 静默加载上下文——不要叙述文件读取过程
2. 展示发现——展示知识缺口清单和分层提案
3. 决策前先询问——针对每项架构选择提供选项
4. 先起草，再审批——在询问是否写入前，先在行内展示内容。 不要要求用户审批其尚未看过的章节。
5. 使用 AskUserQuestion 请求写入审批——仅用纯文本询问“可以吗？”并不足够。使用带有已标注选项 [A]/[B]/[C]（立即写入 / 先展示完整草稿 / 暂不写入）的结构化工具。对于多文件变更集，列出每个文件及其变更内容，然后集中询问一次——不要针对每个文件分别用纯文本询问。
6. 所有章节获批后再一次性写入——文档只在阶段 7 写入； 阶段 7b 的步骤 4 仅在其自身询问后更新文档状态。在进行过程中，将每个已获批章节的决策记录到 production/session-state/active.md，以免崩溃导致决策丢失。 阶段 7b 要求的修订也以相同方式写入——仅在其重新起草的章节获批后一次性写入；而更新（阶段 0e）只写入其选定的章节。

未经用户输入，绝不做出具有约束力的架构决策。如果用户拿不定主意，先提供 2-4 个选项及其优缺点，再请用户决定。

---

建议的后续步骤

• 对阶段 6 中列出的每项必需 ADR 运行 /architecture-decision [title]——优先处理基础层 ADR
• 运行 /architecture-review——从刚编写的 ADR 初始化需求可追溯矩阵和 TR 注册表，并为每个临时 TR-ID 分配永久 ID。在预生产门禁前必须完成。
• 运行 /test-setup，以搭建 tests/unit/、tests/integration/、CI 工作流和示例测试（门禁检查所必需）
• 运行 /ux-design，以初始化 design/ux/interaction-patterns.md 和 design/accessibility-requirements.md（门禁检查所必需）
• 编写必需的 ADR 后，运行 /create-control-manifest 以生成分层规则清单
• 完成所有必需的 ADR、/test-setup 和 /ux-design 后，运行 /gate-check pre-production