# Plan Writing

> 结构化任务规划能力。强调清晰拆解、依赖关系与可验证标准。适用于功能实现、重构与多步骤工作。

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

---


# 计划编写

> 来源：obra/superpowers

## 概览
该技能提供一套框架，用于将工作拆解为清晰、可执行、可验证的任务。

## 任务拆解原则

### 1. 小而聚焦的任务
- 每个任务建议控制在 2-5 分钟内
- 每个任务只对应一个明确结果
- 每个任务都应可独立验证

### 2. 明确的验证标准
- 如何判断它已经完成？
- 可以检查/测试什么？
- 预期输出是什么？

### 3. 合理的执行顺序
- 识别任务依赖关系
- 尽可能并行执行
- 标出关键路径（Critical Path）
- **阶段 X：验证（Verification）永远放在最后**

### 4. 在项目根目录动态命名
- 计划文件保存为项目根目录下的 `{task-slug}.md`
- 文件名由任务语义派生（例如“添加鉴权” -> `auth-feature.md`）
- **绝不能**放在 `.claude/`、`docs/` 或临时目录中

## 规划原则（不是模板）

> [CRITICAL]  **不要使用固定模板。每份计划都必须匹配当前任务。**

### 原则 1：保持简洁

| [FAIL]  错误 | [OK]  正确 |
|---------|---------|
| 50 个任务并含多层子任务 | 最多 5-10 个清晰任务 |
| 罗列所有微步骤 | 只保留可执行项 |
| 描述冗长 | 每个任务一行说明 |

> **规则：** 如果计划超过 1 页，通常就过长了。请继续精简。

---

### 原则 2：具体，不要泛化

| [FAIL]  错误 | [OK]  正确 |
|---------|---------|
| “搭建项目” | “运行 `npx create-next-app`” |
| “添加鉴权” | “安装 next-auth，并创建 `/api/auth/[...nextauth].ts`” |
| “美化界面” | “为 `Header.tsx` 添加 Tailwind 类” |

> **规则：** 每个任务都要有清晰且可验证的完成结果。

---

### 原则 3：按项目类型动态生成内容

**对于新项目（NEW PROJECT）：**
- 技术栈是什么？（先决定）
- MVP（最小可行产品）是什么？（最小功能集合）
- 文件结构如何设计？

**对于功能新增（FEATURE ADDITION）：**
- 会影响哪些文件？
- 需要哪些依赖？
- 如何验证功能可用？

**对于缺陷修复（BUG FIX）：**
- 根因是什么？
- 需要改哪一个文件/哪一行？
- 如何验证修复有效？

---

### 原则 4：脚本必须与项目匹配

> [CRITICAL]  **不要复制粘贴脚本命令。必须按项目类型选择。**

| 项目类型 | 相关脚本 |
|----------|----------|
| Frontend/React（前端/React） | `ux_audit.py`, `accessibility_checker.py` |
| Backend/API（后端/API） | `api_validator.py`, `security_scan.py` |
| Mobile（移动端） | `mobile_audit.py` |
| Database（数据库） | `schema_validator.py` |
| Full-stack（全栈） | 根据修改范围组合上述脚本 |

**错误：** 每份计划都塞入所有脚本  
**正确：** 仅保留与当前任务相关的脚本

---

### 原则 5：验证应简单直接

| [FAIL]  错误 | [OK]  正确 |
|---------|---------|
| “验证组件工作正常” | “运行 `npm run dev`，点击按钮，看到 toast” |
| “测试 API” | “`curl localhost:3000/api/users` 返回 200” |
| “检查样式” | “打开浏览器，确认深色模式切换可用” |

---

## 计划结构（灵活而非固定）

```
# [任务名称]

## 目标（Goal）
一句话：我们要构建/修复什么？

## 任务（Tasks）
- [ ] 任务 1：[具体动作] -> 验证：[如何检查]
- [ ] 任务 2：[具体动作] -> 验证：[如何检查]
- [ ] 任务 3：[具体动作] -> 验证：[如何检查]

## 完成标准（Done When）
- [ ] [主要成功标准]
```

> **就这些。** 除非确实必要，否则不要额外加阶段和子章节。  
> 保持最小化，只有在需要时才增加复杂度。

## 备注（Notes）
[任何重要注意事项]
```

---

## 最佳实践（速查）

1. **先写目标** - 明确构建/修复的对象
2. **最多 10 个任务** - 超过就拆为多份计划
3. **每个任务可验证** - 给出清晰“完成”标准
4. **与项目绑定** - 不使用复制粘贴模板
5. **边做边更新** - 完成后及时标记 `[x]`

---

## 适用场景

- 从零开始新项目
- 新增功能
- 修复复杂缺陷
- 涉及多文件的重构