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：具体，而非泛泛

❌ 错误	✅ 正确
"Set up project"	"Run npx create-next-app"
"Add authentication"	"Install next-auth, create /api/auth/[...nextauth].ts"
"Style the UI"	"Add Tailwind classes to Header.tsx"

规则： 每个任务都应有清晰、可验证的结果。

---

原则 3：基于项目类型的动态内容

对于新项目：

• 什么技术栈？（先决定）
• MVP 是什么？（最小功能）
• 文件结构是什么？

对于功能新增：

• 哪些文件会受影响？
• 需要哪些依赖？
• 如何验证它可用？

对于缺陷修复：

• 根本原因是什么？
• 要修改哪个文件/行？
• 如何测试修复？

---

原则 4：脚本因项目而异

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

项目类型	相关脚本
前端/React	ux_audit.py、accessibility_checker.py
后端/API	api_validator.py、security_scan.py
移动端	mobile_audit.py
数据库	schema_validator.py
全栈	根据你改动的内容混合使用上述脚本

错误： 把全部脚本都加到每个计划里 正确： 只添加与当前任务相关的脚本

---

原则 5：验证要简单

❌ 错误	✅ 正确
"Verify the component works correctly"	"Run npm run dev, click button, see toast"
"Test the API"	"curl localhost:3000/api/users returns 200"
"Check styles"	"Open browser, verify dark mode toggle works"

---

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

# [Task Name]

## Goal
One sentence: What are we building/fixing?

## Tasks
- [ ] Task 1: [Specific action] → Verify: [How to check]
- [ ] Task 2: [Specific action] → Verify: [How to check]
- [ ] Task 3: [Specific action] → Verify: [How to check]

## Done When
- [ ] [Main success criteria]

就是这样。 除非确实需要，否则没有阶段，也没有子章节。 保持最小化。仅在需要时增加复杂度。

备注

[任何重要考虑事项]

---

## Best Practices (Quick Reference)

1. **Start with goal** - What are we building/fixing?
2. **Max 10 tasks** - If more, break into multiple plans
3. **Each task verifiable** - Clear "done" criteria
4. **Project-specific** - No copy-paste templates
5. **Update as you go** - Mark `[x]` when complete

---

## When to Use

- New project from scratch
- Adding a feature
- Fixing a bug (if complex)
- Refactoring multiple files