# Writing Plans

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

- Skill: `tomorrowlm/writing-plans` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomorrowlm/writing-plans`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomorrowlm/writing-plans/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TomorrowLM (https://skillmd.com/u/tomorrowlm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomorrowlm/writing-plans

---


# 编写计划

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

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

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

**输出默认值：** 直接在当前会话中给出完整计划；只有用户明确要求落地到文件时，才保存为文档。

## 范围检查

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

## 文件结构

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

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

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

## 小步骤任务粒度

**每步是一个操作（2-5 分钟）：**
- "编写失败的测试" - 一步
- "运行它确认失败" - 一步
- "实现最少代码让测试通过" - 一步
- "运行测试确认通过" - 一步
- "更新任务状态或记录结果" - 一步

> **TDD 任务：** 包含测试先行的任务步骤时，执行阶段必须委托 `test-driven-development` 技能的红-绿-重构循环。计划中的步骤命名应与 TDD 技能的循环阶段一致（编写失败测试 → 验证红灯 → 最少实现 → 验证绿灯 → 重构）。

## 计划输出头部

**每个计划在会话中输出时，必须以此头部开始：**

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

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

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

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

---
```

## 任务结构

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

#### 目标

[一句话说明该任务完成后会交付什么]

#### 完成标准

- [可验证结果 1]
- [可验证结果 2]
- [可验证结果 3]

#### 涉及文件

- 创建：`exact/path/to/file.py`
- 修改：`exact/path/to/existing.py:123-145`

#### 实施步骤

#### 步骤 1：[动作标题]

说明：[先用一句话说明这一步要做什么，以及为什么现在做它。]

修改内容：

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

#### 步骤 2：运行验证并记录预期结果

运行命令：`pytest tests/path/test.py::test_specific_behavior -v`
预期：FAIL，报错 `[这里写明确的失败信号]`

#### 步骤 3：[最少实现动作]

说明：[先用一句话说明这一步会补上哪部分实现。]

修改内容：

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

#### 步骤 4：运行验证确认通过

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

#### 步骤 5：更新任务状态并记录结果

记录：[用一句话说明该任务已经完成到什么程度，哪些验证已通过，供后续执行阶段继续跟踪。]

**输出格式要求：**
- 每个任务必须按 `任务标题` → `目标` → `完成标准` → `涉及文件` → `实施步骤` 的顺序输出
- `目标`、`完成标准`、`涉及文件`、`实施步骤` 必须单独成段，不要写成一整段连续文本
- `完成标准` 必须使用项目符号列表，不要写成一句长句
- `涉及文件` 默认只列实际创建或修改的业务文件，不额外增加验证文件字段
- 每个步骤必须单独使用四级标题 `#### 步骤 N：[动作标题]`
- 每个步骤之间保留空行，避免挤成一段
- 涉及代码变更的步骤必须使用 `说明：` 和 `修改内容：` 两个固定字段
- 涉及验证的步骤必须使用 `运行命令：` 和 `预期：` 两个固定字段
- 涉及结果回写的步骤必须使用 `记录：` 字段

**推荐的步骤命名方式：**
- `步骤 1：编写失败的测试`
- `步骤 2：运行测试确认失败`
- `步骤 3：实现最少代码`
- `步骤 4：运行测试确认通过`
- `步骤 5：更新任务状态并记录结果`

如果某个任务不需要测试先行，也要保持同样的结构清晰度：步骤标题明确、命令明确、预期结果明确。

````

### 最后一个任务：用户手动测试与验收

如果计划面向页面、表单、弹窗、列表、交互流程或任何用户可见功能，最后一个任务默认应追加“用户手动测试与验收”，并使用下面的结构：

````markdown
### 任务 N+1：用户手动测试与验收

#### 目标

[让用户按明确清单手动检查结果，确认界面、交互和业务流程达到预期。]

#### 完成标准

- [用户知道测试入口或访问路径]
- [用户知道每个关键测试点要检查什么]
- [用户能够按清单逐项验收并反馈问题]

#### 涉及文件

- 修改：`src/pages/example.tsx`

#### 实施步骤

#### 步骤 1：给出手动测试入口

说明：[写清楚用户应该访问哪个页面、点击哪个入口、进入哪个模块。]

#### 步骤 2：列出核心测试点

说明：用户至少需要检查这些点：

- 页面或模块是否能正常打开
- 文案、标题、按钮、提示信息是否正确
- 关键交互是否正常，例如点击、切换、展开、关闭、提交
- 关键状态是否完整，例如默认态、禁用态、空态、错误态
- 是否存在明显视觉问题，例如错位、遮挡、溢出、闪动

#### 步骤 3：给出手动验收方式

说明：[写清楚用户如何记录结果，例如“通过/不通过 + 问题截图 + 复现步骤”。]

#### 步骤 4：更新验收结果记录

记录：[说明哪些点已由用户确认，哪些点还需要继续调整。]
````

如果任务是前端交付，可以在上面的基础上补充这些测试点：响应式、hover、loading、empty、error、键盘可达性和焦点顺序。

## 禁止占位符

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

## 注意事项
- 始终使用精确的文件路径
- 每个步骤都包含完整代码——如果步骤涉及代码变更，就展示代码
- 精确的命令和预期输出
- 默认直接输出计划内容，不要擅自创建或保存 md 文件
- DRY、YAGNI、TDD

## 自检

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

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

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

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

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


## 执行交接

完成计划后，先输出总结语，再列出执行方式让用户选择。

> 以上是完整计划，共 N 个任务。

如果用户没有要求保存文件，就直接基于当前会话中的计划内容进入执行交接；不要额外创建 md 文档。

### 执行方式

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

**2. cdoc + 子代理驱动** — 先读取 `skills/superpowers/skills/cdoc/SKILL.md` 并按其规则生成前端技术文档，再基于文档调度子代理执行

**3. 内联执行** — 在当前会话中使用 executing-plans 按顺序逐步执行

**4. cdoc + 内联执行** — 先读取 `skills/superpowers/skills/cdoc/SKILL.md` 并按其规则生成前端技术文档，再在当前会话中使用 executing-plans 执行

**选哪种方式？**

**如果选择子代理驱动（1 或 2）：**
- **可选执行方式：** 如果计划包含多个边界清晰、需要独立子智能体实现的任务，可使用 `superpowers:subagent-driven-development`；否则使用 `executing-plans`。
- 每个任务一个新子代理 + 两阶段审查
- 若选 2，先生成 cdoc 文档再调度子代理

**如果选择内联执行（3 或 4）：**
- **必需子技能：** executing-plans
- 把当前会话里的计划作为执行输入，不要求额外保存 md 文件
- 先把计划中的"任务 N"重建为 TodoWrite 或复选框清单，再从第一个未完成任务开始执行
- 严格按任务顺序推进；完成一个任务的验证后，才能进入下一个任务
- 不要只因为用户最后提到某个具体改动，就跳过前面的任务直接实现
- 若选 4，先生成 cdoc 文档再开始执行