battle-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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>

<purpose> Claude Code的内置计划模式只是“只读模式 + 编写Markdown文件”。它不评估风险、预估时间、定义完成标准或检查范围。本技能会在任何重要工作开始前，通过组合式技能协调完成一套完整的规划流程。 </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

在以下场景前触发：

新功能实现
涉及多文件的重构
外部服务集成
数据库迁移
用户标注为“重大”或“重要”的任务
预估耗时超过15分钟的任何任务

请勿在以下场景触发：

拼写错误修复
单行代码修改
问题咨询/探索性任务
用户明确说明为琐碎的任务

Instructions

操作说明

Phase 1: Scope (uses rubber-duck patterns)

阶段1：范围确认（使用rubber-duck模式）

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

阶段2：侦察

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.

在规划行动前先梳理现状：

侦察

可能受影响的文件：
- [file1.py] - [原因]
- [file2.py] - [原因]

需要遵循的现有模式：
- [代码库中观察到的模式]

需要检查的依赖/调用方：
- [依赖我们要修改的代码的内容]

已存在的测试：
- [相关测试文件]

使用

find

、

grep

、

head

命令实际探索，不要猜测。

Phase 3: Risks (uses pre-mortem patterns)

阶段3：风险评估（使用pre-mortem模式）

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.

假设两周后任务失败，分析原因：

事前风险分析

如果任务失败，可能的原因：

1. 高风险：[具体风险]
   缓解措施：[预防方案]

2. 中风险：[具体风险]
   缓解措施：[预防方案]

3. 低风险：[具体风险]
   缓解措施：[预防方案]

调整计划顺序，优先处理高风险事项。

Phase 4: Estimate (uses eta patterns)

阶段4：时间预估（使用eta模式）

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?]

提供符合Claude能力的真实时间预估：

预估

范围：[X个文件，预估修改Y行代码]
复杂度：[简单 / 中等 / 复杂]

细分：
- 侦察与准备：~X分钟
- 实现：~Y分钟
- 测试：~Z分钟
- 验证：~W分钟

总计：~[时间范围]分钟

检查点：[如果超过15分钟，中途检查点在哪里？]

Phase 5: The Plan

阶段5：制定作战计划

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?

现在编写实际的计划——结构化而非散文式：

作战计划：[任务名称]

范围
  目标：[一句话描述]
  完成标准：[可验证的条件]
  排除事项：[明确不执行的内容]

步骤
  1. [ ] [步骤内容] -> [输出/产物]
       信心等级：高/中/低

  2. [ ] [步骤内容] -> [输出/产物]
       信心等级：高/中/低
       依赖：步骤1

  3. [ ] [步骤内容] -> [输出/产物]
       信心等级：高/中/低

风险与缓解措施
  [风险1] -> [已融入步骤的缓解方案]
  [风险2] -> [已融入步骤的缓解方案]

回滚策略
  如果出现问题：[如何安全撤销]

预估
  ~[X-Y]分钟
  检查点：[步骤N / 中途节点]

是否准备好执行？

Phase 6: Confirmation (uses you-sure patterns)

阶段6：最终确认（使用you-sure模式）

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

未获得明确批准不得推进：

输入'go'以执行本计划，或告知需要调整的内容。

仅接受以下指令：

"go" / "proceed" / "execute" -> 开始工作
反馈 -> 调整计划后重新提交
"abort" -> 取消任务

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.

本技能协调以下模式：

rubber-duck - 范围澄清
pre-mortem - 风险评估
eta - 时间预估
you-sure - 确认环节

如果已安装这些技能，它们的完整功能会增强本流程。如果未安装，本技能已内置核心模式。

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

规划前先梳理实际文件（侦察是真实的，而非想象）
包含回滚策略
对超过15分钟的任务设置检查点
如实披露信心等级
执行过程中严格遵守范围边界

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?

用户："添加Stripe支付集成"

范围检查

我们要构建什么？
-> 通过Stripe Checkout接受一次性付款

完成标准：
-> 用户可以点击“支付”，完成Stripe Checkout流程，并看到成功确认
-> 付款记录保存到我们的数据库
-> 在测试模式下支持测试卡付款

明确排除在范围外的内容：
-> 订阅功能（后续任务）
-> 退款功能（后续任务）
-> 多种付款方式（目前仅支持卡支付）

有任何模糊点吗？
-> 付款失败时应显示内联错误还是重定向到错误页面？

[用户回答：内联错误]

侦察

可能受影响的文件：
- routes/payments.py - 新增接口
- models/order.py - 添加payment_status字段
- templates/checkout.html - 支付按钮
- tests/test_payments.py - 新增文件

现有模式：
- 路由使用Flask蓝图
- 模型使用SQLAlchemy并支持迁移
- 测试使用pytest + 夹具

依赖项：
- Order模型被3个其他路由使用
- 结账模板在2个地方被引用

事前风险分析

如果两周后任务失败，可能的原因：

1. 高风险：Webhook签名验证错误
   缓解措施：设置Stripe CLI，首先测试Webhook

2. 高风险：测试密钥与生产密钥混淆
   缓解措施：启动时验证环境变量

3. 中风险：付款创建时没有幂等性
   缓解措施：从一开始就添加幂等键

预估

范围：4个文件，约200行代码
复杂度：中等

细分：
- Stripe CLI + Webhook设置：~5分钟
- 支付接口开发：~10分钟
- 数据库迁移：~5分钟
- 前端集成：~8分钟
- 集成测试（Stripe测试模式）：~12分钟

总计：~35-45分钟
检查点：Webhook设置完成后（约15分钟节点）

作战计划：Stripe支付集成

范围
  目标：通过Stripe Checkout接受一次性付款
  完成标准：测试付款端到端流程完成
  排除事项：订阅、退款、多付款方式

步骤
  1. [ ] 设置Stripe CLI + Webhook接口 -> 签名验证正常工作
       信心等级：高

  2. [ ] 添加支付路由（创建会话、成功回调、Webhook） -> 接口正常响应
       信心等级：高
       依赖：步骤1

  3. [ ] 为payment_status字段执行数据库迁移 -> 迁移完成
       信心等级：高

  4. [ ] 前端结账按钮集成 -> 可重定向到Stripe
       信心等级：中（需要检查现有JS模式）
       依赖：步骤2

  5. [ ] Stripe测试模式下的集成测试 -> 测试通过
       信心等级：高
       依赖：步骤1-4

风险与缓解措施
  Webhook验证 -> 步骤1已解决（在业务逻辑前处理）
  密钥混淆 -> 步骤2中添加环境变量检查
  幂等性 -> 步骤2中内置支持

回滚策略
  如果出现问题：回滚迁移，删除路由，禁用结账按钮
  数据安全：未明确切换到生产密钥前不处理生产环境付款

预估
  ~35-45分钟
  检查点：步骤1完成（Webhook正常工作）

是否准备好执行？