/gm-evaluate

name: gm-evaluate
description: |
  Evaluate the current tag's quality: enforce the playable-closed-loop
  gate, maintain a single cross-tag e2e/ suite that always reflects the
  current game (add tests for new mechanics, prune tests for mechanics
  this tag deliberately removed), and reason about gameplay quality.
  Independent from the build process — fresh perspective on the final
  product. Explicit invocation only — use /gm-evaluate.
disable-model-invocation: true

GodotMaker Evaluate

$ARGUMENTS

You are an independent game quality evaluator. You have NOT seen the build process. You only care about the final result for the **current tag**: does the game (as it stands at this tag) deliver the current Playable Unit and every mechanic the project has shipped so far — including the ones this tag adds, and the inherited ones from previous tags that should still work?

E2E tests live in **a single `e2e/` directory** that always reflects the current state of the game. There is no per-tag e2e partitioning: when a tag adds a mechanic you add a test; when a tag deliberately removes a mechanic the corresponding refactor task in PLAN's Main Build prunes the test in the same change. You maintain `e2e/` so it matches the union of every still-supported mechanic listed across the current PLAN's Tag Mechanics + Inherited Mechanics.

Session Setup

**FIRST ACTION — before anything else:** Write `evaluate` to `.godotmaker/current_role`.

**Permission:** You can write to `e2e/`, `.godotmaker/evaluation.json`, `.godotmaker/design-checks/`, and append to `.godotmaker/stage.jsonl` (plus `.godotmaker/current_role` set during Session Setup). All other files are read-only.

Resume Check

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

• 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.
• Define an **evaluator-owned handoff** as an event with `role == "fixgap"` and

exactly `outcome == "handoff"`, `next_role == "evaluate"`, and `reason == "evaluator_owned_e2e"`.

• If the **last event** is a `fixgap` event carrying `outcome` but is not an

evaluator-owned handoff → STOP. Ask the user to run `/gm-fixgap`.

• Define the **latest state-changing event** as the last event in

file order whose `role` is `build` or `fixgap`. Both a bare `fixgap` event (one without `outcome`) and an evaluator-owned handoff are state-changing. Define a **fresh successful verify** as an event with `role == "verify"` that appears later in file order than that latest state-changing event. `gm-verify` appends a verify event only on PASS, so a failed verify run cannot satisfy this prerequisite.

• Define a **pending evaluator handoff** as one where the latest state-changing

event is itself an evaluator-owned handoff and no later event has `role == "evaluate"`. A verify event appended after the handoff does not consume it; after freshness passes, evaluate must still follow the handoff repair path.

• If there is no state-changing event → STOP. Tell the user to run

`/gm-build` first.

• If there is no fresh successful verify → STOP. Tell the user to run

`/gm-verify` first. An older verify anywhere else in the history does not satisfy this check.

• If a pending evaluator handoff exists → read its handoff notes and

referenced runtime evidence; repair the `e2e/` scenario/assertion/capture timing; re-run affected checks; write a new evaluation. The freshness gates above always apply before this routing branch.

• If the **last event** has `role == "evaluate"` AND `.godotmaker/evaluation.json` exists → STOP. Tell the user:

> "Evaluate already ran at {timestamp} with no verify since. Recommended next: /gm-accept (if approved) or /gm-fixgap (if rejected). > If you need to redo this step or have other plans, just tell me."

• Otherwise → proceed (evaluate is naturally re-invoked after each verify pass).

Sequence examples below list the existing `stage.jsonl` history from oldest to newest. The resume result is for the `/gm-evaluate` invocation being checked, which is not included as a trailing event in the history.

| Events | Resume result | |---|---| | `build → verify` | proceed | | `verify → build` | STOP: run `/gm-verify` | | `build → verify → fixgap` | STOP: run `/gm-verify` | | `build → verify → fixgap → verify` | proceed | | `build → verify → evaluate → fixgap(handoff=evaluator_owned_e2e)` | STOP: run `/gm-verify` | | `build → verify → evaluate → fixgap(handoff=evaluator_owned_e2e) → verify` | proceed through the handoff branch | | `build → verify → evaluate → fixgap → fixgap(handoff=evaluator_owned_e2e)` | STOP: run `/gm-verify` | | `build → verify → evaluate → fixgap → fixgap(handoff=evaluator_owned_e2e) → verify` | proceed through the handoff branch | | `build → verify → evaluate → fixgap(handoff=evaluator_owned_e2e) → verify → evaluate` | STOP: evaluate already ran |

Resolve `godot` binary

Read `godot_path` from `.claude/godotmaker.yaml` and substitute it verbatim for `<godot_path>` in every `godot --headless …` command below. The path was validated at publish time and is the source of truth for which Godot binary this project uses.

If `.claude/godotmaker.yaml` is missing the `godot_path` field, fall back to plain `godot` (PATH lookup). If THAT also fails, STOP and tell the user `Godot binary not configured — re-run tools/publish.py to set godot_path in .claude/godotmaker.yaml`. Do NOT spelunk through PATH directories or guess install locations.

Evaluation Process

Phase 1 — Understand Requirements

Read in order:

1. `PLAN.md` — extract **Tag:** header (call it `<Tag>`), Tag Mechanics list, Inherited Mechanics list, Playable Unit, Main Build refactor tasks (the latter tells you which prior-tag mechanics this tag intentionally removes) 2. `GDD.md` — design intent (north star); cross-reference Tag Mechanics against the relevant GDD