从想法到规范
帮助用户将想法转化为可供规划使用的规范。由你主导对话；用户提供答案。
产物与状态
- 每个工作项存放在
docs/specs/<YYYYMMDD>-<类型>-<名称>/目录下。类型遵循 Conventional Commits（feat,fix,refactor,docs……），名称使用 kebab-case。如果该目录已存在，追加-2。 spec.md和plan.md在前置元数据中包含status: draft | approved | obsolete。只有用户才能将状态设置为approved。- 如果你修改了已批准的产物，请将其状态重置为
draft并告知用户。 - 工作管理（优先级、负责人、完成状态）不属于本技能的职责范围：这些信息应存在于跟踪系统中。如果存在关联 Issue，其编号应填写在
issue:字段中。
行为
- 首先用一段简短的话总结想法。
- 识别出编写优秀规范所缺少的信息，并提出最少数量的有用问题，优先处理阻塞性问题。
- 聚焦于“做什么”和“为什么做”，而不是“如何做”：除非用户主动要求，否则不涉及框架或架构。这部分属于
spec-to-plan技能的范畴。 - 如果
docs/ARCHITECTURE.md文件存在，请阅读它以使用其中的术语词汇，并避免与原则冲突。
各轮问题
- 问题与预期成果。
- 用户与参与者。
- 用户故事（每个角色需要什么以及为什么）。
- 范围内的内容与不包含的内容。
- 行为与边界条件：空数据、无效数据或海量数据；外部依赖故障；并发操作。
- 非功能性约束。
- 安全性，如果涉及数据、认证或外部输入：数据敏感性，谁可以做什么，哪些输入不可信，需要哪些负面测试。
- 验收条件（“给定……，当……，那么……”）。
如果某一轮结束后仍有歧义，仅针对该部分进行追问。
未解决的问题
永远不要默默假设答案。 对于每个未解决的问题：
[问题]
- A) [你的默认建议，如果有的话]
- B) [明显的替代方案]
- C) 将其作为未决问题保留在规范中
- D) 其他答案
只有当用户回答或选择将其保持开放时，该问题才算解决。
每条回复的格式：我所理解的 · 待解决的问题 · 下一步。
规模
根据变更的复杂程度调整深度。先提出路径，让用户决定：
| 变更类型 | 产物 |
|---|---|
| 单行 bug | 无需，或只需 tasks.md |
| 复杂 bug | spec.md + tasks.md |
| 小功能 | spec.md + plan.md + tasks.md |
| 生产级功能或架构重构 | 全部，包括规范和计划的审查 |
何时停止
当规范已包含以下内容时停止：目标、问题、用户、用户故事、范围内与范围外、功能与非功能需求、边界条件以及验收标准。
然后：
- 提议目录名称，并从
assets/spec-template.md生成spec.md草稿，状态为draft。删除不适用的可选章节。 - 展示草稿，并在用户批准后方才写入。
- 建议的下一步：使用
review-spec进行评审。如果变更较小且用户认可，用户可以将其标记为approved并进入spec-to-plan阶段。