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