名称: 计划撰写 描述: 结构化任务规划，具有清晰的分解、依赖关系和验证标准。在实现功能、重构或任何多步骤工作时使用。 允许工具: 读取, 全局查找, 搜索
计划撰写
来源: obra/superpowers
概述
该技能提供了一个框架，用于将工作分解为清晰、可操作的任务，并设定验证标准。
任务分解原则
1. 小而专注的任务
- 每个任务应花费2-5分钟
- 每个任务有明确的产出
- 独立可验证
2. 清晰验证
- 如何知道任务已完成？
- 可以检查或测试什么？
- 预期输出是什么？
3. 逻辑排序
- 识别依赖关系
- 尽可能并行工作
- 突出关键路径
- 阶段X: 验证总是最后
4. 项目根目录中的动态命名
- 计划文件保存为
{任务-slug}.md，位于项目根目录 - 名称基于任务（例如，“添加认证” →
认证功能.md） - 绝不放在
.claude/、docs/或临时文件夹中
规划原则（非模板！）
🔴 无固定模板。每个计划针对任务都是独特的。
原则1: 保持简短
| ❌ 错误 | ✅ 正确 |
|---|---|
| 50个任务，包含子子任务 | 最多5-10个清晰任务 |
| 列出每个微步骤 | 仅包括可操作项 |
| 冗长描述 | 每个任务一行 |
规则: 如果计划超过一页，则太长了。简化。
原则2: 具体而非泛泛
| ❌ 错误 | ✅ 正确 |
|---|---|
| “设置项目” | “运行 npx create-next-app” |
| “添加认证” | “安装 next-auth，创建 /api/auth/[...nextauth].ts” |
| “样式化UI” | “向 Header.tsx 添加Tailwind类” |
规则: 每个任务应有清晰、可验证的产出。
原则3: 基于项目类型的动态内容
对于新项目:
- 技术栈是什么？（先决定）
- 最小可行产品是什么？（最小功能）
- 文件结构是什么？
对于功能添加:
- 哪些文件受影响？
- 需要什么依赖？
- 如何验证其工作？
对于错误修复:
- 根本原因是什么？
- 更改哪个文件/行？
- 如何测试修复？
原则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，点击按钮，看到提示” |
| “测试API” | “curl localhost:3000/api/users 返回200” |
| “检查样式” | “打开浏览器，验证深色模式切换有效” |
计划结构（灵活，非固定！）
# [任务名称]
## 目标
一句话：我们在构建/修复什么？
## 任务
- [ ] 任务1: [具体动作] → 验证: [如何检查]
- [ ] 任务2: [具体动作] → 验证: [如何检查]
- [ ] 任务3: [具体动作] → 验证: [如何检查]
## 完成时
- [ ] [主要成功标准]
仅此而已。 除非真正需要，否则无阶段、无子部分。 保持最小化。仅在需要时添加复杂性。
备注
[任何重要考虑事项]
---
## 最佳实践（快速参考）
1. **从目标开始** - 我们在构建/修复什么？
2. **最多10个任务** - 如果更多，分解为多个计划
3. **每个任务可验证** - 清晰的“完成”标准
4. **项目特定** - 无复制粘贴模板
5. **边走边更新** - 完成时标记 `[x]`
---
## 使用时机
- 从零开始的新项目
- 添加功能
- 修复错误（如果复杂）
- 重构多个文件