Tiered gamedev workflow
Skill sonic7881963/gamedev-skills/skills/tiered-gamedev-workflow
Use when starting any game-dev feature with an AI agent and deciding how much process to apply — full spec/plan ceremony is slowing iteration, a feature feels too small for documents, or a lightweight change just broke something the old process would have caughtFrom its SKILL.md
npx -y skills add sonic7881963/gamedev-skills --skill tiered-gamedev-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.3 KB, as published. Nobody here has run it
分级游戏开发工作流（S/M/L 判级）
核心原则
流程的重量要匹配改动的风险，且流程本身可迭代：轻量化砍掉的只能是"文档仪式"， 永远不能是安全网（TDD、设计确认、全量验证、调试纪律）。
子代理团队运营（派发/档位/成本/审查经济）见 running-subagent-teams；工作流 规则演进（复盘/三检/控胀/根基防护）见 evolving-workflow-rules。
特性分级
| 级别 | 适用 | 流程 |
|---|---|---|
| S | 数据调整 / 单文件小改 | 三五行设计向用户确认 → 直接 TDD → 提交；规格写进 commit message |
| M | 单系统特性 | 一份短规格（决策+文件清单+测试清单+一行非目标）→ TDD → 提交；不写全码实施计划 |
| L | 跨系统改造 | 完整流程：superpowers:brainstorming → 规格 → superpowers:writing-plans → superpowers:executing-plans |
拿不准 → 默认 M（短规格是最便宜的保险）。决策集中一轮问完（问前先亮 一行"假设+置信度%+缺什么"），设计确认后自主跑完。 需求访谈模式（蒸馏自 addyosmani/agent-skills 的 interview-me，吸收机制 不装本体）：需求缺 who/why/success/constraint 任一项 → 弃集中问改逐问—— 一次一题、每题附猜测（错猜最钓真意）；用户飙"可扩展/干净架构"类正确术语 时追问"不用向任何人交代的话你实际想要什么"；能预测用户对下三问的回答即 收口重述（含非目标行）。设计确认只认显式 yes："你看着办"=委派、 "行吧"=礼貌退出，都要追问。仅限交互场景。引入第三方流程的原则：先查重 （与既有机制冲突/重复则分流或拒绝），蒸馏增量入权威文件而非安装本体 ——插件清单注入每个会话与子代理，且上游更新会静默改流程。
人工验收场景：M/L 特性规格含一项受控前置的验收场景（指定初始状态供人工 审核，不挤默认主场景）——随系统演进维护、属维护资产（瘦身审计脚手架问对其 豁免）。底线不变：主场景真实启动 + stderr 空仍是验收底线，验收场景是其上叠加。
UI 特性纪律：
- UI 节点只显示+发信号，永不持有/修改游戏状态（状态唯一归属游戏侧组件）
- M 级及以上 UI 特性规格必须含界面流+信号清单
- UI 改动审查加查三点：状态归属、硬编码文案、输入覆盖（键鼠为底线；新增裸键码须对照既有键位占用——InputMap 查重不够，硬编码键码也会撞）
升级判定（任一命中即升级）
- S→M：≥2 个需用户拍板的决策；无同类先例的新机制；预计动 >3 个文件； 会改变既有测试的前提（平衡/时序）。
- M→L：跨系统改语义（改变既有系统间的契约，例如重定义"冷却"）；需重写 ≥2 个 既有测试；动所有人依赖的公共地基（战斗状态机、编队指挥）；接口波及 ≥3 个调用方。
- 任何级→先停下问用户：要碰用户未提交的工作；不可逆/对外操作；疑似需求理解偏差。
永不轻量的底线（所有级别）
- TDD 红→绿（superpowers:test-driven-development）
- 开工前一轮设计确认——"简单"改动最容易藏物理/数学陷阱（实例：射程翻倍这种 两行数据改动，靠开工前 10 分钟分析才发现抛物线极限射程根本够不到新数值）
- 提交前全量测试 ×1（并行跑，见 godot-headless-testing）
- 特性交付验收含一次真实启动 + stderr 捕获为空——测试全绿 ≠ 全图干净： 测试只编译自己的依赖链（实例：大迁移期间未迁脚本的类型冲突沿 class_name 全局类型图级联毒化，活动链上的相机脚本加载失败、游戏黑屏，测试全绿两次 没拦住，用户试玩才发现）。且"真实启动"须走主可玩场景的真实入口（真实 spawn/命令/配置）——verify/probe 脚手架不算实装（实例：编队坚守机制各切片只在 verify 沙盒/probe 验过，单位被直接摆在目标槽点上、用测试硬编的几何参数，主可玩 场景从没走真实 spawn 验过 → 报"实装"但游戏里从没生效、还沿用了旧默认参数）
- 意外失败必走 superpowers:systematic-debugging（探针定位，禁止猜改）
中途升级
判级是假设，证据可推翻。S 级执行中出现以下信号 → 停手补短规格升 M： 红测暴露更深耦合 / 实际文件数超预估 / 任何既有测试意外翻红。
红线自检
| 念头 | 现实 |
|---|---|
| "这次特殊，跳过设计确认直接写" | 简单改动藏陷阱的概率不比大改低 |
| "测试回头补" | 红→绿的顺序就是规格本身，补测只是证明"它是这样"而非"它该这样" |
| "判错级了但快做完了，硬撑完吧" | 中途升级只花 5 分钟，返工花几小时 |
| "这条规则碍事，悄悄不遵守" | 走复盘回路提议删除——规则要么生效要么正式废除 |