open-spec-propose

提出一项新变更并创建可选的工作文档。

我会创建一项变更，并包含以下文档：

• proposal.md（内容与原因）
• design.md（实现方式）
• tasks.md（实施步骤）

准备好实施时，请使用 open-spec-apply 技能

---

输入：用户的请求应包含一个变更名称（kebab-case）或对想要构建内容的描述。

步骤

1. 如果没有提供明确输入，请询问用户想要构建什么

   使用 AskUserQuestion 工具（开放式提问，不提供预设选项）询问：

   “你想开展什么变更？请描述你想构建或修复的内容。”

   根据用户的描述，提炼出一个 kebab-case 名称（例如，“添加用户身份验证” → add-user-auth）。

   重要：在了解用户想要构建什么之前，不要继续。

2. 创建变更目录

   创建 specs/changes/<name>/。

   specs/changes/ 已加入 gitignore。它是可选的工作流脚手架。只有 specs/features/ 是规范且受版本控制的。

3. 创建工作文档

   使用 TodoWrite 工具跟踪进度。

   创建：

   • proposal.md：问题、目标、非目标、范围
   • design.md：架构、决策、权衡、边界
   • tasks.md：带复选框的具体实施步骤

   文档规则：

   • 如有助于交付，可结合技术细节编写。
   • 确保内容符合 AGENTS.md 和已启用的能力文档。
   • 将 specs/features/ 作为规范行为基准。
   • 如果变更会修改现有行为，请引用受影响的规范。
   • 如果用户已经提供了足够的细节，直接编写文档，不要继续追问。

4. 确保变更已准备好实施

   完成前，请确认：

   • proposal.md 说明了变更的原因。
   • design.md 说明了预期方案和边界。
   • tasks.md 包含按顺序排列的执行计划。
   • 变更名称和文档足够具体，open-spec-apply 技能可以据此执行。

输出

创建完所有文档后，总结：

• 变更名称和位置
• 创建的文档列表及简要说明
• 准备情况：“所有文档均已创建！可以开始实施。”
• 提示：“使用 open-spec-apply 技能实施。完成后，使用 open-spec-complete 技能同步 specs/features/ 并清理这些临时文档。”

注意事项

• 除非用户明确要求减少文档，否则必须创建全部三份核心文档
• 如果上下文存在关键性歧义，请询问用户；但优先做出合理判断，保持进度
• 如果该名称的变更已存在，请询问用户是要继续处理，还是创建一个新的变更
• 写入后请确认每份文档都存在，再继续下一步
• 切勿将工作文档视为规范文档