<< All versions

Skill v1.0.1

currentAutomated scan100/100
elliotjlt/claude-skill-potions/battle-plan

1 files

──Details
PublishedOctober 27, 2026 at 08:15 AM
Content Hashsha256:161be0ce3856172f...
Git SHA8858a8fe8661
Bump Typepatch
Compare with v1.0.0
──Files
Files (1 file, 7.7 KB)
SKILL.md7.7 KBactive
SKILL.md · 330 lines · 7.7 KB

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 metadata: version: "1.0.1"

Battle Plan

<purpose> 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. </purpose>

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:

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?
← v1.0.0All versions