<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:
- Auto-fix bugs - Broken behavior → fix immediately, document in Summary
- Auto-add missing critical - Security/correctness gaps → add immediately, document
- Auto-fix blockers - Can't proceed → fix immediately, document
- Ask about architectural - Major structural changes → stop and ask user
- 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 sakeIf 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>
<principle name="user_gates"> Never charge ahead at critical decision points. Use gates: - **AskUserQuestion**: Structured choices (2-4 options) - **Inline questions**: Simple confirmations - **Decision gate loop**: "Ready, or ask more questions?"Mandatory gates:
- Before writing PLAN.md (confirm breakdown)
- After low-confidence research
- On verification failures
- After phase completion with issues
- Before starting next phase with previous issues
See: references/user-gates.md </principle>
<principle name="git_versioning"> All planning artifacts are version controlled. Commit outcomes, not process.- Check for repo on invocation, offer to initialize
- Commit only at: initialization, phase completion, handoff
- Intermediate artifacts (PLAN.md, RESEARCH.md, FINDINGS.md) NOT committed separately
- Git log becomes project history
See: references/git-integration.md </principle>
</essential_principles>
<context_scan> Run on every invocation to understand current state:
# Check git status
git rev-parse --git-dir 2>/dev/null || echo "NO_GIT_REPO"
# Check for planning structure
ls -la .planning/ 2>/dev/null
ls -la .planning/phases/ 2>/dev/null
# Find any continue-here files
find . -name ".continue-here.md" -type f 2>/dev/null
# Check for existing artifacts
[ -f .planning/BRIEF.md ] && echo "BRIEF: exists"
[ -f .planning/ROADMAP.md ] && echo "ROADMAP: exists"
If NO_GIT_REPO detected:
Inline question: "No git repo found. Initialize one? (Recommended for version control)"
If yes: git init
Present findings before intake question. </context_scan>
<domain_expertise>
Domain expertise lives in ~/.claude/skills/expertise/
Before creating roadmap or phase plans, determine if domain expertise should be loaded.
<scan_domains>
ls ~/.claude/skills/expertise/ 2>/dev/null
This reveals available domain expertise (e.g., macos-apps, iphone-apps, unity-games, nextjs-ecommerce).
If no domain skills found: Proceed without domain expertise (graceful degradation). The skill works fine without domain-specific context. </scan_domains>
<inference_rules> If user's request contains domain keywords, INFER the domain:
| Keywords | Domain Skill |
|---|---|
| "macOS", "Mac app", "menu bar", "AppKit", "SwiftUI desktop" | expertise/macos-apps |
| "iPhon |