mcpField
P
plan-writing

plan-writing

github.com/sickn33Agent workflows48.7k840 installsUpdated today
Repository

About plan-writing

plan-writing is a skill for turning project work into short, actionable plans with verifiable tasks. It guides agents through feature work, new projects, complex fixes, and refactoring without prescribing a fixed template.

Key features

  1. 01Small, focused tasks
  2. 02Verification criteria for each task
  3. 03Dependency-aware ordering
  4. 04Project-root plan file naming
  5. 05Plans limited to essential actions

Use cases

  1. 01Planning a new project
  2. 02Breaking down a feature addition
  3. 03Organizing a complex bug fix
  4. 04Planning multi-file refactoring

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill plan-writing

After installing, type/plan-writingin Claude Code to confirm it loaded.

Details

From the project README

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
  • Verify each task as it is completed, then run a final acceptance check.
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)
  • Follow repository/user conventions when they specify another location; preserve an existing supplied plan.

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-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.


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 TypeRelevant Scripts
Frontend/Reactux_audit.py, accessibility_checker.py
Backend/APIapi_validator.py, security_scan.py
Mobilemobile_audit.py
Databaseschema_validator.py
Full-stackMix of above based on what you touched

Wrong: Adding all scripts to every plan Right: Only existing, inspected scripts relevant to THIS task; the names above are illustrative, not bundled prerequisites


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.

Optional notes may record 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 files

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Comments

Markdown supported