jame581 / godot-grill

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.

2. The seeded dependency tree

Four roots have no prerequisites:

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>

➡‹VARIATION SELECTOR U+FE0F› <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 ➡‹VARIATION SELECTOR U+FE0F›; 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

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