GodotMaker Build

GodotMaker Build

$ARGUMENTS

You are implementing a Godot game by dispatching Worker subagents. Risk tasks first, then main tasks — both surfaced from PLAN.md, which is scoped to the current tag (read the **Tag:** header at the top of PLAN.md). You do NOT build the whole game in one go; later tags will add features on top of this one.

Session Setup

FIRST ACTION — before anything else: Write build to .godotmaker/current_role.

Resume Check

Read .godotmaker/stage.jsonl (treat as empty if missing) — each line is {"role": X, "ts": Y}.

• If project.godot does not exist → STOP. Tell user to run /gm-scaffold first.
• If ROADMAP.md does not exist → STOP. Tell user to run /gm-gdd first.
• If no event with role == "gdd" exists anywhere in the file → STOP. Tell user to run /gm-gdd first.
• If PLAN.md is missing the **Tag:** header → STOP. Tell user the file is stale and to re-run /gm-gdd to regenerate it for the current tag.

Read .godotmaker/verify_report.json if it exists.

Define pending verify feedback as:

• .godotmaker/verify_report.json exists.
• Its top-level result is "fail".
• Its ts is later than the latest role == "build" event in stage.jsonl, or there is no prior build event.

Apply the resume gates in this order:

• If pending verify feedback exists → proceed to Step 0, even if the last event is build and all PLAN.md tasks are already verified.
• If the last event has role == "build" AND all PLAN.md tasks are verified → STOP. Tell the user:

  "Build already completed for the current tag at {timestamp}. Recommended next: /gm-verify. If you need to redo this step or have other plans, just tell me."

• Otherwise → proceed (this includes resume from interrupted run AND new tasks added by reviewer).

Then read context:

• PLAN.md → current tag's **Tag:** header + Tag Mechanics + Inherited Mechanics + Playable Unit + pending/in_progress/completed tasks (anything not verified)
• STRUCTURE.md → architecture and build order (current tag scope: previous tags' systems already exist on disk and may be touched only when PLAN.md explicitly lists a refactor task for them)
• ASSETS.md → the generated-runtime authority; for a visual task, derive each asset with tools/asset_result_registration.py --snapshot
• MEMORY.md index + sub-files → stable architecture decisions and project constraints
• docs/tags/<prev_tag>/STRUCTURE.md (only if PLAN.md has Inherited Mechanics or refactor tasks touching prior systems) → know what already exists before adding/refactoring. Read docs/tags/<prev_tag>/SUMMARY.md first — it is one screen and often answers the question without opening the full archive; docs/tags/README.md lists every sealed tag if you are not sure which one to open.