plan-writing
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
Best use case
plan-writing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
Teams using plan-writing should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/plan-writing/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How plan-writing Compares
| Feature / Agent | plan-writing | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Plan Writing
> Source: obra/superpowers
## Overview
This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
## Task Breakdown Principles
### 1. Small, Focused Tasks
- Each task should take 2-5 minutes
- One clear outcome per task
- Independently verifiable
### 2. Clear Verification
- How do you know it's done?
- What can you check/test?
- What's the expected output?
### 3. Logical Ordering
- Dependencies identified
- Parallel work where possible
- Critical path highlighted
- **Phase X: Verification is always LAST**
### 4. Dynamic Naming in Project Root
- 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
## Planning Principles (NOT Templates!)
> 🔴 **NO fixed templates. Each plan is UNIQUE to the task.**
### Principle 1: Keep It SHORT
| ❌ Wrong | ✅ Right |
|----------|----------|
| 50 tasks with sub-sub-tasks | 5-10 clear tasks max |
| Every micro-step listed | Only actionable items |
| Verbose descriptions | One-line per task |
> **Rule:** If plan is longer than 1 page, it's too long. Simplify.
---
### Principle 2: Be SPECIFIC, Not Generic
| ❌ 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.
---
### Principle 3: Dynamic Content Based on Project Type
**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?
---
### Principle 4: Scripts Are Project-Specific
> 🔴 **DO NOT copy-paste script commands. Choose based on project type.**
| Project Type | Relevant 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-stack | Mix of above based on what you touched |
**Wrong:** Adding all scripts to every plan
**Right:** Only scripts relevant to THIS task
---
### Principle 5: Verification is Simple
| ❌ 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" |
---
## Plan Structure (Flexible, Not Fixed!)
```
# [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]
## 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
---
## When to Use
- New project from scratch
- Adding a feature
- Fixing a bug (if complex)
- Refactoring multiple filesRelated Skills
sw-tech-stack-planner
Use when user wants a tech stack recommendation, technology choices, docker-compose setup, or architecture decisions for a software project – reads vision.md, user-stories.md, use-cases.md and generates requirements/tech-stack.yaml silently.
superpowers-writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
self-explanatory-code-commenting
Guidelines for GitHub Copilot to write comments to achieve self-explanatory code with less comments. Examples are in JavaScript but it should work on any language that has comments. Triggers on: **
prd-planner
Analyzes PRDs and creates beads task breakdown for multi-agent implementation
plans-management
Manages Plans.md tasks and marker operations. Use when user mentions タスクを追加, Plans.md更新, 完了マーク, タスク状態変更, add task, update plans, mark complete. Do NOT load for: 実装作業, レビュー, Plans.md以外のファイル操作.
planning-with-files
Transforms workflow to use Manus-style persistent markdown files for planning, progress tracking, and knowledge storage. Use when starting complex tasks, multi-step projects, research tasks, or when the user mentions planning, organizing work, tracking progress, or wants structured output.
plan
Creates detailed implementation plan from validated research. Produces task breakdown with dependencies.
plan-reduce-max-lines
This skill should be used when reducing the maximum class/module lines threshold and fixing all violations. It updates the RuboCop configuration, identifies classes and modules exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
plan-maker
Create implementation plans with testable acceptance criteria, validation strategies, integration touchpoints, and risk analysis before coding begins.
niko-plan
Niko Memory Bank System - Plan Phase - Implementation Planning
implementation-planner
专业的软件架构师,根据用户需求和设计方案创建详细的实施(开发)计划。将设计方案转化为可执行的任务列表,支持测试驱动开发和渐进式实现。
dev-workflow-planning
Structured development workflows using /brainstorm, /write-plan, and /execute-plan patterns. Transform ad-hoc conversations into systematic project execution with hypothesis-driven planning, incremental implementation, and progress tracking.