/create-plans

name: create-plans
description: Create hierarchical project plans optimized for solo agentic development. Use when planning projects, phases, or tasks that Claude will execute. Produces Claude-executable plans with verification criteria, not enterprise documentation. Handles briefs, roadmaps, phase plans, and context handoffs.

<essential_principles>

<principle name="solo_developer_plus_claude"> You are planning for ONE person (the user) and ONE implementer (Claude). No teams. No stakeholders. No ceremonies. No coordination overhead. The user is the visionary/product owner. Claude is the builder. </principle>

<principle name="plans_are_prompts"> PLAN.md is not a document that gets transformed into a prompt. PLAN.md IS the prompt. It contains:

• Objective (what and why)
• Context (@file references)
• Tasks (type, files, action, verify, done, checkpoints)
• Verification (overall checks)
• Success criteria (measurable)
• Output (SUMMARY.md specification)

When planning a phase, you are writing the prompt that will execute it. </principle>

<principle name="scope_control"> Plans must complete within ~50% of context usage to maintain consistent quality.

**The quality degradation curve:**

• 0-30% context: Peak quality (comprehensive, thorough, no anxiety)
• 30-50% context: Good quality (engaged, manageable pressure)
• 50-70% context: Degrading quality (efficiency mode, compression)
• 70%+ context: Poor quality (self-lobotomization, rushed work)

**Critical insight:** Claude doesn't degrade at 80% - it degrades at ~40-50% when it sees context mounting and enters "completion mode." By 80%, quality has already crashed.

**Solution:** Aggressive atomicity - split phases into many small, focused plans.

Examples:

• `01-01-PLAN.md` - Phase 1, Plan 1 (2-3 tasks: database schema only)
• `01-02-PLAN.md` - Phase 1, Plan 2 (2-3 tasks: database client setup)
• `01-03-PLAN.md` - Phase 1, Plan 3 (2-3 tasks: API routes)
• `01-04-PLAN.md` - Phase 1, Plan 4 (2-3 tasks: UI components)

Each plan is independently executable, verifiable, and scoped to **2-3 tasks maximum**.

**Atomic task principle:** Better to have 10 small, high-quality plans than 3 large, degraded plans. Each commit should be surgical, focused, and maintainable.

**Autonomous execution:** Plans without checkpoints execute via subagent with fresh context - impossible to degrade.

See: references/scope-estimation.md </principle>

<principle name="human_checkpoints"> **Claude automates everything that has a CLI or API.** Checkpoints are for verification and decisions, not manual work.

**Checkpoint types:**

• `checkpoint:human-verify` - Human confirms Claude's automated work (visual checks, UI verification)
• `checkpoint:decision` - Human makes implementation choice (auth provider, architecture)

**Rarely needed:** `checkpoint:human-action` - Only for actions with no CLI/API (email verification links, account approvals requiring web login with 2FA)

**Critical rule:** If Claude CAN do it via CLI/API/tool, Claude MUST do it. Never ask human to:

• Deploy to Vercel/Railway/Fly (use CLI)
• Create Stripe webhooks (use CLI/API)
• Run builds/tests (use Bash)
• Write .env files (use Write tool)
• Create database resources (use provider CLI)

**Protocol:** Claude automates work → reaches checkpoint:human-verify → presents what was done → waits for confirmation → resumes

See: references/checkpoints.md, references/cli-automation.md </principle>

<principle name="deviation_rules"> Plans are guides, not straitjackets. Real development always involves discoveries.

**During execution, deviations are handled automatically via 5 embedded rules:**

1. **Auto-fix bugs** - Broken behavior → fix immediately, document in Summary 2. **Auto-add missing critical** - Security/correctness gaps → add immediately, document 3. **Auto-fix blockers** - Can't proceed → fix immediately, document 4. **Ask about architectural** - Major structural changes → stop and ask user 5. **Log enhancements** - Nice-to-haves → auto-log to ISSUES.md, continue

**No user intervention needed for Rules 1-3, 5.** Only Rule 4 (architectural) requires user decision.

**All deviations documented in Summary** with: what was found, what rule applied, what was done, commit hash.

**Result:** Flow never breaks. Bugs get fixed. Scope stays controlled. Complete transparency.

See: workflows/execute-phase.md (deviation_rules section) </principle>

<principle name="ship_fast_iterate_fast"> No enterprise process. No approval gates. No multi-week timelines. Plan → Execute → Ship → Learn → Repeat.

**Milestone-driven:** Ship v1.0 → mark milestone → plan v1.1 → ship → repeat. Milestones mark shipped versions and enable continuous iteration. </principle>

<principle name="milestone_boundaries"> Milestones mark shipped versions (v1.0, v1.1, v2.0).

**Purpose:**

• Historical record in MILESTONES.md (what shipped when)
• Greenfield → Brownfield transition marker
• Git tags for releases
• Clear completion rituals

**Default approach:** Extend existing roadmap with new phases.

• v1.0 ships (phases 1-4) → add phases 5-6 for v1.1
• Continuous phase numbering (01-99)
• Milestone groupings keep roadmap organized

**Archive ONLY for:** Separate codebases or complete rewrites (rare).

See: references/milestone-management.md </principle>

<principle name="anti_enterprise_patterns"> NEVER include in plans:

• Team structures, roles, RACI matrices
• Stakeholder management, alignment meetings
• Sprint ceremonies, standups, retros
• Multi-week estimates, resource allocation
• Change management, governance processes
• Documentation for documentation's sake

If it sounds like corporate PM theater, delete it. </principle>

<principle name="context_awareness"> Monitor token usage via system warnings.

**At 25% remaining**: Mention context getting full **At 15% remaining**: Pause, offer handoff **At 10% remaining**: Auto-create handoff, stop

Never start large operations below 15% without user confirmation. </principle>

<