用途
Plan Writing 是一个任务规划框架，用于把工作拆解为清晰、可执行、可验证的任务。它适用于从零开始的新项目、添加功能、修复复杂 Bug，以及涉及多个文件的重构等多步骤工作。
主要能力
任务拆解原则
- 小而聚焦的任务：每个任务应耗时 2-5 分钟，一个任务对应一个明确产出，且可独立验证。
- 清晰的验证方式：明确如何判断任务完成、可以检查或测试什么、预期输出是什么。
- 逻辑排序：识别依赖关系，尽可能并行处理，突出关键路径；验证阶段始终放在最后。
- 项目根目录动态命名：计划文件以 {task-slug}.md 形式保存在项目根目录，名称由任务派生（例如 "add auth" → auth-feature.md），绝不放在 .claude/、docs/ 或临时文件夹中。
规划原则（非模板）
该技能强调没有固定模板，每个计划都因任务而异。
原则 1：保持简短。最多 5-10 个清晰任务，只列可执行项，每个任务一行；如果计划超过一页，就说明太长了，需要简化。
原则 2：具体而非笼统。例如不写 "Set up project"，而写 "Run npx create-next-app"；不写 "Add authentication"，而写 "Install next-auth, create /api/auth/[...nextauth].ts"；不写 "Style the UI"，而写 "Add Tailwind classes to Header.tsx"。每个任务都应有清晰、可验证的产出。
原则 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：验证要简单。例如不写 "Verify the component works correctly"，而写 "Run npm run dev, click button, see toast"；不写 "Test the API"，而写 "curl localhost:3000/api/users returns 200"；不写 "Check styles"，而写 "Open browser, verify dark mode toggle works"。
使用方式
计划结构灵活而非固定，基本形式如下：
[Task Name]
Goal
一句话说明：我们要构建或修复什么？
Tasks
- [ ] Task 1: [Specific action] → Verify: [How to check]
- [ ] Task 2: [Specific action] → Verify: [How to check]
- [ ] Task 3: [Specific action] → Verify: [How to check]
Done When
- [ ] [Main success criteria]
Notes
[Any important considerations]
除真正需要外，不设阶段和子章节，保持最小化，只在必要时增加复杂度。
最佳实践速查：从目标开始；最多 10 个任务，超出则拆成多个计划；每个任务可验证；项目特定，不复制粘贴模板；随进度更新，完成时标记 [x]。
适用场景
- 从零开始的新项目
- 添加功能
- 修复 Bug（复杂时）
- 重构多个文件
限制
资料未提供该技能的安装方式、收费模式、平台支持范围或具体效果数据，这些信息暂未提供。