name: 编写计划 description: 当用户有一个设计（来自头脑风暴）时，应使用此技能，以将其分解为详细的、分步的实施计划，每个任务都包含验证步骤。 argument-hint: [设计文件夹路径] user-invocable: true version: 1.3.0

编写计划

创建可执行的实施计划，减少执行者的模糊性。

解析设计路径：
- 如果 $ARGUMENTS 提供了一个路径（例如，docs/plans/YYYY-MM-DD-topic-design/），则将其用作设计源。
- 如果没有提供参数：
  - 在 docs/plans/ 中搜索最新的 *-design/ 文件夹，匹配模式 YYYY-MM-DD-*-design/
  - 如果找到，向用户确认：“使用此设计：[路径]？”
  - 如果没有找到或用户拒绝，则向用户询问设计文件夹路径。
设计检查：验证文件夹包含 _index.md 和 bdd-specs.md。
上下文：完全阅读 bdd-specs.md。这是您任务的真相来源。

核心概念：显式优于隐式，粒度任务，验证驱动，上下文独立。禁止：不要生成实际代码 - 关注要做什么，而不是实现细节。

定义目标、架构、约束。

分解为小任务，映射到特定的BDD场景。

参考场景：关键：每个任务必须明确参考一个BDD场景（例如，“实施登录（参考：场景1）”）。
定义验证：关键：验证步骤必须运行BDD规格（例如，npm test tests/login.spec.ts）。
强制执行顺序：任务N（测试/红） -> 任务N+1（实施/绿）。
声明依赖：强制：每个任务文件必须包括一个 **depends-on** 字段，仅列出真正的技术先决条件——需要其输出才能开始此任务的任务。规则：
- 特性X的测试任务（红）不依赖于其他特性的测试任务
- 实施任务（绿）仅依赖于其配对的测试任务（红），而不是其他特性的实施
- 默认情况下，触及不同文件并测试不同场景的任务是独立的
- 禁止：不要仅为了强加执行顺序而链式任务——仅在有真正技术原因时使用 depends-on（例如，“实施身份验证中间件”必须先于“实施受保护路由测试”）
确保兼容性：确保任务与 superpowers:behavior-driven-development 兼容。
创建任务文件：强制：为每个任务创建一个 .md 文件。文件名模式：task-<NNN>-<short-description>.md。
描述什么，而不是如何：禁止：不要生成实际代码。描述要实施什么（例如，“创建一个验证用户凭据的函数”），而不是实施（例如，“def validate_credentials(username, password): …”）。

验证完整性，与用户确认，并保存。

验证：检查有效的提交边界和没有模糊任务。
确认：获得用户对计划的批准。
保存：写入 docs/plans/YYYY-MM-DD-<topic>-plan/ 文件夹。
- 关键：_index.md 必须包括“执行计划”部分，引用所有任务文件
- 示例：- [任务001：设置](./task-001-setup.md)

将计划文件夹提交到git，使用适当的消息格式。

参见 ../../skills/references/git-commit.md 以获取详细模式、提交消息模板和要求。

关键要求：

目标：无缝过渡到执行计划。

操作：

计划创建时具有清晰的目标/约束，分解的任务包含文件列表和验证，BDD步骤，提交边界，没有模糊任务，用户批准。