用途
Plan Writing 是一个用于结构化任务规划的技能，目标是把一项工作拆解成清晰、可执行、可验证的任务，并明确依赖关系与验证标准。它适用于从零开始的新项目、添加功能、修复复杂 Bug，以及涉及多个文件的重构。
主要能力
- 任务拆解：每个任务应小而聚焦，耗时约 2-5 分钟，只有一个明确产出，并且可以独立验证。
- 清晰验证：每个任务都要回答“如何知道它完成了”“可以检查或测试什么”“预期输出是什么”。
- 逻辑排序：识别依赖关系，尽可能并行安排工作，突出关键路径；验证阶段始终放在最后。
- 动态命名与存放：计划文件以 {task-slug}.md 保存在项目根目录，名称由任务派生（例如“add auth”对应 auth-feature.md），绝不放在 .agents/、docs/ 或临时文件夹中。
使用方式
该技能强调“规划原则，而非模板”。每个计划都应对当前任务唯一，不套用固定模板。
核心原则包括：
- 保持简短：最多 5-10 个清晰任务，只列可执行项，每个任务一行；如果计划超过一页，就说明太长了，需要简化。
- 具体而非泛泛：避免“设置项目”“添加认证”“美化 UI”这类模糊描述，改为“运行 npx create-next-app”“安装 next-auth，创建 /api/auth/[...nextauth].ts”“给 Header.tsx 添加 Tailwind 类”等可验证动作。
- 根据项目类型动态生成内容：
- 新项目：先决定技术栈，明确 MVP 最小功能，确定文件结构。
- 功能新增：明确受影响的文件、所需依赖、如何验证其工作。
- Bug 修复：明确根因、要修改的文件或行、如何测试修复。
- 脚本因项目而异：不要复制粘贴脚本命令，应根据项目类型选择。例如前端/React 可考虑 ux_audit.py、accessibility_checker.py；后端/API 可考虑 api_validator.py、security_scan.py；移动端可考虑 mobile_audit.py；数据库可考虑 schema_validator.py；全栈则按实际改动混合选择。错误做法是把所有脚本都塞进每个计划，正确做法是只选与当前任务相关的脚本。
- 验证要简单：避免“验证组件工作正常”“测试 API”“检查样式”这类模糊说法，改为“运行 npm run dev，点击按钮，看到 toast”“curl localhost:3000/api/users 返回 200”“打开浏览器，验证深色模式切换可用”等具体可执行步骤。
计划结构灵活而非固定，通常包含：
- 任务名称
- Goal：一句话说明要构建或修复什么
- Tasks：任务列表，每项格式为“任务：具体动作 → 验证：如何检查”
- Done When：主要成功标准
- Notes：重要注意事项
除非确实需要，否则不添加阶段和子章节，保持最小化，只在必要时增加复杂度。
适用场景
- 从零开始的新项目
- 添加一个功能
- 修复 Bug（复杂时）
- 重构多个文件
限制
资料未提供该技能的具体安装命令、收费方式、价格、平台支持范围或实际效果数据，这些信息暂未提供。该技能本身不提供固定模板，要求使用者根据任务动态生成计划；如果任务超过 10 项，应拆分为多个计划。