游戏平衡检查：当需要排查战斗、经济…

适用于有设计文档和数值数据文件的游戏项目，按战斗/经济/成长/掉落领域检查平衡并输出可执行修复与验证循环。

适用场景

解决思路

1. 在生成任何报告前，先列出本技能会读取的输入：数据文件、既有报告、profiler 输出、测试结果、注册表、源代码。
2. 对每个输入记录为 `FOUND` 或 `ABSENT`，不要假设存在。
3. 如果某个 section 所需输入为 `ABSENT`，将该 section 标为 `NOT ASSESSED — NO DATA`；不要估算、不要从相邻产物推断、不要留空给后续填写。
4. 如果所有必需输入均为 `ABSENT`，停止并整体报告 `NOT ASSESSED — NO DATA`，说明缺失内容及哪个技能能生成它；把 NOT ASSESSED 视为成功，并区分“没有文件可扫描”和“扫描后无匹配”。
5. 每次调用 `AskUserQuestion` 都遵循 `.claude/docs/automation-modes.md`：collaborative 总是询问；guided 仅主要问题询问；autonomous 记录并继续；`automation_always_ask` 类别总是提示。
6. 运行自动化配置解析：source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 并调用 `resolve_config --keys automation`（若可用）。
7. Phase 1：根据 `$ARGUMENTS[0]` 确定平衡领域：Combat → 武器/技能 DPS、time-to-kill、伤害类型交互；Economy → 资源 faucets/sinks、获取率、物品定价；Progression → XP/战力曲线、dead zones、power spikes；Loot → 稀有度分布、pity timers、背包压力；给定文件路径 → 直接加载该文件并根据内容推断领域。
8. Phase 1：如果没有参数，询问用户要检查哪个系统。
9. Phase 2：从 `assets/data/` 和 `design/balance/` 读取与已识别领域相关的文件，并记录每个读取的文件，用于报告 Data Sources。
10. Phase 3：优先读取注册表：如果 `design/registry/entities.yaml` 存在，先于 GDD 读取。其 `constants` 和 `formulas` 区块保存跨 GDD 的命名值和输出范围（平衡目标），含 `source:` GDD 和 `revised:` 日期；对其中列出的常量和公式，以注册表意图值为权威，GDD 不得矛盾。
11. Phase 3：使用 Grep 读取注册表条目：`Grep pattern="^ - name:" path="design/registry/entities.yaml" output_mode="content" -A 6`。
12. Phase 3：如果 `design/registry/entities.yaml` 不存在或没有条目（它作为空 stub 直到 `/design-system` 填充），跳过注册表，单独使用 GDD。
13. Phase 3：然后从 `design/gdd/` 读取该系统的 GDD，理解注册表未提供的预期设计目标、调参旋钮和期望值范围，将其作为“正确”行为的基线。
14. Phase 4 Combat balance：计算所有武器/技能在每个 power tier 的 DPS。
15. Phase 4 Combat balance：检查每个 tier 的 time-to-kill。
16. Phase 4 Combat balance：识别严格优于其他选项的 dominating options。
17. Phase 4 Combat balance：检查防御选项是否会产生不可击杀状态。
18. Phase 4 Combat balance：验证伤害类型/抗性交互是否平衡。
19. Phase 4 Economy balance：映射所有资源 faucets 和 sinks 及其 flow rates。
20. Phase 4 Economy balance：预测资源随时间的累积。
21. Phase 4 Economy balance：检查无限资源循环。
22. Phase 4 Economy balance：验证 gold sinks 随 gold generation 扩展。
23. Phase 4 Economy balance：检查是否有物品永远不值得购买。
24. Phase 4 Progression balance：绘制 XP 曲线和 power 曲线。
25. Phase 4 Progression balance：检查 dead zones（过长时间没有有意义进展）。
26. Phase 4 Progression balance：检查 power spikes（能力突然跃升）。
27. Phase 4 Progression balance：验证内容门禁与预期玩家战力一致。
28. Phase 4 Progression balance：检查 skip/grind 策略是否破坏预期节奏。
29. Phase 4 Loot balance：计算获取每个稀有度层级的预期时间。
30. Phase 4 Loot balance：检查 pity timer 数学。
31. Phase 4 Loot balance：验证没有 loot 在任何阶段严格无用。
32. Phase 4 Loot balance：检查 inventory pressure 与 acquisition rate。
33. Phase 5：输出 `## Balance Check: [System Name]`。
34. Phase 5：输出 `### Data Sources Analyzed`，列出读取的文件。
35. Phase 5：输出 `### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]`。
36. Phase 5：输出 `### Outliers Detected` 表格，列为 `Item/Value | Expected Range | Actual | Issue`。
37. Phase 5：输出 `### Degenerate Strategies Found`，描述问题策略及为何有问题。
38. Phase 5：输出 `### Progression Analysis`，用图描述或表格展示 progression curve health。
39. Phase 5：输出 `### Recommendations` 表格，列为 `Priority | Issue | Suggested Fix | Impact`。
40. Phase 5：输出 `### Values That Need Attention`，给出具体值和调整建议及理由。
41. Phase 6：报告后用 `AskUserQuestion` 提示“Balance check complete. What would you like to do next?”，选项为 `[A] Fix highest-priority issue now — walk me through it`、`[B] Save report to design/balance/balance-check-[system]-[date].md`、`[C] Stop here — I'll review the findings manually`。
42. Phase 6 选 [A] 时：询问先处理哪个问题（按 Recommendations 表的 priority 行）。引导用户更新 `assets/data/` 中相关数据文件或 `design/balance/` 中公式。每次修复后，提议重新运行相关平衡检查，验证没有引入新 outlier。如果修复改变 GDD 中定义的调参旋钮或被 ADR 引用的值，提醒：“This value is defined in a design document. Run `/propagate-design-change [path]` on the affected GDD to find downstream impacts before committing.”
43. Phase 6 选 [B] 时：将报告写入 `design/balance/balance-check-[system]-[date].md`（必要时创建目录），[date] 用当前日期 YYYY-MM-DD。确认文件已写入，然后以“Re-run `/balance-check` after fixes to verify.”结束。
44. Phase 6 选 [C] 时：汇总未解决问题，并以“Re-run `/balance-check` after fixes to verify.”结束。

适用边界 · 注意事项

• 当必需输入（数据文件、既有报告、profiler 输出、测试结果、注册表、源代码等）缺失时，不要强行生成报告；正确结果是 `NOT ASSESSED — NO DATA`。
• 没有 GDD、设计目标或注册表中的平衡目标时，无法判断期望范围和 outlier，不应编造健康结论。
• 不适用于非游戏数值平衡领域（如通用代码性能、安全审计），除非存在可检查的公式、目标范围和对应数据。