writing-plans

name	writing-plans
description	当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前

编写计划

概述

编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。

假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。

开始时宣布： "我正在使用 writing-plans 技能创建实现计划。"

上下文： 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。

计划保存位置： docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md

• （用户对计划位置的偏好优先于此默认值）

范围检查

如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。

文件结构

在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。

• 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。
• 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。
• 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。
• 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以管理，在计划中包含拆分是合理的。

此结构决定了任务分解。每个任务应产出独立的、有意义的变更。

小步骤任务粒度

每步是一个操作（2-5 分钟）：

• "编写失败的测试" - 一步
• "运行它确认失败" - 一步
• "实现最少代码让测试通过" - 一步
• "运行测试确认通过" - 一步
• "Commit" - 一步

计划文档头部

每个计划必须以此头部开始：

# [功能名称] 实现计划

> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers:executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。

**目标：** [一句话描述要构建什么]

**架构：** [2-3 句话描述方案]

**技术栈：** [关键技术/库]

---

任务结构

### 任务 N：[组件名称]

**文件：**
- 创建：`exact/path/to/file.py`
- 修改：`exact/path/to/existing.py:123-145`
- 测试：`tests/exact/path/to/test.py`

- [ ] **步骤 1：编写失败的测试**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

- [ ] **步骤 2：运行测试验证失败**

运行：`pytest tests/path/test.py::test_name -v`
预期：FAIL，报错 "function not defined"

- [ ] **步骤 3：编写最少实现代码**

```python
def function(input):
    return expected
```

- [ ] **步骤 4：运行测试验证通过**

运行：`pytest tests/path/test.py::test_name -v`
预期：PASS

- [ ] **步骤 5：Commit**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```

注意事项

• 始终使用精确的文件路径
• 计划中包含完整代码（而非"添加验证"）
• 精确的命令和预期输出
• 使用 @ 语法引用相关技能
• DRY、YAGNI、TDD、频繁 commit

计划审查循环

编写完整计划后：

1. 调度一个 plan-document-reviewer 子代理（参见 plan-document-reviewer-prompt.md），提供精心组织的审查上下文——绝不是你的会话历史。这样可以让审查员专注于计划本身，而非你的思考过程。
   • 提供：计划文档路径、规格文档路径
2. 如果发现问题：修复问题，重新调度审查员审查整个计划
3. 如果通过：进入执行交接

审查循环指南：

• 编写计划的同一个代理负责修复（保留上下文）
• 如果循环超过 3 次迭代，交给人工指导
• 审查员是顾问性质的——如果你认为反馈不正确，可以解释你的理由

执行交接

保存计划后，提供执行选项：

"计划已完成并保存到 docs/superpowers/plans/<filename>.md。两种执行方式：

1. 子代理驱动（推荐） - 每个任务调度一个新的子代理，任务间进行审查，快速迭代

2. 内联执行 - 在当前会话中使用 executing-plans 执行任务，批量执行并设有检查点

选哪种方式？"

如果选择子代理驱动：

• 必需子技能： 使用 superpowers:subagent-driven-development
• 每个任务一个新子代理 + 两阶段审查

如果选择内联执行：

• 必需子技能： 使用 superpowers:executing-plans
• 批量执行并设有检查点供审查