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:
❓ **Q1** — **<title>**: <the question, with its options>
➡️ <recommended answer, and why in one clause>
Then stop and wait. A question whose prerequisite is still open belongs to a later round. Everything you ask is in the numbered list: no closing "also, what genre…?" after it. Anything worth asking gets a number and a ➡️; anything else waits for the next round.
Round 1 is small and settles scope first — scope prunes the most tree. A "throwaway slice" answer commonly ends the session at round 2.
After each round, re-derive the frontier from the answers. If an answer contradicts a recorded decision, say so and ask whether to reopen it — never overwrite a record silently.
4. Ending the grill
The grill ends when the frontier is empty, or on the off-ramp: "just build it" / "skip the questions" / "stop grilling", in any round, including the first message. Then stop asking, and list every assumption you are now making for the open decisions, where the user can scan and overrule them.
On the off-ramp there are no confirmation or approval gates: list the assumptions, write the
record, and build — with the matching domain skill, or godot-brainstorming from Step 2 without
its per-section check-ins.
When the frontier empties, write the record (§5), confirm shared understanding in one message, and wait. Then hand off:
- it needs a scene tree, signal map, or plan →
godot-brainstorming, from Step 2 - it is a single known change → the matching domain skill
5. The decision record
GodotPrompter has no decisions folder of its own. Write the record where this project keeps
them, 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. If none applies, ask
the user, suggesting docs/decisions/, or use docs/decisions/ when you cannot ask (a subagent
or non-interactive run). Name the file YYYY-MM-DD-<topic>.md. The path must stay stable: the
next grill reads it back.
# <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 keeps a decision reopenable, not binding. Off-ramp assumptions go under
Open / deferred, marked assumed. If you cannot write files, put the record in your final
message instead.
6. Anti-patterns
| Anti-pattern | Why it is wrong | Instead |
|---|---|---|
| One question at a time | Order fixed in advance; questions arrive before their prerequisites; more turns | Ask the whole frontier |
| Asking a fact | Spends the user's attention on the model's job | Look it up, decide, record |
| A question with no recommendation | The user answers in a vacuum; rounds slow down | Every question gets ➡️ |
| A trailing question outside the numbered list | It has no recommendation and is easy to miss when answering by number | Number it, or hold it for the next round |
| Grilling a bug fix or an explicit ask | The over-correction this skill must not become | Route to the domain skill |
| Re-asking a recorded decision | Feels like amnesia; wastes the record | Read where the project keeps decision records first |
| Coding after the last answer | Skips the shared-understanding check | Confirm, then hand off |
Checklist
- Read existing decision records before round 1
- Round 1 settled scope first
- Every question is a decision — numbered, with a recommended answer
- Whole frontier per round; waited after each
- Off-ramp taken → assumptions listed
- Record written (or in the final message when files cannot be written)
- Frontier emptied → user confirmed before design or code; off-ramp → no gates, built on the listed assumptions