misonl 计划编写
来源：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]`
---
## 适用场景
- 从零开始新项目
- 新增功能
- 修复复杂缺陷
- 涉及多文件的重构