CCGS /create-architecture 技能深度解析骨架优先、逐节审批与导演门禁的架构文档创作机制【免费下载链接】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导读/create-architecture是 Claude Code Game StudiosCCGS框架中负责产出「总架构文档」docs/architecture/architecture.md的核心创作技能它采用骨架优先skeleton-first策略先建立文档骨架再逐节草拟、逐节征求用户批准并在full审查模式下并行唤起技术总监TD-ARCHITECTURE与主程LP-FEASIBILITY两道导演门禁。本文以其在 CCGS Skill Testing Framework 中的行为规格 create-architecture.md 为骨架结合测试框架、导演代理规格与 工作流指南 中的管线上下文完整解析该技能的行为契约、五种测试场景、门禁判定词汇与周边协作链路帮助读者理解并验证这条「从架构文档到控制清单」的创作管道。一、技能定位什么是 /create-architecture从行为规格的 Skill Summary 可以提炼出该技能的四项核心职责引导式创作带领用户逐节撰写技术架构文档而不是一次性生成全文。骨架优先在填写任何内容之前先用全部必需的小节标题创建文件骨架保证会话中断后进度不丢失。逐节批准每一节都经过「讨论 → 草拟 → 展示 → 请求写入 → 批准后落盘」的循环。改造模式retrofit如果架构文档已存在技能切换到 retrofit 模式只更新用户指定的章节而不是重写整份文档。输出路径固定为docs/architecture/architecture.md这是 CCGS 技术管线的关键产物。规格还明确指出在full模式下完整草稿完成后会并行唤起两个门禁代理TD-ARCHITECTURE由技术总监technical-director执行的架构审查门禁LP-FEASIBILITY由主程lead-programmer执行的可行性审查门禁。而在lean或solo模式下两道门禁都会被跳过。从测试框架的 catalog.yaml 可见该技能被登记为authoring创作类别其规格路径正是CCGS Skill Testing Framework/skills/authoring/create-architecture.md是 72 个技能之一。二、行为契约静态断言Structural Assertions规格首先定义了由/skill-test static自动验证、无需任何测试夹具fixture的结构性断言它们本质上是该技能文件的「代码规范」断言项含义必需 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools五者齐全≥2 个阶段标题phase headings技能正文必须包含至少两个阶段化标题确保多阶段流程可见裁决关键字必须包含APPROVED、NEEDS REVISION、MAJOR REVISION NEEDED三个裁定词协作协议语言必须包含「May I write」逐节批准措辞区别于只读类技能结尾交接必须提供下一步交接指向/architecture-review或/create-control-manifest骨架优先必须文档化 skeleton-first 的创作流程门禁行为必须文档化 full 模式唤起 TD-ARCHITECTURE LP-FEASIBILITY、lean/solo 跳过的规则改造模式必须文档化针对既有架构文档的 retrofit 更新方式这些断言与测试框架模板 templates/skill-test-spec.md 中定义的通用静态断言一脉相承frontmatter 五字段、2 阶段标题、裁决关键字、写权限技能须含「May I write」语言、结尾交接段。可以推断/create-architecture属于「可写文件」类技能因此「May I write」是其必需协议。需要说明的是规格在 Coverage Notes 中特别注明架构文档的必需小节清单定义在技能正文与/architecture-review技能中并不在本规格内重复枚举。也就是说本节断言只保证「骨架存在且流程正确」而「骨架由哪些小节组成」属于另一份文档的职责边界。三、导演门禁full / lean / solo 三种模式的判定规则门禁是 CCGS 质量体系的核心机制。规格对此技能的门禁行为规定如下full 模式在所有章节草拟完毕、任何最终批准写入之前TD-ARCHITECTURE 与 LP-FEASIBILITY并行唤起不是串行两者均完成后才进入最终确认。lean 模式两道门禁均跳过输出中必须出现精确注释TD-ARCHITECTURE skipped — lean mode与LP-FEASIBILITY skipped — lean mode。solo 模式两道门禁同样跳过输出等价注释。这一「按模式裁决」的设计与 quality-rubric.md 对 authoring 类别的度量一致完整创作型技能design-system、ux-design、art-bible必须逐节走 A1/A2/A5 指标而quick-design、architecture-decision、create-architecture属于轻量创作技能允许「一次性成稿 一次性征求批准」的单稿模式适用于约 4 小时实现范围内的小文档。但轻量不意味着免检——门禁仍由full模式触发。从代理规格可以进一步拆解两道门禁的判定词汇与关注点技术总监 technical-director.md 负责 TD-ARCHITECTURE 门禁模型层级为 Opus其裁决词汇限定为APPROVE / CONCERNS / REJECT输出须格式化为TD-ARCHITECTURE: APPROVE这类带门禁 ID 的令牌且理性依据必须落到具体系统边界、接口定义或算法复杂度上而非泛泛而谈。主程 lead-programmer.md 负责 LP-FEASIBILITY 门禁模型层级为 Sonnet其可行性裁决词汇限定为FEASIBLE / CONCERNS / INFEASIBLE输出须格式化为LP-FEASIBILITY: INFEASIBLE这类令牌并引用具体复杂度量级、实体数量阈值或帧预算数字。也就是说/create-architecture唤起的虽然名义上是「两道门禁」但它们是两个不同层级的代理各自用各自词汇表给出结构化判定最终由技能汇总为 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED 三档文档级裁决。四、五大测试用例完整行为边界规格用五个测试用例刻画了该技能的完整行为边界每个用例都包含固定的项目状态Fixture、期望行为Expected behavior与断言Assertions。下面逐一展开。Case 1Happy Path —— 全新文档、骨架优先、full 模式双门禁通过Fixturedocs/architecture/architecture.md不存在全新项目docs/architecture/目录下已有若干Accepted已接受ADR可供参考production/session-state/review-mode.txt内容为full期望行为技能先创建带全部必需小节标题的骨架文件docs/architecture/architecture.md对每一节草拟内容 → 展示草稿 → 询问May I write [section]?→ 获得批准后写入全部章节草拟完成后TD-ARCHITECTURE 与 LP-FEASIBILITY并行唤起两道门禁均返回 APPROVED最后询问May I confirm architecture is complete?确认架构文档完成更新会话状态。关键断言骨架文件在任何内容写入之前就已包含全部小节标题创作期间每节都询问May I write [section]?两道门禁并行而非串行两道门禁都在最终完成确认之前结束双 APPROVED 时文档级裁决为 APPROVED结尾包含指向/architecture-review或/create-control-manifest的交接。规格在 Coverage Notes 中指出架构文档中的引擎版本戳记与 ADR 戳记平行的机制属于创作工作流的一部分通过 Case 1 隐式覆盖。Case 2Failure Path —— TD-ARCHITECTURE 返回 MAJOR REVISIONFixture架构文档所有章节已完成草拟review-mode.txt为fullTD-ARCHITECTURE 返回MAJOR REVISION并附具体结构性问题的描述期望行为所有章节照常草拟并写入TD-ARCHITECTURE 门禁运行并返回带具体反馈的 MAJOR REVISION技能将反馈原样呈现给用户架构文档不被标记为 finalized最终定稿用户被询问是修订被点名的章节还是接受当前文档作为草稿状态。关键断言TD 返回 MAJOR REVISION 时文档绝不被自动定稿门禁反馈必须带具体问题描述展示给用户用户拥有「修订指定章节」的选择权技能在 MAJOR REVISION 反馈下不会自动定稿。这一用例刻画了最重要的安全阀无论文档结构多完整门禁的负面裁定都会把「定稿权」交还给人而不是让技能绕过反馈自行推进。这呼应了 quality-rubric.md 中对 authoring 类别「不可在未获批准时自动写文件」的要求。Case 3Lean Mode —— 双门禁跳过仅凭用户批准成稿Fixture无既有架构文档review-mode.txt为lean期望行为创建骨架文件所有章节逐节创作、逐节经用户批准写入完成后TD-ARCHITECTURE 与 LP-FEASIBILITY 均被跳过输出中出现两条跳过注释TD-ARCHITECTURE skipped — lean mode与LP-FEASIBILITY skipped — lean mode仅凭用户批准即视为架构文档完成。关键断言两条门禁跳过注释都出现在输出中lean 模式下文档仅凭用户批准即可写成技能不会因为门禁被跳过而阻塞完成流程结尾交接仍然存在。该用例证明门禁是可配置的流程环节而非硬性阻塞点——review-mode.txt中的模式值直接决定门禁是否参与而「跳过」本身必须显式留痕便于审计。Case 4Retrofit Mode —— 既有文档用户仅更新某一节Fixturedocs/architecture/architecture.md已存在且所有章节均已填充期望行为技能检测到既有架构文档并读取当前内容技能提供 retrofit 入口Architecture doc already exists. Which section would you like to update?架构文档已存在您想更新哪个章节用户选择某一节技能只创作该节同样询问May I write [section]?仅被选中的章节被更新其余章节保持不变。关键断言提供 retrofit 前必须先检测并读取既有文档询问用户更新哪一节而不是要求重写整份文档仅更新被选中的章节一次 retrofit 会话中其他章节不被改动。规格在 Coverage Notes 中补充一次会话内对多个章节进行 retrofit 遵循同样的逐节批准模式但本规格不单独为多节 retrofit 设计独立测试。Case 5Director Gate —— 架构引用 Proposed 状态的 ADR标记为风险Fixture架构文档正在创作中某一节引用或依赖一条Status: Proposed的 ADRreview-mode.txt为full期望行为技能照常创作所有章节创作过程中检测到对 Proposed ADR 的引用技能标记Note: [section] references ADR-NNN which is Proposed — this is a risk until the ADR is accepted注意[章节] 引用了仍处于 Proposed 状态的 ADR-NNN——在该 ADR 被接受之前这是一个风险风险标记被嵌入对应章节的内容TD-ARCHITECTURE 与 LP-FEASIBILITY仍然运行并被知会该 Proposed ADR 风险。关键断言章节创作期间能检测并标记 Proposed ADR 引用风险注释嵌入架构文档对应章节两道门禁仍会唤起风险不阻塞门禁风险标记必须点名具体的 ADR 编号与标题。这一用例揭示了 CCGS 对「半成品依赖」的显式管理哲学风险要被点名、被记录、被传递但不阻止流程推进。门禁在知情的前提下自行判断该风险是否可接受而不是由创作技能替决策者静默放行。五、协议合规清单与覆盖边界规格以一份 Protocol Compliance 清单收束技能必须满足的整体行为骨架文件在任何内容写入前已创建且含全部小节标题每节创作时询问May I write [section]?full 模式下 TD-ARCHITECTURE 与 LP-FEASIBILITY 并行唤起lean/solo 模式下被跳过的门禁按名称与模式在输出中留痕对 Proposed ADR 的引用在文档中标记为风险结尾以/architecture-review或/create-control-manifest交接。同时Coverage Notes 明确划定了本规格的验证边界这本身就是很有价值的设计信息小节清单不在此处架构文档的必需小节清单定义在技能正文与/architecture-review技能中这里不重复枚举避免双份维护引擎版本戳记与 ADR 戳记平行的引擎版本戳记是创作工作流的一部分通过 Case 1 隐式测试多节 retrofit沿用逐节批准模式但不单独测试。从测试框架 CLAUDE.md 的说明可知规格文件描述的是技能的当前行为而非理想行为是阅读技能正文后反向书写的因此可能编码了既有缺陷——当技能在实践中表现异常时应当先修正技能再更新规格以匹配修正后的行为。把规格失败视为「需要调查」而不是「技能一定有错」。六、管线中的位置从架构文档到控制清单/create-architecture不是孤立工具它是 CCGS 技术管线的第一个环节。根据 WORKFLOW-GUIDE.md 的 Phase 3 Pipeline/create-architecture -- /architecture-decision (x N) -- /architecture-review | | | v v v Master architecture Per-decision ADRs Validates completeness, document covering in docs/architecture/ dependency ordering, all systems adr-*.md engine compatibility | v /create-control-manifest | v Flat programmer rules docs/architecture/ control-manifest.md步骤 3.1本技能产出覆盖系统边界、数据流与集成点的总架构文档docs/architecture/architecture.md步骤 3.2对每个重大技术决策调用/architecture-decision产出docs/architecture/adr-*.md决策记录后续/architecture-review校验完整性、依赖顺序与引擎兼容性最终由/create-control-manifest生成程序员可直接执行的扁平规则清单。作为承接者architecture-review.md 的规格与本技能严格对称它检查架构文档的 8 个必需小节、与既有 ADR 的一致性、引擎版本钉定同样在 full 模式并行唤起 TD-ARCHITECTURE 与 LP-FEASIBILITY并且是只读技能不写任何文件其裁决词汇同样限定为 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED——其中 ≥2 个小节缺失判 MAJOR REVISION NEEDED单一 ADR 冲突判 NEEDS REVISION。有趣的是/architecture-review的文件未找到用例Case 4还会主动建议「检查docs/architecture/或运行/create-architecture」两个技能形成互救闭环。管线末端还有一条稳定的数据契约tr-registry.yaml 技术需求 ID 注册表由/architecture-review追加写入、被/create-stories嵌入 story、/story-done评审时查最新需求文本与/story-readiness校验 TR-ID 存在且 active读取ID 格式为TR-[system-slug]-[NNN]且永久编号、只增不删。这意味着本技能产出的架构文档质量会顺着管线传导到需求追踪与验收环节——这正是导演门禁存在的意义。七、如何用测试框架验证 /create-architecture本技能所在目录是整个 CCGS 的质量保障层。根据 README.md 与 CLAUDE.md验证流程如下读目录先读catalog.yaml拿到技能的spec:路径即本文主题文件与category:authoring读技能正文阅读技能的实际定义理解行为读规格阅读 spec 文件即本文分析的文档逐用例评估按五种测试用例逐一核对断言写结果把结果写入results/并更新catalog.yaml的last_spec/last_spec_result字段。可用的测试命令/skill-test static create-architecture # 仅结构断言7 项检查无需夹具 /skill-test spec create-architecture # 按行为规格逐用例评估 /skill-test category create-architecture # 按 authoring 类别度量评估 /skill-test audit # 全量覆盖率has-spec / last tested / result /skill-improve create-architecture # 测试 → 诊断 → 修复 → 重测 → 保留或回退其中/skill-test category会依据 quality-rubric.md 的 authoring 段执行A1逐节循环轻量技能允许单稿、A2逐节 May-I-write轻量技能允许整体一次、A5骨架优先轻量技能豁免——create-architecture被明确列入轻量技能名单因此在评估时应套用单稿模式的宽松标准。需要注意的是规格中的五种测试用例多数需要具体项目状态如review-mode.txt内容、既有 ADR 状态属于行为级验证依赖真实或模拟的项目夹具而第二节的静态断言则由/skill-test static自动完成无需夹具。八、小结一条可验证、可追溯、人机协同的架构创作链路回顾整个规格/create-architecture的设计价值可以浓缩为三点过程可见骨架优先 逐节May I write [section]?使每一步创作都处于用户监督之下会话中断可恢复进度不丢失质量有闸full 模式下 TD-ARCHITECTUREOpus 层与 LP-FEASIBILITYSonnet 层并行把关用各自规范的裁决词汇输出结构化判定lean/solo 模式则显式跳过并留痕保证审计可追溯风险显式对 Proposed ADR 的依赖会被点名嵌入文档风险信息随门禁传递而不被静默吞没。它向下衔接/architecture-decision、/architecture-review与/create-control-manifest最终落为程序员可直接执行的扁平规则并由tr-registry.yaml把需求 ID 稳定地注入故事与验收流程。对于希望把 Claude Code 用于真实游戏研发管线的团队这份规格既是行为契约也是一份可复用的「架构文档创作与验收」参考实现。延伸阅读本技能行为规格 create-architecture.md承接审查技能 architecture-review.md门禁代理 technical-director.md 与 lead-programmer.md类别度量 quality-rubric.md管线上下文 WORKFLOW-GUIDE.md需求 ID 注册表 tr-registry.yaml【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考