battle-plan

name	battle-plan
description	Before ANY significant development task (new feature, refactor, integration, migration), run a complete planning ritual by orchestrating other skills in sequence: rubber-duck (clarify scope) -> pre-mortem (assess risks) -> eta (estimate time) -> final confirmation. Do not start coding until the battle plan is approved.
allowed-tools	bash: find, grep, cat, head, ls, wc, python file: read

Battle Plan

Claude Code's built-in plan mode is just "read-only mode + write a markdown file." It doesn't assess risks, estimate time, define done, or check scope. This skill orchestrates a complete planning ritual using composable skills before any significant work begins.

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?