关于
结构化任务规划，包含清晰的分解、依赖关系和验证标准。在实现功能、修复 Bug 或执行复杂多步骤任务时使用。
name: plan-writing description: "结构化任务规划，包含清晰的分解、依赖关系和验证标准。用于实现功能、重构或任何多步骤工作。" risk: unknown source: community date_added: "2026-02-27"
计划编写
来源：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" |
| "美化 UI" | "给 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: [具体操作] → 验证: [如何检查]
## 完成条件
- [ ] [主要成功标准]
就这样。 除非真正需要，否则不要分阶段、不要子章节。 保持最小化。仅在需要时增加复杂度。
最佳实践（快速参考）
- 从目标开始 - 我们在构建/修复什么？
- 最多 10 个任务 - 如果更多，拆分为多个计划
- 每个任务可验证 - 清晰的"完成"标准
- 项目特定 - 不要复制粘贴模板
- 随时更新 - 完成时标记
[x]
何时使用
- 从零开始的新项目
- 添加功能
- 修复 Bug（如果复杂）
- 重构多个文件
限制
- 仅在任务明确匹配上述描述的范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准，请停下来寻求澄清。