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?

battle-plan