writing-plans

name	writing-plans
description	当你有规格或需求需要进行多步骤任务时使用，在动代码之前

编写计划

概述

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

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

开始时声明："我正在使用 writing-plans skill 来创建实现计划。"

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

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

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

范围检查

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

文件结构

在定义任务之前，先映射出将要创建或修改的文件及其各自的职责。这是分解决策被锁定的地方。

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

此结构指导任务分解。每个任务应该产出独立有意义的自包含变更。

细粒度任务粒度

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

• "编写失败测试" — 一步
• "运行它确认失败" — 一步
• "实现最少代码使测试通过" — 一步
• "运行测试确认通过" — 一步
• "提交" — 一步

计划文档头部

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

# [功能名称] 实现计划

> **给代理工作者：** 必须调用的子 skill：使用 subagent-driven-development（推荐）或 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"
```

要点

• 始终使用精确文件路径
• 计划中包含完整代码（不是"添加验证"）
• 精确命令及预期输出
• 用 @ 语法引用相关 skill
• DRY、YAGNI、TDD、频繁提交

计划评审循环

编写完整计划之后：

1. 派遣一个 plan-document-reviewer 子代理（见 plan-document-reviewer-prompt.md），附带精心构造的评审上下文——不传递你的会话历史。这让评审者专注于计划而非你的思考过程。
   • 提供：计划文档路径、规格文档路径
2. 如果 ❌ 发现问题：修复问题，重新派遣评审者评审整个计划
3. 如果 ✅ 通过：进入执行交接

评审循环指南：

• 编写计划的同一代理修复它（保留上下文）
• 如果循环超过 3 次迭代，交给用户处理
• 评审者是建议性的——如果你认为反馈不正确，解释你的分歧

执行交接

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

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

1. 子代理驱动（推荐） — 每个任务派遣全新子代理，任务间评审，快速迭代

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

选择哪种方案？"

如果选择子代理驱动：

• 必须调用的子 skill： 使用 subagent-driven-development
• 每任务全新子代理 + 两阶段评审

如果选择内联执行：

• 必须调用的子 skill： 使用 executing-plans
• 批量执行附带评审检查点