85f0ea5c58
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 plans use `type: tdd` frontmatter with `<feature>` element - One feature per TDD plan (batching defeats the purpose) - Target ~40% context usage for TDD plans - Standard plans handle non-TDD work with 2-3 tasks 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
158 lines
4.8 KiB
Markdown
158 lines
4.8 KiB
Markdown
<principles>
|
|
Core principles for the Gets Shit Done planning system.
|
|
|
|
<solo_developer_claude>
|
|
|
|
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
|
|
</solo_developer_claude>
|
|
|
|
<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 (with verification criteria)
|
|
- Success criteria (measurable)
|
|
|
|
When planning a phase, you are writing the prompt that will execute it.
|
|
</plans_are_prompts>
|
|
|
|
<initialization_leverage>
|
|
|
|
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"
|
|
</initialization_leverage>
|
|
|
|
<scope_control>
|
|
|
|
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
|
|
</scope_control>
|
|
|
|
<claude_automates>
|
|
|
|
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)
|
|
</claude_automates>
|
|
|
|
<deviation_rules>
|
|
|
|
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
|
|
</deviation_rules>
|
|
|
|
<test_driven_when_beneficial>
|
|
|
|
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.
|
|
</test_driven_when_beneficial>
|
|
|
|
<ship_fast>
|
|
|
|
No enterprise process. No approval gates.
|
|
|
|
Plan → Execute → Ship → Learn → Repeat
|
|
|
|
Milestones mark shipped versions (v1.0 → v1.1 → v2.0).
|
|
</ship_fast>
|
|
|
|
<atomic_commits>
|
|
|
|
**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.
|
|
</atomic_commits>
|
|
|
|
<anti_enterprise>
|
|
|
|
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.
|
|
</anti_enterprise>
|
|
</principles>
|