--- name: godot-grill description: Use when a new Godot system or feature has open design decisions — interrogates them in batched rounds, scope first, each question with a recommended answer, and records the answers before any design or code. Triggers on "grill me", "ask me first", "question me on the design", "what do I need to decide before building". Not for choosing between nodes or APIs, and not for bug fixes. --- # Godot Grill Settle the decisions only the developer can make, before anyone designs a scene tree or writes code. The output is a **decision record**, not a design. > **Related skills:** **godot-brainstorming** for the scene tree, signal map, and plan once decisions are settled, **scene-organization** for composition vs. inheritance trade-offs, **godot-mentor** for teaching-mode delivery of what follows. ## 1. Decisions, not facts Ask only what **only the user knows**: intent, constraints, priorities, taste. Node types, API signatures, and version differences are **facts**. Look them up (`godot-brainstorming/references/node-selection.md`, the domain skills), decide, and record the choice. Never spend a question on one. Architecture choices — data home, state representation, save format — are decided **from** the user's answers, not asked as technology picks. Ask the constraint behind them ("will designers edit items in the Inspector?"), then map the answer to Resource `.tres` yourself. | Question | Verdict | |---|---| | "Throwaway prototype, or a system other code builds on?" | Decision — ask | | "Should the player be a `CharacterBody2D` or a `RigidBody2D`?" | Fact — decide, record it | | "When two clients disagree, who is right?" | Decision — ask | | "Can a `Tween` chain steps in 4.3?" | Fact — never ask | ## 2. The seeded dependency tree Four roots have no prerequisites: | Root | Options | |---|---| | **Scope** | throwaway slice / one feature / a system others build on | | **Dimension** | 2D / 3D / 2.5D | | **Language** | GDScript / C# / both | | **Authority** | single-player / networked (and if networked, who is authoritative) | | Settling this… | …unblocks | |---|---| | Scope | prunes branches: a throwaway slice skips persistence, data home, networking, and testing | | Authority | state ownership (source of truth); signals vs. RPCs | | Dimension | physics model; camera model | | Language | interop boundary, when the answer is "both" | | Scope + Dimension | entity model: composition vs. inheritance | | Entity model | data home (Resource `.tres` / autoload / node-local `@export`); communication (signals up, calls down / EventBus / DI) | | Authority + Entity model | state representation (enum FSM / node FSM / AnimationTree / none); persistence boundary | | Data home + Persistence | save format (ConfigFile / JSON / Resource serialization) | The right-hand column names what an answer lets **you** decide; ask the user the constraint behind it, never the technology. The tree is a **seed, not a script**. Answers grow it — "networked" creates branches a single-player answer never does. Skip any root the request or the project already answers (`project.godot`, existing scripts). Most sessions visit few nodes. ## 3. Rounds **Before round 1**, read where the project keeps decision records, checking in order: the user's instructions or the project's agent instructions file (`CLAUDE.md`, `AGENTS.md`, …); then an existing decisions or ADR directory. A recorded decision is a settled prerequisite: never re-ask it; start the frontier past it. The **frontier** is every open decision whose prerequisites are settled. Ask the whole frontier in one message, numbered, each with a recommended answer: ```text ❓ **Q1** — **