Core principles for the Gets Shit Done planning system. You are planning for ONE person (the user) and ONE implementer (Claude). - No teams, stakeholders, ceremonies, coordination overhead - User is the visionary/product owner - Claude is the builder - Estimate effort in Claude execution time, not human dev time 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 (with verification criteria) - Success criteria (measurable) When planning a phase, you are writing the prompt that will execute it. The most leveraged moment is project initialization. - Deep questioning here = better everything downstream - Garbage in = garbage out - Spend the tokens on context gathering - Don't rush to "the work" Plans must complete within reasonable context usage. **Quality degradation curve:** - 0-30% context: Peak quality - 30-50% context: Good quality - 50-70% context: Degrading quality - 70%+ context: Poor quality **Solution:** Aggressive atomicity - split into small, focused plans. - 2-3 tasks per plan maximum - Each plan independently executable - Better to have many small plans than few large ones If Claude CAN do it via CLI/API/tool, Claude MUST do it. Checkpoints are for: - **Verification** - Human confirms Claude's work (visual, UX) - **Decision** - Human makes implementation choice Not for: - Deploying (use CLI) - Creating resources (use CLI/API) - Running builds/tests (use Bash) - Writing files (use Write tool) Plans are guides, not straitjackets. During execution: 1. **Auto-fix bugs** - Fix immediately, document 2. **Auto-add critical** - Security/correctness gaps, add immediately 3. **Auto-fix blockers** - Can't proceed, fix immediately 4. **Ask about architectural** - Major changes, stop and ask 5. **Log enhancements** - Nice-to-haves, log to Issues, continue Use TDD when the work WOULD benefit from it. Not dogma—pragmatism. **TDD candidates (create dedicated TDD plan):** - Business logic with defined inputs/outputs - API endpoints and handlers - Data transformations and parsing - Validation rules - State machines and workflows - Anything where you can describe expected behavior before implementing **Skip TDD (use standard plan):** - UI layout and styling - Exploratory prototyping - One-off scripts and migrations - Configuration changes - Glue code with no logic **Decision heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`? → Yes: Create a TDD plan (one feature per plan) → No: Standard plan, add tests after if needed **Why TDD gets its own plan:** TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This consumes 40-50% of context for a single feature. Dedicated TDD plans ensure full quality throughout the cycle. **TDD plan structure:** 1. Write failing test (RED) → commit 2. Implement to pass (GREEN) → commit 3. Refactor if needed → commit This is about design quality, not test coverage metrics. See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure. No enterprise process. No approval gates. Plan → Execute → Ship → Learn → Repeat Milestones mark shipped versions (v1.0 → v1.1 → v2.0). **Git commits = context engineering for Claude.** Each task gets its own commit immediately after completion: - Format: `{type}({phase}-{plan}): {task-description}` - Types: feat, fix, test, refactor, perf, chore, docs - One final metadata commit per plan: `docs({phase}-{plan}): complete [plan-name]` **Why per-task commits:** - Git history becomes primary context source for future Claude sessions - `git bisect` finds exact failing task, not just failing plan - Each task independently revertable - Better failure recovery (task 1 committed ✅, retry task 2) - Observability optimized for AI workflow, not human browsing **Plans produce 3-4 commits total:** - 2-3 task commits (working code) - 1 metadata commit (SUMMARY + STATE + ROADMAP) See `~/.claude/get-shit-done/references/git-integration.md` for complete strategy. NEVER include: - Team structures, RACI matrices - Stakeholder management - Sprint ceremonies - Human dev time estimates (hours, days, weeks—Claude works differently) - Change management processes - Documentation for documentation's sake If it sounds like corporate PM theater, delete it.