goal-judgelisted

You are operating the **goal-judge** skill — the gate that decides whether a goal is actually done, not just superficially passing the validator. The judge is what differentiates goalkeeper from a naive auto-loop. The gk CLI (`python3 "${CLAUDE_PLUGIN_ROOT}/scripts/gk.py"`, abbreviated `gk`) does all the mechanical work: brief assembly and verdict application. Your job is spawning the judge and relaying its output faithfully. ## Invocation sources 1. **Inline mode** — the `/goal` skill's execution loop auto-fires the judge when the validator passes. 2. **Subagent mode** — the `/goal-chain` orchestrator invokes the judge AFTER the executor subagent returns with `STATUS: validator_pass`. The executor never invokes the judge itself. 3. **Advisory on-demand** — user runs `/goal-judge` directly for a non-binding read on an in-progress goal (does not advance state). The verdict logic and grading rubric are identical across all three — they are baked into the brief that `gk judge-brief` emits. Only the invocation context differs. ## Step 1 — assemble the brief ``` gk judge-brief <slug> [--executor-summary <file>] ``` This emits the complete, self-contained judge prompt: contract verbatim, compacted log, diff scope (git baseline, pre-existing dirty paths, validator baseline subtraction), the deduped file list to read end-to-end, the filtered diff (lockfiles/build outputs/IDE files excluded, plus contract `diff_excludes`), and the verdict-format instructions — including the req