# Writing Plans

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

- Repository: https://github.com/jnMetaCode/superpowers-zh (8437 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add jnMetaCode/superpowers-zh --skill writing-plans -g -a claude-code -y`
Codex: `npx skills add jnMetaCode/superpowers-zh --skill writing-plans -g -a codex -y`
Cursor: `npx skills add jnMetaCode/superpowers-zh --skill writing-plans -g -a cursor -y`
Gemini CLI: `npx skills add jnMetaCode/superpowers-zh --skill writing-plans -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add jnMetaCode/superpowers-zh`

## Description

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 编写计划

## 概述

为一位没见过这个代码库、也没见过这份规格的工程师编写实现计划。假设他们一旦知道确切的接口和确切的测试，就能用项目所用的语言写出地道的代码；也假设在计划留出选择余地的地方，他们会做出合理的选择。他们无从知道的，是你已经决定了什么：哪些文件、哪些名字和签名、规格里的哪些取值、哪些测试证明每个任务。把这些记下来。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。

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

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

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

## 范围检查

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

## 文件结构

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

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

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

## 任务粒度定界

一个任务是**能独立承载自己那一轮测试循环、且值得一个全新审查者把关**的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个**可独立测试的交付物**结束。

## 步骤粒度

**每步是一个操作，并有一个可检查的结果：**
- "编写失败的测试" - 一步
- "运行它确认失败" - 一步
- "实现最少代码让测试通过" - 一步
- "运行测试确认通过" - 一步
- "Commit" - 一步

## 计划文档头部

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

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

> **面向 AI 代理的工作者：** 必需子技能：使用 subagent-driven-development（推荐）或 executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。

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

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

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

**规格：** [本计划所实现的规格 / 设计文档路径, , 计划的论证依据来自规格，所以规格要跟着计划一起走；执行者两份都读]


## 全局约束

[来自规格的项目级要求, , 版本下限、依赖限制、命名与文案规则、平台要求, , 每条一行，数值从规格里逐字照抄。每个任务的要求都隐含包含本节。]

## 审查重点（Review Focus）

[规格隐含了、但没有任何任务的测试覆盖到的输入类别或失败模式中，最可能伤到这个软件使用者的五个, , 每条一行，写明那个输入或条件，以及一个正常人会期待的行为，最可能的排最前。规格是一份愿景文档：它说软件必须做什么，而不是软件会遇到的一切；规格对某种输入没有提及，不等于允许这种输入把程序弄坏。趁规格就在眼前，在这里一次写完这份清单。然后针对每一行，把钉住它的那个测试，按那个任务自己的步骤写法，加进负责那段代码的任务里。]

---
```

## 任务结构

````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：运行测试验证失败**

The rest: https://github.com/jnMetaCode/superpowers-zh/blob/HEAD/skills/writing-plans/SKILL.md