godot-grill

Godot Grill

在设计任何场景树或编写代码之前，先敲定只有开发者才能做出的决定。输出应为决策记录，而非设计方案。

**相关技能：**敲定决定后，使用 godot-brainstorming 规划场景树、信号映射和实施方案；使用 scene-organization 权衡组合与继承；使用 godot-mentor 以教学模式讲解后续内容。

1. 问决定，不问事实

只问只有用户才知道的内容：意图、约束、优先级、偏好。

节点类型、API 签名和版本差异都是事实。查阅相关资料 （godot-brainstorming/references/node-selection.md、领域技能），自行决定并记录选择。绝不要为此提问。

架构选择——数据存放位置、状态表示、存档格式——应根据用户的回答来决定，而不是把技术选型丢给用户。询问背后的约束（“设计师会在 Inspector 中编辑项目吗？”），然后自行将答案映射到 Resource .tres。

问题	判断
“这是一次性原型，还是其他代码会在其基础上构建的系统？”	决定——提问
“玩家应该是 CharacterBody2D 还是 RigidBody2D？”	事实——自行决定并记录
“两个客户端意见不一致时，以谁为准？”	决定——提问
“在 4.3 中，Tween 能否串联步骤？”	事实——绝不提问

2. 种子依赖树

四个根节点没有前置条件：

根节点	选项
范围	一次性切片 / 单项功能 / 供其他代码构建其上的系统
维度	2D / 3D / 2.5D
语言	GDScript / C# / 两者
权威模式	单人游戏 / 网络游戏（若为网络游戏，需确定谁拥有权威）

敲定此项……	……即可决定
范围	剪枝：一次性切片可跳过持久化、数据存放位置、网络和测试
权威模式	状态归属（真实数据源）；信号还是 RPC
维度	物理模型；摄像机模型
语言	答案为“两者”时的互操作边界
范围 + 维度	实体模型：组合还是继承
实体模型	数据存放位置（Resource .tres / autoload / 节点本地 @export）；通信方式（信号向上、调用向下 / EventBus / DI）
权威模式 + 实体模型	状态表示（enum FSM / 节点 FSM / AnimationTree / 无）；持久化边界
数据存放位置 + 持久化	存档格式（ConfigFile / JSON / Resource 序列化）

右侧列出的是回答能让你自行决定的事项；询问用户背后的约束，而不是技术选型。这棵树是种子，不是脚本。回答会让它生长——“网络游戏”会带出单人游戏答案不会触发的分支。若请求或项目已有答案（project.godot、现有脚本），就跳过相应根节点。多数对话只会涉及少数节点。

3. 轮次

第 1 轮之前，先查明项目将决策记录存放在哪里，并按以下顺序检查：用户指示或项目的 Agent 指示文件（CLAUDE.md、AGENTS.md 等）；然后检查现有的决策或 ADR 目录。已记录的决定属于已敲定的前置条件：绝不再次提问；从其之后的待决范围开始。

待决范围是指所有前置条件均已敲定的未决事项。在一条消息中一次询问整个待决范围，使用编号，并为每项提供推荐答案：

❓ **Q1** — **<title>**: <the question, with its options>

➡️ <recommended answer, and why in one clause>

然后停止并等待。前置条件尚未敲定的问题应留到后续轮次。所有问题都必须放在编号列表中：列表之后不要再补一句“还有，你想做什么类型的游戏……？”值得问的问题都要编号并加上 ➡️；其他内容留到下一轮。

第 1 轮要精简，并优先敲定范围——范围能剪掉最多分支。“一次性切片”的回答通常会让对话在第 2 轮结束。

每轮结束后，根据回答重新推导待决范围。如果某个回答与已记录的决定相矛盾，要指出矛盾并询问是否重新审议；绝不要悄悄覆盖记录。

4. 结束 grill

当待决问题清单为空时，或用户选择退出选项时，grill 即结束。退出选项包括在任意轮次（包括第一条消息）中说「直接构建」「跳过问题」或「停止 grill」。此时停止提问，并列出你现在对所有未决事项所作的每一项假设，方便用户快速浏览并推翻。

**选择退出选项后，不设确认或审批关卡：**列出假设、撰写记录并开始构建——使用匹配的领域技能，或使用步骤 2 中的 godot-brainstorming，但不进行逐节确认。

待决问题清单为空时，撰写记录（§5），在一条消息中确认双方理解一致，然后等待。之后移交：

• 需要场景树、信号映射或计划 → 使用步骤 2 中的 godot-brainstorming
• 属于单个已明确的更改 → 使用匹配的领域技能

5. 决策记录

GodotPrompter 没有自己的决策目录。请将记录写入项目存放决策记录的位置，并按以下顺序检查：用户指示或项目的 Agent 指示文件（CLAUDE.md、AGENTS.md 等）；然后是现有的决策目录或 ADR 目录。如果都不适用，请询问用户，并建议使用 docs/decisions/；若无法询问（例如子 Agent 或非交互运行），则使用 docs/decisions/。文件名采用 YYYY-MM-DD-<topic>.md。路径必须保持稳定：下一次 grill 会读取该记录。

# <Topic> — decisions

| Decision | Choice | Why | Revisit when |
|---|---|---|---|
| Bag model | Fixed 20 slots | Grid UI already designed | a weight system is wanted |
| Item data | Resource `.tres` | Inspector editing, typed exports | items exceed ~200 |

## Open / deferred
- Equipment stat aggregation — deferred to a later pass.
- Save slots — **assumed** 1 (off-ramp); revisit before shipping.

Revisit when 用于让决策之后可以重新讨论，而不是将其定为不可更改。退出选项下的假设应放在 Open / deferred 下，并标记为 assumed。如果无法写入文件，请在最终消息中提供记录。

6. 反模式

反模式	错误原因	应采取的做法
每次只问一个问题	提问顺序预先固定；问题会早于其前置条件出现；增加轮次	询问整批待决问题
询问事实	浪费用户注意力，让模型代劳即可	查明事实、作出决定并记录
提问时不提供建议	用户只能在没有背景的情况下作答；轮次推进缓慢	每个问题都附上 ➡️ 建议答案
在编号列表之外追加问题	问题没有建议答案，用户按编号回答时容易漏掉	编号，或留到下一轮
对 Bug 修复或明确请求进行盘问	这正是此技能必须避免的过度纠正	转交给领域技能
重新询问已记录的决定	让人觉得模型失忆；浪费记录	先查看项目存放决策记录的位置
得到最后一个回答后立即编写代码	跳过双方理解一致的检查	先确认，再移交

检查清单

• 第 1 轮前阅读现有决策记录
• 第 1 轮优先明确范围
• 每个问题都是一项决策——有编号，并附上建议答案
• 每轮询问整批待决问题；每轮结束后等待
• 用户选择退出选项 → 列出假设
• 已撰写记录（或无法写入文件时，将记录放在最终消息中）
• 待决问题清单为空 → 在设计或编写代码前获得用户确认；选择退出选项 → 不设关卡，依据所列假设开始构建