任务规划Skill：把复杂工作拆成可验证的小步骤，让 AI 与人都不会跑偏
- 它是什么：plan-writing（任务规划Skill）是一个结构化任务规划框架，用「目标 + 最多 5-10 个可验证任务 + 完成标准」把模糊需求变成可执行的清单。
- 它的核心不是模板，而是原则：小步聚焦（每任务 2-5 分钟）、具体可验证、识别依赖与关键路径、计划文件放项目根目录、动态命名。
- 它最实用之处：强制每个任务都写清「如何验证」，避免出现"做完了但不知道对不对"的常见困境。
- 它只调用读取、全局查找、搜索三类只读工具：规划阶段不碰代码，保证输出的是计划而不是半成品改动。
- 最适合：新项目从零启动、功能添加、复杂 Bug 修复、多文件重构这四类多步骤场景。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
任务规划Skill，英文名 plan-writing，技能 ID 12021。该技能来源标注为 obra/superpowers，定位是一个「计划撰写」框架型技能。
它到底解决什么问题
在真实的开发协作里，最昂贵的成本往往不是写代码，而是"没想清楚就开始写"。典型症状包括：
- 需求一抛出来就动手，写了三百行才发现技术选型错了；
- 任务颗粒度失控，一个任务里塞着建项目、装依赖、写页面、调样式，无法判断到底是哪一步失败；
- 没有验证标准，做完之后只能说"应该没问题吧"，回归成本极高；
- 计划写成了五十个任务的长文档，看起来专业，实际上没人会去读完和执行。
plan-writing 的思路非常务实：用最小篇幅，换取最大执行力。它要求计划控制在"一页以内"，每个任务一行，每个任务都有明确的"验证"字段。它不提供固定模板，而是给出一组必须遵守的原则。
一键安装的思路与步骤
通用流程（具体命令与入口以官方说明为准）：
- 确认前提：该技能声明允许使用「读取、全局查找、搜索」三类只读工具，说明它运行在支持技能机制与工具权限声明的 AI 编程环境中。安装前需确认你所用的客户端支持技能（Skill）加载与权限声明。
- 获取技能包：从技能来源（详情中标注为 obra/superpowers）取得 plan-writing 技能文件。
- 放入技能目录并启用：按客户端约定将技能放置到技能加载目录，然后在会话中启用该技能。具体目录路径与启用开关以官方说明为准。
- 验证是否生效：对 AI 说一句"帮我把’给现有项目添加登录功能’拆成计划"，观察输出是否满足三条特征——①有独立「目标」一行；②任务数量在 5-10 条以内且每条带「→ 验证:」；③计划被建议保存为项目根目录下的
{任务-slug}.md形式文件。三条都满足，说明技能已生效。
之所以强调"一键安装"的价值：技能装好后，规划能力就从"每次都要我先叮嘱一遍"变成"默认行为"，这才是效率增益的真正来源。
该技能的主要功能和特点
- 小而聚焦的任务拆分：要求每个任务耗时 2-5 分钟，有明确产出，独立可验证。这把"大块工作"切成了可连续打勾的推进单元。
- 强制验证标准：每个任务后面必须跟"如何知道它完成了、可以检查或测试什么、预期输出是什么"。这是该技能与普通待办清单最大的区别。
- 逻辑排序与依赖识别：要求识别依赖关系、尽可能并行、突出关键路径，并明确"验证总是最后"——阶段 X 永远是验证阶段。
- 计划文件落在项目根目录：文件名为
{任务-slug}.md，例如"添加认证"对应认证功能.md，并明确禁止放进.claude/、docs/或临时文件夹。这样计划与代码同处一处，不易丢失。 - 反模板的规划哲学：明确写着"无固定模板，每个计划针对任务都是独特的"。它反对把 50 个任务、层层子任务、冗长描述的"看起来很专业"的计划当成目标。
- 项目类型动态适配：新项目先定技术栈与最小可行产品；功能添加问清受影响文件、依赖、验证方式；错误修复先定根本原因，再定改哪个文件/行、怎么测试。
- 脚本按项目类型选择：前端/React 类项目对应
ux_audit.py、accessibility_checker.py；后端/API 对应api_validator.py、security_scan.py；移动端mobile_audit.py；数据库schema_validator.py；全栈按接触面混合。明确反对"往每个计划里塞所有脚本"。 - 验证要简单可操作：不写"验证组件工作正确"，而写"运行
npm run dev，点击按钮，看到提示"；不写"测试 API"，而写"curl localhost:3000/api/users 返回 200"。 - 边走边更新：任务完成时把
[ ]标记为[x]，让计划文件本身成为进度看板。
和普通任务清单工具相比，它强在两点：颗粒度纪律（小、少、一行一个）和验证纪律（每条任务必须能被检验）。普通清单只回答"要做什么"，它必须回答"怎么算做完了"。
如何使用该技能？
步骤一：给出目标，而不是任务列表
不要一上来就列任务，先把"我们在构建/修复什么"用一句话讲清楚。
输入示例：
帮我为现有 Next.js 项目添加邮箱密码登录功能，请用计划撰写的方式输出。
步骤二：让 AI 输出结构化的计划骨架
该技能规定的结构是灵活的、极简的，通常形如：
# 添加邮箱密码登录
## 目标
为现有 Next.js 项目增加邮箱 + 密码登录，支持会话保持。
## 任务
- [ ] 安装 next-auth 依赖 → 验证: package.json 中出现 next-auth 条目
- [ ] 创建 `/api/auth/[...nextauth].ts` → 验证: 文件存在且导出 handler
- [ ] 在登录页接入 signIn → 验证: 运行 npm run dev，输入测试账号后跳转到首页
- [ ] 配置会话读取 → 验证: 首页能显示当前登录邮箱
## 完成时
- [ ] 用未登录状态访问受保护页面会自动跳转登录页
## 备注
测试账号先用本地种子数据，暂不接入第三方 OAuth。
注意它同时满足了：目标一句话、任务不超过 10 条、每条带验证、验证具体到命令或可观察现象、末尾有完成标准。
步骤三：校对颗粒度与验证可操作性
拿到计划后，按三条自查：
- 有没有任务超过"2-5 分钟"的合理范围？有就再拆。
- 每个"→ 验证:"能不能在终端或浏览器里真的执行一遍？不能就改写。
- 计划是否超过一页？超了就拆成多个计划，或删掉非必要项。
步骤四：落盘到项目根目录
按技能约定，把计划保存为项目根目录下的 {任务-slug}.md，如 认证功能.md。不要放进 .claude/、docs/ 或临时目录。
步骤五：执行并打勾
按任务顺序推进，完成一条就把 - [ ] 改成 - [x]。关键路径上的任务优先，无依赖关系的任务可并行。全部任务完成后，跑一遍"完成时"清单做最终验收。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| plan-writing（任务规划Skill） | 面向 AI 协作的结构化计划撰写框架 | 小步拆分、强制验证标准、依赖排序、计划落项目根目录 | 需支持技能机制的环境，具体安装以官方说明为准；使用上只需自然语言提出目标 | 新项目启动、功能添加、复杂 Bug 修复、多文件重构 | 优势：颗粒度与验证纪律强，计划极短可执行；不足：不含任务看板、甘特图等项目管理能力，也不做自动执行 |
| 通用待办清单（如各类 Todo 应用） | 个人任务管理 | 清单、提醒、标签、看板 | 门槛低，多数免费或订阅 | 日常琐事、个人时间管理 | 优势：上手快、界面成熟；不足：不约束颗粒度，不要求验证标准，也不会针对代码任务给出具体命令级动作 |
| 研发项目管理平台（如 Jira 类工具） | 团队级项目与缺陷跟踪 | 需求、迭代、缺陷、报表、权限 | 门槛较高，需团队配置与流程约定 | 多人协作的中大型工程 | 优势：协作与追踪能力强；不足：面向团队流程，"任务 2-5 分钟、每任务一行"这类轻量纪律反而难落地，个人开发者易显笨重 |
| AI 编码助手内置的 Plan 模式 | 编码前的方案确认 | 生成实现步骤、确认后自动改代码 | 依赖具体产品，门槛中等 | 快速落地中小改动 | 优势：计划与执行打通；不足：计划文本通常不可控、不落盘为可勾选清单，验证标准不一定显式写出 |
选择建议：如果你要的是"想清楚再动手"，且希望计划本身是一份可勾选、可验证、能长期留在仓库里的轻量文档，plan-writing 更贴合；如果你要的是团队级追踪与报表，则应由项目管理平台承担，两者并不互斥。
该技能的典型应用场景与实际体验情况
场景一：从零启动一个新项目（独立开发者）
痛点：想法很多，技术栈没定就开始写，写到一半推翻重来。 使用方式：先让技能输出"技术栈是什么、最小可行产品是什么、文件结构是什么"三问的计划，再落到具体任务。 实际体验：因为技能明确要求"先决定技术栈"，这类返工明显减少。注意点是——不要在这一步接受超过 10 个任务，宁可先做最小闭环。
场景二：给成熟项目添加一个功能（后端工程师）
痛点：改一处漏三处，事后才发现还有别的文件需要同步修改。
使用方式：按"哪些文件受影响、需要什么依赖、如何验证其工作"三要素产出计划。
实际体验：技能要求把"受影响文件"写进任务里，漏改概率下降。注意点是验证项要写成 curl localhost:3000/api/users 返回 200 这种可执行形式，不要写成"确认接口正常"。
场景三：复杂 Bug 修复（长期维护者）
痛点：直接改现象，不查根因，改完又复发。 使用方式：先写"根本原因是什么"，再写"更改哪个文件/行"，最后写"如何测试修复"。 实际体验：它是四类场景里收益最明显的一类，因为强制先定性根因。注意点是——简单的一行修复不必强行走完整计划，技能本身也说明"修复错误（如果复杂）"才需要。
场景四：多文件重构（Tech Lead 带人）
痛点：重构计划写成五十步长文，团队没人读完，进度不可见。
使用方式：把重构拆成多个不超过 10 任务的计划文件，分别落盘，逐个打勾推进。
实际体验：一页以内的计划显著提升了团队实际阅读率，[x] 标记让进度对所有人可见。注意点是关键路径上的任务要前置，能并行的分给不同人。
总体上手难度：低。它不需要学新语法或新命令，本质是把"先想清楚"变成默认习惯。真正的学习成本在于忍住不写长计划。
该技能能为用户带来的价值
- 减少返工：通过在动手前明确技术栈、受影响文件与根因，"写到一半推翻"的概率显著降低，这是收益最大的一项。
- 让"完成"可判定：每个任务都带验证项，做完即可自证，不再依赖"应该没问题"这种模糊判断，对后续回归尤其友好。
- 降低协作门槛：计划最多 5-10 条、每条一行、整体一页以内，新人加入项目读一遍就能接手，沟通成本远低于长篇设计文档。
- 计划与代码同仓：文件落在项目根目录、以任务语义命名，检索引擎和版本记录都能覆盖，形成可追溯的决策记录。
- 降低 AI 协作风险：技能仅使用读取、全局查找、搜索三类只读工具，规划阶段不产生代码改动，等于把"想"和"做"分开，出错代价极低。
- 长期复利：把"先规划再动手"固化为默认行为，收益会随项目数量和复杂度线性累积，而不是一次性提速。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？ A：按通用流程是：确认客户端支持技能机制与工具权限声明 → 从来源（obra/superpowers）取得技能包 → 放入技能加载目录并启用 → 用一句"帮我把某个需求拆成计划"验证是否生效。具体的安装命令、目录路径、入口位置与是否收费，本技能详情中未提供，请以官方说明为准。
Q2：它会不会生成又长又复杂的计划？ A：设计上正相反。技能明确要求"最多 5-10 个清晰任务"“如果计划超过一页，则太长了”“仅包括可操作项，每个任务一行”。如果你收到的计划太长，直接要求它按原则压缩。
Q3：它和 AI 编程助手自带的 Plan 模式有什么区别？ A：Plan 模式侧重"确认后自动改代码"，plan-writing 侧重"产出一份可勾选、带验证标准、落在项目根目录的计划文件"。前者偏执行效率，后者偏思考质量与可追溯性。该技能只使用只读工具，本身不执行代码修改。
Q4：简单的小改动也要用它吗？ A：不必。技能的适用时机是"从零开始的新项目、添加功能、复杂错误修复、重构多个文件"这类多步骤工作。一行修复、改个文案直接做即可。
Q5：计划文件应该放在哪里？可以放进 docs 目录吗？
A：按技能约定，必须放在项目根目录，命名为 {任务-slug}.md（如"添加认证"→ 认证功能.md），绝不放在 .claude/、docs/ 或临时文件夹中。目的是让计划与代码同处一处、不易丢失。