Back to Details

plan-writing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan Writing

任务规划撰写

Source: obra/superpowers
来源：obra/superpowers

Overview

概述

This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
本Skill提供一个框架，可将工作拆分为清晰、可执行的任务，并附带验证标准。

Task Breakdown Principles

任务拆分原则

1. Small, Focused Tasks

1. 小巧、聚焦的任务

  • Each task should take 2-5 minutes
  • One clear outcome per task
  • Independently verifiable
  • 每个任务耗时应在2-5分钟之间
  • 每个任务对应一个明确的成果
  • 可独立验证

2. Clear Verification

2. 明确的验证标准

  • How do you know it's done?
  • What can you check/test?
  • What's the expected output?
  • 如何判断任务已完成？
  • 可以检查/测试哪些内容？
  • 预期输出是什么？

3. Logical Ordering

3. 合理的排序逻辑

  • Dependencies identified
  • Parallel work where possible
  • Critical path highlighted
  • Phase X: Verification is always LAST
  • 识别依赖关系
  • 尽可能并行处理工作
  • 突出关键路径
  • 阶段X：验证环节永远放在最后

4. Dynamic Naming in Project Root

4. 项目根目录下的动态命名规则

  • Plan files are saved as 
    {task-slug}.md
    in the PROJECT ROOT
  • Name derived from task (e.g., "add auth" → 
    auth-feature.md
    )
  • NEVER inside 
    .claude/
    , 
    docs/
    , or temp folders
  • 规划文件以
    {task-slug}.md
    格式保存在项目根目录
  • 文件名源自任务内容（例如："add auth" → 
    auth-feature.md
    ）
  • 绝对不要存放在
    .claude/
    、
    docs/
    或临时文件夹中

Planning Principles (NOT Templates!)

规划原则（非模板！）

🔴 NO fixed templates. Each plan is UNIQUE to the task.
🔴 禁止使用固定模板。每个规划都应与任务需求匹配，具备唯一性。

Principle 1: Keep It SHORT

原则1：保持简洁

❌ Wrong✅ Right
50 tasks with sub-sub-tasks5-10 clear tasks max
Every micro-step listedOnly actionable items
Verbose descriptionsOne-line per task
Rule: If plan is longer than 1 page, it's too long. Simplify.
❌ 错误做法✅ 正确做法
包含50个带子子任务的条目最多5-10个清晰任务
列出每个微步骤仅包含可执行项
冗长的描述每个任务一行说明
规则： 如果规划超过1页，说明过于冗长，需要简化。

Principle 2: Be SPECIFIC, Not Generic

原则2：具体明确，避免泛化

❌ Wrong✅ Right
"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
"
Rule: Each task should have a clear, verifiable outcome.
❌ 错误做法✅ 正确做法
"搭建项目""运行
npx create-next-app
"
"添加认证功能""安装next-auth，创建
/api/auth/[...nextauth].ts
"
"设计UI样式""为
Header.tsx
添加Tailwind类"
规则： 每个任务都应有清晰、可验证的成果。

Principle 3: Dynamic Content Based on Project Type

原则3：根据项目类型调整内容

For NEW PROJECT:
  • What tech stack? (decide first)
  • What's the MVP? (minimal features)
  • What's the file structure?
For FEATURE ADDITION:
  • Which files are affected?
  • What dependencies needed?
  • How to verify it works?
For BUG FIX:
  • What's the root cause?
  • What file/line to change?
  • How to test the fix?
针对新项目：
  • 采用什么技术栈？（先确定）
  • 最小可行产品（MVP）包含哪些功能？
  • 文件结构是什么样的？
针对功能新增：
  • 会影响哪些文件？
  • 需要哪些依赖？
  • 如何验证功能正常运行？
针对Bug修复：
  • 根本原因是什么？
  • 需要修改哪个文件/哪一行代码？
  • 如何测试修复效果？

Principle 4: Scripts Are Project-Specific

原则4：脚本需贴合项目类型

🔴 DO NOT copy-paste script commands. Choose based on project type.
Project TypeRelevant Scripts
Frontend/React
ux_audit.py
, 
accessibility_checker.py
Backend/API
api_validator.py
, 
security_scan.py
Mobile
mobile_audit.py
Database
schema_validator.py
Full-stackMix of above based on what you touched
Wrong: Adding all scripts to every plan Right: Only scripts relevant to THIS task
🔴 不要复制粘贴通用脚本命令。应根据项目类型选择合适的脚本。
项目类型相关脚本
前端/React
ux_audit.py
, 
accessibility_checker.py
后端/API
api_validator.py
, 
security_scan.py
移动端
mobile_audit.py
数据库
schema_validator.py
全栈根据涉及模块混合使用上述脚本
错误做法： 为每个规划添加所有脚本 正确做法： 仅添加与当前任务相关的脚本

Principle 5: Verification is Simple

原则5：验证标准应简单可执行

❌ Wrong✅ Right
"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"
❌ 错误做法✅ 正确做法
"验证组件正常工作""运行
npm run dev
，点击按钮，确认弹出提示框"
"测试API""执行
curl localhost:3000/api/users
，确认返回200状态码"
"检查样式""打开浏览器，验证暗黑模式切换功能正常"

Plan Structure (Flexible, Not Fixed!)

规划结构（灵活可变，非固定格式！）

undefined
undefined

[Task Name]

[任务名称]

Goal

目标

One sentence: What are we building/fixing?
一句话说明：我们要构建/修复什么？

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]
  • 任务1：[具体操作] → 验证方式：[检查方法]
  • 任务2：[具体操作] → 验证方式：[检查方法]
  • 任务3：[具体操作] → 验证方式：[检查方法]

Done When

完成标准

  • [Main success criteria]

> **That's it.** No phases, no sub-sections unless truly needed.
> Keep it minimal. Add complexity only when required.
  • [核心成功指标]

> **就这么简单。** 除非确实需要，否则不要添加阶段划分或子章节。
> 保持极简风格，仅在必要时增加复杂度。

Notes

注意事项

[Any important considerations]

---
[任何重要的考虑因素]

---

Best Practices (Quick Reference)

最佳实践（快速参考）

  1. Start with goal - What are we building/fixing?
  2. Max 10 tasks - If more, break into multiple plans
  3. Each task verifiable - Clear "done" criteria
  4. Project-specific - No copy-paste templates
  5. Update as you go - Mark 
    [x]
    when complete
  1. 从目标出发 - 我们要构建/修复什么？
  2. 最多10个任务 - 如果任务过多，拆分为多个规划
  3. 每个任务可验证 - 明确的"完成"标准
  4. 贴合项目需求 - 不要复制粘贴通用模板
  5. 实时更新 - 完成任务后标记
    [x]

When to Use

适用场景

  • New project from scratch
  • Adding a feature
  • Fixing a bug (if complex)
  • Refactoring multiple files
  • 从零开始搭建新项目
  • 新增功能
  • 修复复杂Bug
  • 重构多个文件