企业官网建设流程全解析

Claude Code Game Studios 项目阶段分析报告：基于 /project-stage-detect 的全项目体检与缺口诊断模板

【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios

项目阶段分析报告（Project Stage Analysis Report）是 Claude Code Game Studios 为游戏开发项目提供"全项目体检"的标准化输出文档：它由 project-stage-detect 技能 驱动，通过扫描设计、代码、架构、生产、测试、原型六类产物，判定项目当前所处开发阶段、量化完整性缺口，并产出带优先级与角色视角的建议。读者学完本文，将掌握报告模板每一节的填写语义与生成流程，理解阶段分类的启发式规则，并能将报告与/gate-check阶段门禁、/milestone-review里程碑评审衔接成完整的开发治理闭环。

一、模板在项目中的定位与生成链路

该模板文件位于 .claude/docs/templates/project-stage-report.md，是整个工作流中"诊断类"产出的唯一标准格式。它由/project-stage-detect技能（定义见 .claude/skills/project-stage-detect/SKILL.md）在第四步"Generate Stage Report"时使用。

在仓库的整套技能体系中，该技能适合在以下场景触发：

• 接手一个已有项目、首次摸清家底时；
• 新成员 onboard 代码库时；
• 里程碑前检查还缺什么产物时；
• 回答"我们现在开发到哪一步了（where are we?）"这一核心问题时。

技能本身是只读诊断型技能（Read-only diagnostic skill），不需要委派专家 Agent，使用轻量模型（model: haiku）即可运行。其完整工作流分为六步：扫描关键目录 → 分类项目阶段 → 协作式缺口识别 → 生成阶段报告 → 角色过滤建议 → 写入前征求批准。模板承担的是第四步的输出载体，同时报告中的"Follow-Up Skills"一栏也直接复用其余步骤的结论。

值得强调的是该技能与/gate-check的职责分工：/project-stage-detect是诊断（"我们在哪"），而/gate-check是裁决（"我们是否准备好前进"并给出正式结论），两者互补但不可互相替代，这一点在 gate-check 技能定义 中有明确区分。

二、报告头：生成时间、阶段与分析范围

模板头部是三组元数据，用于标注报告的可追溯性：

其中 Stage 的七种取值对应仓库 workflow-catalog.yaml 中定义、并由/gate-check强化的完整开发流水线：Concept（头脑风暴、游戏概念文档）→Systems Design（系统分解、编写 GDD）→Technical Setup（引擎配置、架构决策）→Pre-Production（原型、垂直切片验证）→Production（Epic/Feature/Task 追踪下的功能开发）→Polish（性能、试玩、修 Bug）→Release（发布准备、认证）。

阶段判定的优先级规则：先检查production/stage.txt——若该文件存在，直接采用其值（这是/gate-check通过门禁后写入的显式覆盖，例如echo -n "Production" > production/stage.txt）；否则按"从最成熟阶段向前倒查"的启发式自动检测，详见本文第五节的判定表。

三、Executive Summary：执行摘要

执行摘要是报告的门面，模板要求在一到两段内说清三件事：

1. 项目整体状态：概述项目当前状态、主要缺口与推荐优先级；
2. Current Focus（当前焦点）：项目正在积极推进的工作；
3. Blocking Issues（阻塞问题）：阻碍进展的关键缺口；
4. Estimated Time to Next Stage（预计进入下一阶段的时间）：如适用则填写。

填写这段时，信息来自后续所有章节的结论浓缩。根据技能的协作协议（见 project-stage-detect SKILL.md），在正式落笔写报告前，Agent 应先向用户展示摘要级发现并请求批准："I've analyzed your project. Here's what I found… May I write the full stage analysis to production/project-stage-report.md?"，未经批准不得静默写文件——这是整个仓库坚持的"Question First → Present Options → User Decides → Show Draft → Get Approval"协作原则的一部分。

四、Completeness Overview：六维完整性盘点

这是报告的主体，对项目六个维度逐一给出完成度百分比、文件计数、关键缺口清单。每个维度都对应仓库中约定的物理目录（见 directory-structure.md）。

4.1 Design Documentation（设计文档）

• Status：[X%]完成度；
• Files Found：design/下的文档数，细分design/gdd/的 GDD 章节数、design/narrative/的叙事文档数、design/levels/的关卡设计数；
• Key Gaps：列出缺失文档及缺失原因（例如"缺少战斗系统 GDD，导致程序无法按规格实现"）。

技能在扫描该维度时（SKILL.md）会进一步检查game-concept.md、game-pillars.md、systems-index.md是否存在；若systems-index.md存在，则统计"系统总数 vs 已设计系统数"，并逐份评估 GDD 的 Overview、Detailed Design、Edge Cases 等章节完整性。

4.2 Source Code（源码）

• Status：[X%]完成度；
• Files Found：src/下的源文件数；
• Major Systems Identified：以 ✅（正常）、⚠️（有问题或不完整）标注主要系统，并给出其src/path/；
• Key Gaps：缺失系统及其影响。

扫描规则是：统计源文件数量（语言无关）、识别主要系统（含 5 个以上文件的目录视为一个系统）、检查core/、gameplay/、ai/、networking/、ui/等标准子目录、粗估代码行数规模。

4.3 Architecture Documentation（架构文档）

• Status：完成度百分比；
• ADRs Found：docs/architecture/下的架构决策记录（ADR）数量；
• Coverage：逐项用 ✅/⚠️/❌ 标注——已记录、已实现但未记录、既未实现也未决策；
• Key Gaps：缺失的 ADR 及需要它的原因。

这与 workflow-catalog.yaml 中 Technical Setup 阶段的要求呼应：架构文档（docs/architecture/architecture.md）与至少 3 份 Foundation 层 ADR（docs/architecture/adr-*.md，min_count: 3）是进入 Pre-Production 的必需产物。

4.4 Production Management（生产管理）

• Status：完成度百分比；
• Found：production/sprints/的冲刺计划数、production/milestones/的里程碑数、Roadmap 是否存在；
• Key Gaps：缺失的生产产物及其影响。

仓库的生产目录还承载了/start技能写入的production/review-mode.txt（Full/Lean/Solo 三档评审模式）与/gate-check写入的production/stage.txt，这些文件是阶段与评审治理的状态源。

4.5 Testing（测试）

• Status：覆盖率（估算）；
• Test Files：tests/下测试文件数；
• Coverage by System：按系统给出估算覆盖率；
• Key Gaps：缺失测试领域及风险。

注意模板明确标注该覆盖率是estimated——技能只做粗略启发式估算，不生产精确指标。

4.6 Prototypes（原型）

• Active Prototypes：prototypes/下的活动原型数，标注 ✅ 有 README、⚠️ 无 README 状态不明；
• Archived：已归档原型数（完成实验）；
• Key Gaps：未文档化的原型及原因。

五、Stage Classification Rationale：阶段分类依据

这一节回答"为什么判定为当前阶段"，是报告最有方法论价值的部分。技能在 SKILL.md 中给出了完整启发式判定表（从最成熟阶段向前倒查）：

模板要求在这一节回答三个子问题：

1. Why [Stage]?— 基于已扫描到的指标解释分类原因；
2. Indicators for this stage— 列出与当前阶段匹配的证据指标；
3. Next stage requirements— 以复选框列出进入下一阶段的必要条件（例如从 Pre-Production 进入 Production 需要：至少 1 个带 README 的原型、首个冲刺计划、完整的 Art Bible、可玩且经过 3 次以上内部试玩的垂直切片等，完整清单见 gate-check SKILL.md）。

六、Gaps Identified：分级缺口与澄清问题

模板将缺口按影响分为三级，每级都遵循"Impact → Question → Suggested Action"三段式结构——这是整套仓库"协作式缺口识别"的核心体现：不要只罗列缺失文件，而要针对缺口先提出澄清问题。技能给出了大量真实对话范例（SKILL.md）：

• "我看到了战斗代码（src/gameplay/combat/）但没有design/gdd/combat-system.md。这是先原型后文档，还是需要反向文档化？"（→ 对应/reverse-document）
• "你有 15 份 ADR 但没有架构总览。是否需要我创建一份以帮助新贡献者？"
• "production/下没有冲刺计划。你们在其他地方（Jira、Trello 等）跟踪工作吗？"
• "我找到了游戏概念但没有 systems index。你是否已将概念分解为独立系统，还是应该运行/map-systems？"
• "prototypes/下有 3 个项目没有 README。这些是实验还是需要文档化？"

三级缺口的填写语义：

1. Critical Gaps（阻塞进展）— 例如缺失 GDD 导致程序员无法开工、无 ADR 导致架构决策悬空；
2. Important Gaps（影响质量/速度）— 例如测试覆盖不足导致回归风险累积；
3. Nice-to-Have Gaps（打磨/最佳实践）— 例如原型缺少 README、文档格式不统一。

七、Recommended Next Steps：分优先级行动建议

模板把下一步行动分成三个时间窗，每条行动标注建议技能与预估工作量（S/M/L）：

• Immediate Priority（立即执行）：标明/[skill-name]或人工处理，给出 S/M/L 工作量估计；
• Short-Term（本冲刺/本周）：近期必须推进的事项；
• Medium-Term（下一里程碑）：中期需求。

技能在 Follow-Up Actions 一节 给出了"缺口 → 技能"的映射表，可直接用于填充此节：

八、Role-Specific Recommendations：角色视角建议

当用户以角色参数调用（/project-stage-detect programmer）时，报告追加角色过滤建议。技能定义了四类视角（SKILL.md）：

• Programmer：聚焦架构文档、测试覆盖、缺失 ADR，以及"代码与文档之间的缝隙"；
• Designer：聚焦 GDD 完整性、缺失设计章节、原型文档化；
• Producer：聚焦冲刺计划、里程碑跟踪、路线图，以及跨团队协调文档；
• General（无角色）：全缺口综合视图，给出跨领域最高优先级事项。

模板中每个角色小节需给出 Focus areas（优先领域）、Blockers（阻塞项）、Next tasks（下一步任务清单）。

九、Follow-Up Skills to Run：后续技能清单

模板在此节列出基于缺口生成的候选技能调用，每个条目包含命令、用途说明：

• /reverse-document [type] [path]— 针对需要反向文档化的缺口；
• /architecture-decision— 针对缺失 ADR；
• /sprint-plan— 生产规划缺失时；
• /milestone-review— 临近截止日期时；
• /onboard [role]— 有新贡献者加入时。

这些命令的完整语义与参数格式可查阅 .claude/skills/reverse-document/SKILL.md（如/reverse-document design src/gameplay/magic-system）、.claude/skills/milestone-review/SKILL.md（产出 GO / CONDITIONAL GO / NO-GO 结论）等技能定义。

十、Appendix：按目录统计文件数

报告结尾以代码块形式给出标准目录的文件计数快照，作为全篇数据的机器可读附录。模板约定的统计口径：

design/ gdd/ [N] files narrative/ [N] files levels/ [N] files src/ core/ [N] files gameplay/ [N] files ai/ [N] files networking/ [N] files ui/ [N] files docs/ architecture/ [N] ADRs production/ sprints/ [N] plans milestones/ [N] definitions tests/ [N] test files prototypes/ [N] directories

该目录树与仓库 directory-structure.md 中约定的顶层布局一致（src/下含 core/gameplay/ai/networking/ui/tools，production/下含 session-state 与 session-logs），保证报告计数与工程实际目录一一对应。报告以End of Report标记收尾，并注明"Generated by/project-stage-detectskill"。

十一、报告之后的治理闭环：与门禁和评审的衔接

阶段分析报告本身是诊断，不是裁决。一份报告产出后，自然的后续是：

1. 推进阶段转换→ 运行/gate-check [target-phase]，获得 PASS / CONCERNS / FAIL 正式结论；门禁通过并经用户确认后，将新阶段名写入production/stage.txt立即更新状态行；
2. 里程碑检查→ 运行/milestone-review [milestone-name|current]，读取production/milestones/与production/sprints/产出 Go/No-Go 评估；
3. 持续修正→ 报告中的关键缺口可由 quick-start.md 中的四条入门路径（无想法 / 有想法 / 有概念无引擎 / 已有项目）指引补齐。

由此，一份阶段分析报告从"体检单"升级为贯穿 Concept 到 Release 七阶段的持续治理数据源，这正是 Claude Code Game Studios 以 49 个 Agent、72 项工作流技能模拟真实工作室层级协作时，用于回答"项目到底走到哪一步、还缺什么、下一步干什么"的标准答案载体。

End of Article

参考文件：模板 .claude/docs/templates/project-stage-report.md · 技能 .claude/skills/project-stage-detect/SKILL.md · 门禁 .claude/skills/gate-check/SKILL.md · 工作流 .claude/docs/workflow-catalog.yaml · 目录约定 .claude/docs/directory-structure.md

【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios