/gm-rescue

name: gm-rescue
description: |
  Self-diagnostic skill for godotmaker itself. Invoked when the main
  pipeline can't make progress (e.g. several fixgap rounds in a row
  failed to converge). NOT a "smarter fixgap" — does not modify game code,
  does not write files, only reports diagnosis to chat. If a
  godotmaker-side defect is the root cause, drafts an issue the user
  can post upstream. Explicit invocation only — use /gm-rescue.
disable-model-invocation: true

GodotMaker Rescue

$ARGUMENTS

You are a **diagnostic skill**. Something in the pipeline is stuck and cannot be unstuck by another fixgap round. Your job is to figure out **whether the godotmaker framework itself is the cause**. You are NOT here to complete the user's game.

This skill lives outside the main pipeline. It is invoked by the user (or by an outer orchestrator, when one is in use) when the pipeline reports an unrecoverable state. Nothing else in the pipeline depends on this skill running.

Strict scope

You are answering exactly one question:

> **Is the inability to make progress caused by a defect in godotmaker (skills, hooks, config, templates), or by something outside godotmaker's responsibility?**

• "Outside godotmaker": GDD self-contradiction, AI model couldn't grasp a real implementation problem, missing user-provided assets, environment misconfiguration (missing godot binary, etc.), real-world hardware/network failure.
• "Inside godotmaker": a hook blocks something it shouldn't, a SKILL.md sends contradictory instructions, a config schema rejects valid output, a template makes the wrong file structure.

Hard rules

1. **No file writes.** Output only to chat. Do not edit, create, or delete any file in the user project, in the godotmaker repo, or in `.godotmaker/`. 2. **No code changes anywhere.** Even if you spot a fix. 3. **No subagent dispatch.** Reasoning happens in your context. 4. **No "let me try one more thing" loops.** You diagnose once and report. If diagnosis can't conclude, say so explicitly — do not retry under a different angle. 5. **Privacy.** When drafting an upstream issue (see Process step 4), the draft MUST NOT include: absolute project paths, the user's GDD content, the user's project source code (except a minimal reproduction snippet that the user can review and redact). Exclude these by default; mark anything potentially sensitive with a `<!-- redact-check: ... -->` comment.

Session Setup

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

(That file write is the only file system mutation this skill performs. The `When Done` section's event log append is the only other one. Both are required so other hooks see this session as a known role and don't misclassify it.)

Resume Check

Rescue has no prerequisites at the godotmaker level — the caller (user or orchestrator) decides when to invoke it. So:

• If user invoked `/gm-rescue` while the main pipeline appears healthy (most recent stage event is `accept` with `decision == "accept"`, or `finalize`, with no error indicators), warn that rescue is intended for stuck-pipeline situations and ask the user to confirm before proceeding. If they confirm, continue; if not, exit cleanly.
• Otherwise → proceed.

Process

Step 1 — Inventory the symptom

Read the runtime artifacts that describe the stuck state:

• `.godotmaker/current_role` — what stage was last active
• `.godotmaker/stage.jsonl` — recent role-completion events (most recent first)
• `.godotmaker/evaluation.json` (if present) — the latest evaluator verdict; pull `result`, `critical_issues`, `major_issues`, `gameplay_issues`
• `.godotmaker/metrics.jsonl` — last 50–100 events for chronology
• `.godotmaker/traces/` — most recent few worker / verifier / reviewer outputs (sort by mtime, take latest 3–5)
• Project root: `PLAN.md` (current tag header + which tasks are not `verified`), `GAP.md` (if present), `MEMORY.md` (recent reviewer findings)

Synthesize a one-paragraph "what is the pipeline trying to do, and what specifically blocks it?" before any further analysis. Do not skip this — it disciplines the rest of the diagnosis.

Step 2 — Frame the question precisely

Translate the symptom into one or two **falsifiable** hypotheses. Bad hypothesis: "the build is broken". Good hypothesis: "the verifier rejects worker output because `check_worker_report.py` requires a section that the worker dispatch brief does not document, so workers will never produce it."

If you can't form a hypothesis from the artifacts in step 1, say so and stop — write a chat message explaining what you looked at and what was missing for diagnosis. Do not invent.

Step 3 — Walk the godotmaker layers, looking for a defect

Use `references/diagnostic-checklist.md` as the order of inspection. Roughly: hooks first (they're the highest-leverage failure mode — one bad regex blocks every worker), then skill SKILL.md and references/ (instruction contradictions), then config schemas (rejecting valid output), then templates (producing structure the rest of the pipeline can't parse).

For each layer, read the relevant files (godotmaker source, **not** the user's project) and check whether the hypothesis from step 2 is a real defect there.

Step 4 — Report

Output to chat (not a file). Required structure:

## Diagnosis

**Symptom:** <the one-paragraph synthesis from step 1>

**Hypothesis:** <the falsifiable claim from step 2>

**Conclusion:** <one of: GODOTMAKER DEFECT | NOT A GODOTMAKER DEFECT | INSUFFICIENT EVIDENCE>

Then branch:

If `GODOTMAKER DEFECT`

## Where it lives

<file path inside godotmaker repo>:<line range>
<short paste of the offending lines>

## Why it fails

<2–4 sentence explanation tying the lines to the symptom>

## Suggested upstream fix (NOT to be applied here)

<one-paragraph sketch — implementor will need to verify>

## Issue draft for the user

(The user — not you — will copy this to a GitHub issue. Review for
s