writing-plans

name	writing-plans
description	当已经有明确规格、需求或多步骤实现目标时使用，用来拆成可执行计划。不要作为普通 bug 修复、小改动或日常执行的默认入口；不要假设必须使用未安装的 superpowers execution skills。在 OpenCode 中，计划应交接给当前可用的 todo、task、验证命令和最小改动流程。
version	1.0.0
license	MIT
metadata	{"hermes":{"tags":["planning","documentation"]}}

Usage Rule

Use this skill on demand for implementation planning, not as the default entry for every coding task.

Trigger it when the task clearly involves one of these goals:

• Turning an approved spec or clear multi-step requirement into an implementation plan
• Coordinating several files, phases, or dependencies before coding
• Creating a handoff document for another agent or future session
• Breaking a medium or large project into verifiable steps

Do not trigger it for:

• A single straightforward code edit
• Routine bug fixes where the next step is root-cause debugging
• Small refactors that can be handled directly with a todo list
• Tasks where the user asked to implement now rather than write a plan

OpenCode compatibility:

• Do not require superpowers:subagent-driven-development or superpowers:executing-plans unless those skills are actually installed and available
• If the upstream workflow mentions missing execution skills, translate the handoff into OpenCode-native execution: todowrite, task when useful, direct edits, and verification commands
• Do not create or commit plan documents by default unless the user asked for a saved plan or the task genuinely needs a durable handoff

编写计划

概述

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

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

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

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

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

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

范围检查

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

文件结构

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

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

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

小步骤任务粒度

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

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

计划文档头部

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

# [功能名称] 实现计划

> **面向 AI 代理的工作者：** 按下述任务清单逐项执行；进度用复选框（`- [ ]`）跟踪。每个任务完成后运行对应的验证命令并核对预期输出，再进入下一项。

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

**架构：** [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"
```

禁止占位符

每个步骤都必须包含工程师需要的实际内容。以下是计划缺陷——绝不要写出来：

• "待定"、"TODO"、"后续实现"、"补充细节"
• "添加适当的错误处理" / "添加验证" / "处理边界情况"
• "为上述代码编写测试"（没有实际测试代码）
• "类似任务 N"（重复代码——工程师可能不按顺序阅读任务）
• 只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）
• 引用了未在任何任务中定义的类型、函数或方法

注意事项

• 始终使用精确的文件路径
• 每个步骤都包含完整代码——如果步骤涉及代码变更，就展示代码
• 精确的命令和预期输出
• DRY、YAGNI、TDD、频繁 commit

自检

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

1. 规格覆盖度： 浏览规格中的每个章节/需求。你能指出实现它的任务吗？列出所有遗漏。

2. 占位符扫描： 搜索计划中的红旗——上方"禁止占位符"章节中的任何模式。修复它们。

3. 类型一致性： 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 clearLayers() 但任务 7 中叫 clearFullLayers() 就是 bug。

如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。

执行交接

保存计划后，按当前 agent 环境可用的方式逐任务推进，不要假设某个特定的执行子 skill 必须存在：

• 用当前 agent 自带的任务清单 / todo 机制把计划落地为可勾选的进度（如果有这种工具的话）
• 如果当前 agent 支持子任务分发，可以一个子任务调度一个独立 agent 跑单步，跑完再回到主会话审查
• 不支持时直接在当前会话内顺序执行，每步用计划里指定的命令验证，验证通过再进下一步
• 是否在每步之间 commit，按用户偏好或项目 commit 策略决定，不要默认 commit

如果 agent 环境装了专用的执行链 skill（例如 superpowers:subagent-driven-development 或 superpowers:executing-plans），可以用，但不是必需的。