Menü
从现有实现生成设计或架构文档。从代码/原型逆向工作，创建缺失的规划文档。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
创建架构决策记录（Architecture Decision Record, ADR），记录重大技术决策及其背景、备选方案和影响后果。每个重大技术选择都应有对应的 ADR。
根据描述创建结构化的缺陷报告，或分析代码以识别潜在缺陷。确保每份缺陷报告包含完整的复现步骤、严重程度评估和上下文信息。
通过分析复杂度、依赖关系、历史速度和风险因素来估算任务工作量。生成包含置信水平的结构化估算。
运行本地化工作流：提取字符串、验证本地化就绪状态、检查硬编码文本，并生成可供翻译的字符串表。
将游戏概念拆解为独立系统，映射依赖关系，确定设计优先级，并创建系统索引。
生成全面的里程碑进度审查，包括功能完成度、质量指标、风险评估和推进/暂停建议。在里程碑检查点或评估里程碑截止日期的准备情况时使用。
| name | reverse-document |
| description | 从现有实现生成设计或架构文档。从代码/原型逆向工作，创建缺失的规划文档。 |
| argument-hint | <类型> <路径>（例如 'design src/gameplay/combat' 或 'architecture src/core'） |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit, Bash |
本技能分析现有实现（代码、原型、系统）并生成相应的设计或架构文档。适用于以下场景：
格式：/reverse-document <类型> <路径>
类型选项：
design -> 生成游戏设计文档 (GDD 章节)architecture -> 生成架构决策记录 (ADR)concept -> 从原型生成概念文档路径：要分析的目录或文件
src/gameplay/combat/ -> 所有战斗相关代码src/core/event-system.cpp -> 特定文件prototypes/stealth-mech/ -> 原型目录示例：
/reverse-document design src/gameplay/magic-system
/reverse-document architecture src/core/entity-component
/reverse-document concept prototypes/vehicle-combat
阅读并理解代码/原型：
对于设计文档 (GDD)：
对于架构文档 (ADR)：
对于概念文档（原型分析）：
不要只是描述代码。要问关于意图：
设计问题：
架构问题：
概念问题：
在起草之前，展示你发现了什么：
我已经分析了 src/gameplay/combat/。以下是我的发现：
已实现的机制：
- 3 连击系统，带时机窗口
- 破防机制（重攻击 vs 格挡中的敌人）
- 体力系统（攻击/闪避时消耗，空闲时恢复）
- 击倒系统（累积触发脆弱状态）
发现的公式：
- 伤害 = 基础值 * (1 + 力量缩放 * 等级)
- 击倒累积 = 攻击击倒值 / (敌人.定力 * 0.5)
- 体力消耗 = 基础体力消耗 * (1 - 效率加成)
意图不明确的区域：
1. 体力系统 — 节奏控制还是资源管理？
2. 击倒 — 核心支柱还是辅助功能？
3. 伤害缩放 — 力量幻想还是需要调整？
在起草设计文档之前，能否请您澄清这些要点？
等待用户澄清意图后再起草。
根据类型，使用相应模板：
| 类型 | 模板 | 输出路径 |
|---|---|---|
design | templates/design-doc-from-implementation.md | design/gdd/[系统名称].md |
architecture | templates/architecture-doc-from-code.md | docs/architecture/[决策名称].md |
concept | templates/concept-doc-from-prototype.md | prototypes/[名称]/CONCEPT.md 或 design/concepts/[名称].md |
草稿结构：
协作协议：
我已经根据你的代码和澄清内容起草了战斗系统设计文档。
[展示关键章节：概述、机制、公式、设计意图]
我添加的内容：
- 根据你的澄清，将体力记录为 "节奏控制机制"
- 添加了代码中未涉及的边缘情况（如果体力在连击中途归零怎么办？）
- 标记了平衡隐患：高等级的指数伤害缩放
标记为不完整的章节：
- "敌人 AI 与击倒的交互"（尚未完全实现）
- "武器多样性和缩放"（目前只实现了剑）
可以将此内容写入 design/gdd/combat-system.md 吗？
等待批准。用户可能在写入前要求修改。
获得批准后，使用特殊标记写入文件：
---
status: reverse-documented
source: src/gameplay/combat/
date: 2026-02-13
verified-by: [用户名称]
---
# 战斗系统设计
> **注意**：本文档是从现有实现逆向工程得出的。
> 它记录了当前行为和经澄清的设计意图。某些部分可能不完整，
> 特别是实现不完整或意图不明确的地方。
[文档其余部分...]
写入后，建议下一步操作：
已写入 design/gdd/combat-system.md
建议后续工作：
1. 对战斗公式运行 /balance-check（指数缩放隐患）
2. 为体力系统的架构决策创建 ADR
3. 实现缺失的边缘情况：
- 连击中途体力归零的行为
- 闪避期间的击倒状态
4. 当实现武器多样性时扩展设计文档
需要我现在处理其中任何一项吗？
| 如果分析... | 使用模板... | 因为... |
|---|---|---|
src/gameplay/* | design-doc-from-implementation.md | 玩法机制 -> GDD |
src/core/*、src/ai/* | architecture-doc-from-code.md | 核心系统 -> ADR |
prototypes/* | concept-doc-from-prototype.md | 实验 -> 概念文档 |
src/networking/* | architecture-doc-from-code.md | 技术系统 -> ADR |
src/ui/* | design-doc-from-implementation.md | UI/UX -> 设计规范 |
用户: /reverse-document design src/gameplay/combat
代理: 我将分析你的战斗实现来创建设计文档。
[读取代码，发现机制、公式]
代理: 我已经分析了 src/gameplay/combat/。以下是我的发现：
[展示机制、公式、不明确的区域]
在起草之前，能否请您澄清：
1. 体力系统的意图？
2. 击倒是核心支柱吗？
3. 伤害缩放 — 有意为之还是需要调整？
用户: 1. 体力是为了节奏控制，防止乱按
2. 击倒是核心 — 我想要深思熟虑的战斗
3. 对，指数缩放太过分了，应该是线性的
代理: 明白了，这澄清了愿景。让我起草设计文档。
[展示含澄清意图的草稿]
可以将此内容写入 design/gdd/combat-system.md 吗？
用户: 好，写入吧。
代理: 已写入 design/gdd/combat-system.md
已标记为 [逆向文档化]
已标记伤害缩放需要重新平衡
后续步骤：
- 将伤害公式更新为线性缩放
- 运行 /balance-check 验证成长曲线
- 在 game-pillars.md 中将击倒记录为核心支柱
本技能遵循协作设计原则：
绝不要假设意图。在记录 "为什么" 之前，始终先询问。