spec-architect

name	spec:architect
description	Use when converting a spec into an actionable implementation plan with file manifests, phased checkbox steps, and code snippets - triggers on /spec:architect, 写 plan, 实施计划, 架构计划

实施计划工作流 (Architect)

将 spec.md 转化为可逐步执行的实施计划 plan.md，包含文件清单、分步复选框、阶段分组和代码片段。

产物: specs/[feature_name]/plan.md 前置: 必须先有 specs/[feature_name]/spec.md（由 /spec:define 生成）

⚠️ 交付标准（写之前必读）

你生成的 plan.md 必须同时满足以下指标，任何一项不通过禁止提交：

#	检查项	合格标准
1	文件清单表格	包含所有涉及文件、所属层级、改动性质（新增/修改/删除）的 Markdown 表格
2	分步实施复选框	每个步骤都使用 - [ ] 复选框格式
3	阶段分组	步骤按阶段分组（A: 代码修改 → B: 编译验证 → C: 文档更新）
4	层级标签	每个步骤标注 [Frontend] / [Backend] / [Build] / [Docs]
5	编译验证步骤	必须包含 npm run build 编译验证步骤
6	文档更新步骤	必须包含 UPDATE_LOG.md 更新步骤
7	代码片段	关键改动步骤必须附带代码片段（改动前 → 改动后），不能只写"修改 xxx"

执行指令

1. 阅读规范

• 加载 specs/[feature_name]/spec.md
• 逐章阅读，提取：根因分析结论、修复方案细节、涉及文件清单、边界情况
• 如 spec.md 不存在，提示用户先运行 /spec:define

2. 起草计划

• 仅创建/更新一个文件: specs/[feature_name]/plan.md
• 语言要求: 所有输出及文件内容必须使用简体中文
• 严禁创建 tasks.md，所有任务保留在 plan.md 中

3. 文档结构

3.1 架构设计

• 文件清单表格：列出所有涉及文件、所属层级、改动性质、一句话说明
• 架构影响评估：简述数据模型/状态管理/通信链路的影响。如无架构变更，用 > [!NOTE] 声明"本次改动不涉及架构变更"
• 关键流程图：如涉及多组件交互或状态流转，用 Mermaid 图或 ASCII 图展示

3.2 分步实施

按阶段分组，推荐模板：

### 阶段 A: 代码修改
- [ ] [Frontend] 步骤描述...

### 阶段 B: 编译验证
- [ ] [Build] 执行 `npm run build` 确认编译通过

### 阶段 C: 文档更新
- [ ] [Docs] 更新 `UPDATE_LOG.md`

• 关键步骤必须附代码片段：涉及新增/修改代码的步骤，用 fenced code block 给出改动前后对比或最终代码
• 步骤粒度：每个步骤应为一个可独立完成的原子操作。描述超过 3 行即拆分

4. 出厂自检

创建 plan.md 后，回复用户在末尾输出以下自检表：

| 检查项 | 要求 | 实际 | 达标 |
|--------|------|------|------|
| 文件清单表格 | 有 | 有/无 | ✅/❌ |
| 复选框步骤数 | ≥ 3 | ? | ✅/❌ |
| 阶段分组 | 有 | 有/无 | ✅/❌ |
| 层级标签 | 有 | 有/无 | ✅/❌ |
| 编译验证步骤 | 有 | 有/无 | ✅/❌ |
| 文档更新步骤 | 有 | 有/无 | ✅/❌ |
| 代码片段 | ≥ 1 | ? | ✅/❌ |

5. 输出结果

• 向用户展示创建的 plan.md 摘要
• 总结实施步骤数及预计改动范围
• 末尾附带上述自检表
• 提示用户：下一步运行 /spec:execute 开始逐步执行，或运行 /spec:refactor 先做代码审计