Battle Plan
When To Activate
Trigger before:
- New feature implementation
- Refactors touching multiple files
- External service integrations
- Database migrations
- "Significant" or "important" tasks (user's words)
- Anything estimated >15 minutes
Do NOT trigger for:
- Typo fixes
- Single-line changes
- Questions/exploration
- Tasks user explicitly says are trivial
Instructions
Phase 1: Scope (uses rubber-duck patterns)
Before anything, clarify what we're actually building:
Scope Check
What are we building?
-> [Clear description of the goal]
What's the definition of done?
-> [Specific, verifiable completion criteria]
What's explicitly OUT of scope?
-> [Things we're NOT doing, even if related]
Any ambiguity I should clarify before planning?If scope is vague, ask clarifying questions. Do not proceed with vague scope.
Phase 2: Recon
Map the terrain before planning the attack:
Recon
Files likely affected:
- [file1.py] - [why]
- [file2.py] - [why]
Existing patterns to follow:
- [Pattern observed in codebase]
Dependencies/callers to check:
- [What depends on code we're changing]
Tests that exist:
- [Relevant test files]Use find, grep, head to actually explore. Don't guess.
Phase 3: Risks (uses pre-mortem patterns)
Imagine it's 2 weeks later and this failed. Why?
Pre-mortem
If this fails, it's probably because:
1. HIGH: [Specific risk]
Mitigation: [How to prevent]
2. MED: [Specific risk]
Mitigation: [How to prevent]
3. LOW: [Specific risk]
Mitigation: [How to prevent]Reorder plan to address HIGH risks first.
Phase 4: Estimate (uses eta patterns)
Provide realistic Claude-time estimate:
Estimate
Scope: [X files, Y estimated lines changed]
Complexity: [Simple / Medium / Complex]
Breakdown:
- Recon & setup: ~X min
- Implementation: ~Y min
- Testing: ~Z min
- Verification: ~W min
Total: ~[range] minutes
Checkpoint: [If >15 min, where's the halfway check-in?]Phase 5: The Plan
Now write the actual plan - structured, not prose:
Battle Plan: [Task Name]
SCOPE
Goal: [One sentence]
Done when: [Verifiable criteria]
Not doing: [Explicit exclusions]
STEPS
1. [ ] [Step] -> [Output/artifact]
Confidence: HIGH/MED/LOW
2. [ ] [Step] -> [Output/artifact]
Confidence: HIGH/MED/LOW
Depends on: Step 1
3. [ ] [Step] -> [Output/artifact]
Confidence: HIGH/MED/LOW
RISKS & MITIGATIONS
[Risk 1] -> [Mitigation baked into steps]
[Risk 2] -> [Mitigation baked into steps]
ROLLBACK
If this goes wrong: [How to undo safely]
ESTIMATE
~[X-Y] minutes
Checkpoint at: [Step N / halfway point]
Ready to execute?Phase 6: Confirmation (uses you-sure patterns)
Do not proceed without explicit approval:
Type 'go' to execute this plan, or tell me what to adjust.Accept only:
- "go" / "proceed" / "execute" -> Start work
- Feedback -> Adjust plan and re-present
- "abort" -> Cancel
Confidence Levels
For each step, assess confidence:
HIGH - Done this before, clear path, low ambiguity MED - Reasonable approach, some unknowns LOW - Best guess, might need to pivot
If multiple steps are LOW confidence, flag it:
Several steps have LOW confidence. Consider spiking/prototyping first?Composability Note
This skill orchestrates patterns from:
- rubber-duck - Scope clarification
- pre-mortem - Risk assessment
- eta - Time estimation
- you-sure - Confirmation gate
If those skills are installed, their full capabilities enhance this ritual. If not, this skill includes the core patterns inline.
NEVER
- Start coding without presenting the battle plan
- Proceed without explicit confirmation
- Skip risk assessment for "simple" significant tasks
- Provide single-point estimates (always give ranges)
- Hide low confidence behind confident language
ALWAYS
- Map actual files before planning (recon is real, not imagined)
- Include rollback strategy
- Set checkpoint for tasks >15 minutes
- Surface confidence levels honestly
- Respect scope boundaries during execution
Example
User: "Add Stripe payment integration"
Scope Check
What are we building?
-> Accept one-time payments via Stripe Checkout
Definition of done:
-> User can click "Pay", complete Stripe Checkout, and see success confirmation
-> Payment recorded in our database
-> Works in test mode with test cards
Explicitly OUT of scope:
-> Subscriptions (future task)
-> Refunds (future task)
-> Multiple payment methods (just card for now)
Any ambiguity?
-> Should failed payments show inline error or redirect to error page?
[User answers: inline error]
Recon
Files likely affected:
- routes/payments.py - new endpoints
- models/order.py - add payment_status field
- templates/checkout.html - payment button
- tests/test_payments.py - new file
Existing patterns:
- Routes use Flask blueprints
- Models use SQLAlchemy with migrations
- Tests use pytest + fixtures
Dependencies:
- Order model used by 3 other routes
- Checkout template included in 2 places
Pre-mortem
If this fails in 2 weeks, it's probably because:
1. HIGH: Webhook signature validation wrong
Mitigation: Set up Stripe CLI, test webhooks FIRST
2. HIGH: Test vs live key confusion
Mitigation: Env validation on startup
3. MED: No idempotency on payment creation
Mitigation: Add idempotency key from start
Estimate
Scope: 4 files, ~200 lines
Complexity: Medium
Breakdown:
- Stripe CLI + webhook setup: ~5 min
- Payment endpoints: ~10 min
- Database migration: ~5 min
- Frontend integration: ~8 min
- Testing: ~12 min
Total: ~35-45 minutes
Checkpoint: After webhook setup works (~15 min mark)
Battle Plan: Stripe Payment Integration
SCOPE
Goal: One-time payments via Stripe Checkout
Done when: Test payment completes end-to-end
Not doing: Subscriptions, refunds, multi-method
STEPS
1. [ ] Set up Stripe CLI + webhook endpoint -> Working signature validation
Confidence: HIGH
2. [ ] Add payment routes (create session, success, webhook) -> Endpoints responding
Confidence: HIGH
Depends on: Step 1
3. [ ] Database migration for payment_status -> Migration applied
Confidence: HIGH
4. [ ] Frontend checkout button -> Redirects to Stripe
Confidence: MED (need to check existing JS patterns)
Depends on: Step 2
5. [ ] Integration tests with Stripe test mode -> Tests passing
Confidence: HIGH
Depends on: Steps 1-4
RISKS & MITIGATIONS
Webhook validation -> Addressed in Step 1 (before business logic)
Key confusion -> Env check added in Step 2
Idempotency -> Built into Step 2
ROLLBACK
If broken: Revert migration, remove routes, disable checkout button
Data safety: No production payments until explicitly switched to live keys
ESTIMATE
~35-45 minutes
Checkpoint at: Step 1 complete (webhook working)
Ready to execute?