# Plan Writing

> 结构化任务规划，包含清晰的分解、依赖关系和验证标准。适用于功能开发、重构或多步骤工作。当用户要求编写计划、制定方案、任务分解或开发规划时使用。

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

---


# Plan Writing

> 来源: obra/superpowers

## 概述
本技能提供一套将工作分解为清晰、可执行任务的框架，并包含验证标准。

## 任务分解原则

### 1. 小而聚焦的任务
- 每个任务应在 2-5 分钟内完成
- 每个任务一个明确的产出
- 可独立验证

### 2. 清晰的验证标准
- 如何确认已完成？
- 可以检查/测试什么？
- 预期输出是什么？

### 3. 逻辑排序
- 识别依赖关系
- 尽可能并行处理
- 标注关键路径
- **阶段 X：验证永远放在最后**

### 4. 项目根目录的动态命名
- 计划文件保存为项目根目录下的 `{task-slug}.md`
- 名称从任务派生（如 "add auth" → `auth-feature.md`）
- **绝不能**放在 `.claude/`、`docs/` 或临时文件夹内

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

> 🔴 **没有固定模板。每个计划都是针对任务定制的。**

### 原则 1：保持简短

| ❌ 错误做法 | ✅ 正确做法 |
|------------|------------|
| 50 个任务包含子子任务 | 最多 5-10 个清晰任务 |
| 列出每个微步骤 | 仅列出可执行项 |
| 冗长的描述 | 每个任务一行 |

> **规则：** 如果计划超过 1 页，说明太长了。简化它。

---

### 原则 2：具体明确，不要笼统

| ❌ 错误做法 | ✅ 正确做法 |
|------------|------------|
| "搭建项目" | "运行 `npx create-next-app`" |
| "添加认证" | "安装 next-auth，创建 `/api/auth/[...nextauth].ts`" |
| "美化界面" | "给 `Header.tsx` 添加 Tailwind 类" |

> **规则：** 每个任务应有清晰、可验证的产出。

---

### 原则 3：根据项目类型动态调整内容

**新项目：**
- 技术栈是什么？（先决定）
- MVP 是什么？（最少功能）
- 文件结构如何？

**功能新增：**
- 涉及哪些文件？
- 需要什么依赖？
- 如何验证其工作？

**Bug 修复：**
- 根本原因是什么？
- 需要修改哪个文件/哪一行？
- 如何测试修复？

---

### 原则 4：脚本是项目特定的

> 🔴 **不要复制粘贴脚本命令。根据项目类型选择。**

| 项目类型 | 相关脚本 |
|---------|---------|
| 前端/React | `ux_audit.py`、`accessibility_checker.py` |
| 后端/API | `api_validator.py`、`security_scan.py` |
| 移动端 | `mobile_audit.py` |
| 数据库 | `schema_validator.py` |
| 全栈 | 根据涉及内容混合使用 |

**错误做法：** 把所有脚本加到每个计划里
**正确做法：** 仅添加与当前任务相关的脚本

---

### 原则 5：验证要简单

| ❌ 错误做法 | ✅ 正确做法 |
|------------|------------|
| "验证组件正常工作" | "运行 `npm run dev`，点击按钮，看到 toast" |
| "测试 API" | "curl localhost:3000/api/users 返回 200" |
| "检查样式" | "打开浏览器，验证深色模式切换生效" |

---

## 计划结构（灵活，不固定！）

```
# [任务名称]

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

## 任务
- [ ] 任务 1: [具体操作] → 验证: [如何检查]
- [ ] 任务 2: [具体操作] → 验证: [如何检查]
- [ ] 任务 3: [具体操作] → 验证: [如何检查]

## 完成标准
- [ ] [主要成功标准]
```

> **就这样。** 没有阶段划分，除非真正需要，不要加子章节。
> 保持精简。只在需要时增加复杂度。

## 备注
[任何重要考虑事项]
```

---

## 最佳实践（快速参考）

1. **从目标开始** - 我们要构建/修复什么？
2. **最多 10 个任务** - 超过则拆分为多个计划
3. **每个任务可验证** - 明确的"完成"标准
4. **项目特定** - 不要复制粘贴模板
5. **边做边更新** - 完成后标记 `[x]`

---

## 适用场景
- 从零开始的新项目
- 添加功能
- 修复 Bug（如果复杂）
- 重构多个文件

## 局限性
- 仅在任务明确匹配上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家评审的替代品。
- 如果缺少必要输入、权限、安全边界或成功标准，请停下来请求澄清。