ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Quick Design Spec: [Title]

Quick Design Spec: [Title] Quick Design Spec: [Title]【免费下载链接】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-StudiosType: TuningSystem: [System name]GDD Reference:design/gdd/[filename].md— Tuning Knobs sectionDate: [today]ChangeParameterOld ValueNew ValueRationale[param][old][new][why]Tuning Knob MappingMaps to GDD Tuning Knob: [knob name and its documented range]. New value is [within / at the edge of / outside] the documented range. [If outside: explain why the range should be extended.]Acceptance Criteria[Parameter] reads [new value] fromassets/data/[file]Behavior difference is observable in [specific context]No regression in [related behavior]**要点解析** - **Tuning Knob Mapping 一节要求显式对照 GDD 中已记录的调参旋钮及其文档化范围**并声明新值位于范围内/边界/范围外。若在范围外必须解释为何要扩展该范围——这是防止悄悄越界调参的硬约束 - 验收标准强调参数**必须从 assets/data/ 读取**而不是硬编码在代码里。这与 design-system 中 Tuning Knobs 章节所有值必须存在于 assets/data/[appropriate-file].json的规定完全一致是整个 CCGS 设计体系对数据驱动的一致要求。 ### 4.2 Tweak 与 Addition 类变更声明规格 这两类改动引入了行为或机制变化需要比 Tuning 更完整的声明 markdown # Quick Design Spec: [Title] **Type**: [Tweak / Addition] **System**: [System name] **GDD Reference**: design/gdd/[filename].md **Date**: [today] ## Change Summary [1-2 sentences describing what changes and why.] ## Motivation [Why is this change needed? What player experience problem does it solve? Reference the relevant MDA aesthetic or player feedback if applicable.] ## Design Delta Current GDD says (quoting design/gdd/[filename].md, [section]): [exact quote of the relevant rule or description] This spec changes that to: [New rule or description, written with the same precision as a GDD Detailed Rules section. A programmer should be able to implement from this text alone.] ## New Rules / Values [Full unambiguous statement of the replacement content. If this introduces new states, list them. If it introduces new parameters, define their ranges.] ## Affected Systems | System | Impact | Action Required | |--------|--------|-----------------| | [system] | [how it is affected] | [update GDD / update data file / no action] | ## Acceptance Criteria - [ ] [Specific, testable criterion 1] - [ ] [Specific, testable criterion 2] - [ ] [Specific, testable criterion 3] - [ ] No regression: [the original behavior this must not break] ## GDD Update Required? [Yes / No] [If yes: which file, which section, and what the update should say.]要点解析Design Delta设计增量是本节灵魂必须先精确引用GDD 中相关规则的原句再写明新规则新规则必须精确到程序员只看这段文字就能实现与design-system对 Detailed Design 章节无需提问即可实现的标准同源Motivation鼓励引用 MDA 美学或玩家反馈把改动与玩家体验目标绑定Affected Systems 表显式标注每个受影响系统需要的后续动作改 GDD / 改数据文件 / 无需动作GDD Update Required?显式声明是否需要回写 GDD——这一步为后续单独征得批准后更新 GDD的流程做铺垫。4.3 New Small System 类精简 GDD 结构对独立的小系统使用裁剪版 GDD 结构——只保留直接必要的章节除非系统特别需要否则跳过 Player Fantasy、完整 Formulas 和 Edge Cases# Quick Design Spec: [Title] **Type**: New Small System **Scope**: [1-2 sentence description of what this system does and doesnt do] **Date**: [today] **Estimated Implementation**: [hours] ## Overview [One paragraph a new team member could understand. What does this system do, when does it activate, and what does it produce?] ## Core Rules [Unambiguous rules for the system. Use numbered lists for sequential behavior and bullet lists for conditions. Be precise enough that a programmer can implement without asking questions.] ## Tuning Knobs | Knob | Default | Range | Category | Rationale | |------|---------|-------|----------|-----------| | [name] | [value] | [min–max] | [feel/curve/gate] | [why this default] | All values must live in assets/data/[appropriate-file].json, not hardcoded. ## Acceptance Criteria - [ ] [Functional criterion: does the right thing] - [ ] [Functional criterion: handles the edge case] - [ ] [Experiential criterion: feels right — what a playtest validates] - [ ] [Regression criterion: does not break adjacent system] ## Systems Index This system is not currently in design/gdd/systems-index.md. [If it should be added: suggest which layer and priority tier.] [If it is too small to track: state This system is below systems-index tracking threshold — quick spec is sufficient.]要点解析Overview要求新成员一看就懂回答系统做什么、何时激活、产出什么三个问题Core Rules强调编号列表表达顺序行为、项目符号表达条件精确到程序员无需提问Tuning Knobs 表的Category列取feel/curve/gate之一手感/曲线/门槛并再次强调数值必须落在assets/data/的 JSON 文件中Acceptance Criteria覆盖功能、边界、体验由 playtest 验证、回归四类标准Systems Index一节要求明确决策该系统是否够格进入design/gdd/systems-index.md跟踪。低于跟踪阈值时明确声明quick spec 已足够。5. 第五步批准与归档Approval and Filing规格草稿完成后完整呈现给用户然后按此句式征得写档许可May I write this Quick Design Spec todesign/quick-specs/[kebab-case-title]-[YYYY-MM-DD].md?5.1 文件命名规范文件名使用今天日期标题为改动的kebab-case 描述例如jump-height-tuning-2026-03-10parry-window-addition-2026-03-10若design/quick-specs/目录不存在先创建再写文件。5.2 GDD 更新的独立批准如果规格中标记了需要更新 GDD即 GDD Update Required 为 Yes在写完 quick spec 后单独询问This spec modifies rules in [System Name]. May I updatedesign/gdd/[filename].md— specifically the [section name] section?必须先展示将要变更的确切文本旧 vs 新再征求同意。未经明确批准不得修改 GDD。这一先展示 diff、再请求写入的协议与design-system中绝不静默改写已批准 GDD的协作原则完全一致。6. 交接输出与流水线语义Handoff Pipeline Notes6.1 标准交接块文件写完后输出以下交接信息Quick Design Spec written to: design/quick-specs/[filename].md Type: [Tuning / Tweak / Addition / New Small System] System: [system name] GDD update: [Required — pending approval / Applied / Not required] Next step: This spec is ready for /story-readiness validation before implementation. Reference this spec in the storys GDD Reference field.技能自带结论文本为Verdict: COMPLETE—— quick design spec 已写好并可供实现。6.2 为什么它绕过完整评审管线Quick Design Spec 设计上就绕过/design-review和/review-all-gdds因为它们是针对小改动、低风险、边界清晰场景的通道——完整评审管线的成本超过了改动本身的风险。这正是gate-check技能.claude/skills/gate-check/SKILL.md中Small design change needed? →/quick-designfor changes under ~4 hours (bypasses full GDD pipeline)这一路由规则的来源。6.3 何时重定向回完整管线出现以下任一情况时必须重定向改动新增了一个**应进入系统索引systems index**的新系统改动显著改变跨系统行为或系统与其他系统的契约改动引入影响游戏MDA 美学平衡的新玩家面向机制实现很可能超过一周的工作量。此时按固定话术告知用户This change has grown beyond quick-spec scope. I recommend using/design-systemto author a full GDD for this.值得注意的是即使走轻量通道产出物仍会进入评审体系director-gates.md.claude/docs/director-gates.md中的CD-GDD-ALIGN门禁就声明其触发条件为 After a system GDD is authored (design-system, quick-design, or any workflow that produces a GDD)——轻量只是降低文档成本不意味着完全脱离质量网。7. 与 Story 管线的集成从规格到实现quick spec 的最终归宿是 story 文件其交接链路在仓库中可被完整追踪/story-readiness校验.claude/skills/story-readiness/SKILL.mdstory 在实现前必须通过 READY / NEEDS WORK / BLOCKED 判定。其重定向规则明确写道当 story 缺少 GDD 引用且工作量较小时——If the change is small (under ~4 hours), run/quick-design [description]to create a Quick Design Spec, then reference that spec in the story. 也就是说quick spec 可以反向补位发现 story 缺设计依据时用/quick-design快速补齐GDD Reference 字段story 文件的 GDD Reference 字段引用 quick spec 路径满足 readiness 检查中GDD requirement referenced引用了design/gdd/路径下的具体需求而非仅文件名的要求/dev-story实现.claude/skills/dev-story/SKILL.mdstory 通过 readiness 校验后/dev-story读取完整上下文story、GDD 需求、ADR 指引、control manifest路由到对应程序员 Agent 实现。其主循环为/qa-plan sprint ← 定义测试需求 /story-readiness [path] ← 实现前校验 /dev-story [path] ← 实现本技能 /code-review [files] ← 评审 /story-done [path] ← 验证并关闭【免费下载链接】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),仅供参考
返回列表