writing-plans

编写计划

概述

编写全面的实现计划，假设工程师对我们的代码库零上下文且品味可疑。记录他们需要知道的一切：每个任务要触及哪些文件、代码、测试、可能需要查看的文档、如何测试。将整个计划分解为小任务。DRY。YAGNI。TDD。频繁提交。

假设他们是熟练的开发者，但对我们的工具集或问题领域几乎一无所知。假设他们不太擅长良好的测试设计。

开始时声明： “我正在使用编写计划技能来创建实现计划。”

上下文： 如果在隔离的工作树中工作，该工作树应在执行时通过 superpowers:using-git-worktrees 技能创建。

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

• （用户对计划位置的偏好会覆盖此默认值）

范围检查

如果规格涵盖多个独立的子系统，应在头脑风暴期间将其分解为子项目规格。如果没有，建议将其分解为多个单独的计划——每个子系统一个。每个计划应独立产生可工作、可测试的软件。

文件结构

在定义任务之前，规划哪些文件将被创建或修改，以及每个文件负责什么。这是分解决策被锁定的地方。

• 设计具有清晰边界和良好定义接口的单元。每个文件应有一个明确的职责。
• 你最能推理的是能一次在上下文中容纳的代码，当文件专注时，你的编辑更可靠。优先选择较小、专注的文件，而不是过大、做太多事情的文件。
• 一起变化的文件应放在一起。按职责拆分，而不是按技术层。
• 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果正在修改的文件变得笨重，在计划中包含拆分是合理的。

此结构为任务分解提供信息。每个任务应产生自包含的更改，独立有意义。

小任务粒度

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

• “编写失败的测试” - 步骤
• “运行以确保它失败” - 步骤
• “实现使测试通过的最小代码” - 步骤
• “运行测试并确保通过” - 步骤
• “提交” - 步骤

计划文档头部

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

# [功能名称] 实现计划

> **对于代理工作者：** 必需的子技能：使用 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: 提交**

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

无占位符

每个步骤必须包含工程师需要的实际内容。以下是计划失败——永远不要写：

• “待定”、“TODO”、“稍后实现”、“填写细节”
• “添加适当的错误处理” / “添加验证” / “处理边界情况”
• “为上述内容编写测试”（没有实际测试代码）
• “类似于任务 N”（重复代码——工程师可能按顺序阅读任务）
• 描述要做什么但不展示如何做的步骤（代码步骤需要代码块）
• 引用任何任务中未定义的类型、函数或方法

记住

• 始终使用精确的文件路径
• 每个步骤中的完整代码——如果步骤更改代码，展示代码
• 精确的命令及预期输出
• DRY、YAGNI、TDD、频繁提交

自我审查

编写完整计划后，以全新视角查看规格，并对照计划检查。这是你自己运行的检查清单——不是子代理调度。

1. 规格覆盖： 浏览规格中的每个部分/需求。你能指出实现它的任务吗？列出任何差距。

2. 占位符扫描： 在你的计划中搜索红旗——上面“无占位符”部分中的任何模式。修复它们。

3. 类型一致性： 你在后续任务中使用的类型、方法签名和属性名称是否与你在早期任务中定义的一致？在任务3中称为 clearLayers() 但在任务7中称为 clearFullLayers() 的函数是一个错误。

如果发现问题，就地修复。无需重新审查——只需修复并继续。如果发现规格需求没有对应任务，添加该任务。

执行交接

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

“计划完成并保存到 docs/superpowers/plans/<filename>.md。两个执行选项：

1. 子代理驱动（推荐） - 我为每个任务派遣一个全新的子代理，在任务之间进行审查，快速迭代

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

选择哪种方法？

如果选择子代理驱动：

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

如果选择内联执行：

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