---
name: writing-plans
description: 用于在开始编码前，当已有规格说明或需求文档需要执行多步骤任务时使用
---

# 编写实施计划

## 概述

编写全面的实施计划，假设执行工程师对我们代码库毫无背景知识且品味存疑。记录他们需要了解的一切：每个任务需要修改哪些文件、代码、测试、可能需要查阅的文档，以及如何测试。将整个计划拆解为易于消化的小任务。遵循 DRY（Don't Repeat Yourself，不要重复自己）、YAGNI（You Ain't Gonna Need It，你不需要它）、TDD（Test-Driven Development，测试驱动开发）原则，并频繁提交。

假设他们是有经验的开发者，但几乎不了解我们的工具集或问题领域。假设他们对良好的测试设计掌握得不够好。

**开始时声明：** "我正在使用 writing-plans 技能来创建实施计划。"

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

**计划保存至：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
- （用户对计划保存位置的偏好可覆盖此默认值）

## 范围检查

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

## 文件结构

在定义任务之前，先规划好哪些文件将被创建或修改，以及每个文件的职责。这是确定分解决策的环节。

- 设计具有清晰边界和明确定义接口的单元。每个文件应有一个明确的职责。
- 你最能推理的代码是你一次能在上下文中容纳的代码，当文件专注时你的编辑更可靠。倾向于更小、更专注的文件，而非臃肿的大文件。
- 经常一起变更的文件应放在一起。按职责拆分，而非按技术层拆分。
- 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得臃肿，在计划中包含拆分是合理的。

此结构为任务分解提供依据。每个任务应产生自包含的变更，可独立理解。

## 易于消化的小任务粒度

**每一步是一个动作（2-5 分钟）：**
- "编写失败的测试"——一步
- "运行测试以确保它失败"——一步
- "实现最简代码让测试通过"——一步
- "运行测试并确保它们通过"——一步
- "提交"——一步

## 计划文档头部

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

```markdown
# [功能名称] 实施计划

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

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

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

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

---
```

## 任务结构

````markdown
### 任务 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"
```
````

## 禁止留白

每一步都必须包含工程师所需的实际内容。以下属于**计划失败**——永远不要写出这些内容：
- "待定"、"待办"、"稍后实现"、"补充细节"
- "添加适当的错误处理"/"添加验证"/"处理边界情况"
- "为上述内容编写测试"（没有实际的测试代码）
- "与任务 N 类似"（重复代码——工程师可能不按顺序阅读任务）
- 只描述要做什么而不展示如何做的步骤（代码步骤必须包含代码块）
- 引用任何任务中未定义的类型、函数或方法

## 注意事项
- 始终使用精确的文件路径
- 每一步都要有完整代码——如果某步修改了代码，要展示代码
- 精确的命令及其预期输出
- 遵循 DRY（Don't Repeat Yourself，不要重复自己）、YAGNI（You Ain't Gonna Need It，你不需要它）、TDD（Test-Driven Development，测试驱动开发）原则，并频繁提交

## 自我审查

编写完整计划后，以全新的视角审视规格说明，并对照检查计划。这是你需要自己执行的检查清单——不是交给子代理的任务。

**1. 规格覆盖：** 浏览规格说明中的每个章节/需求。能否指出实现了该需求的任务？列出任何缺口。

**2. 禁止留白扫描：** 检查计划中的危险信号——上述"禁止留白"部分列出的任何模式。修复它们。

**3. 类型一致性：** 你在后续任务中使用的类型、方法签名和属性名称是否与你之前任务中定义的一致？任务 3 中名为 `clearLayers()` 但在任务 7 中变成 `clearFullLayers()` 的函数就是一个缺陷。

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

## 执行交接

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

**"计划已完成并保存至 `docs/superpowers/plans/<filename>.md`。有两种执行方式可选：**

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

**2. 内联执行** - 在当前会话中使用 executing-plans 技能执行任务，分批执行并设置检查点

**选择哪种方式？"**

**如果选择了子代理驱动：**
- **必须使用的子技能：** 使用 superpowers:subagent-driven-development
- 每个任务使用全新子代理 + 两阶段审查

**如果选择了内联执行：**
- **必须使用的子技能：** 使用 superpowers:executing-plans
- 分批执行，设置检查点以供审查