Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →randallliuxin/gm-fixgap
Fix gaps identified by the Evaluator. Generates GAP.md from evaluation.json, dispatches workers to address critical/major issues, then runs one final verify+review pass. Unlike gm-build (PLAN.md-driven), gm-fixgap is GAP.md-driven. Explicit invocation only — use /gm-fixgap.
Passed 3 of 9 test cases with the skill, and 2 of 9 without it.
and 2 more in the full report
4 fixed4 passed either way14 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
During visual verification of scene rendering, the verifier identifies a conflict where satisfying the visual requirement violates a structural boundary defined in SCENES.md. How should fixgap handle this constraint conflict rather than continuously splitting tasks?
| Checked | Without skill | With skill |
|---|---|---|
| Records the design constraint conflict in GAP.md notes. | Missed | Passed |
| Aligns task execution with SCENES.md or escalates for a design decision. | Passed | Passed |
The instructions your model reads when the skill loads.
$ARGUMENTS
You are fixing specific issues identified by the Evaluator. You read the evaluation report, generate a GAP.md task list, dispatch workers to address each gap, then run one final verify+review pass.
Loop position: /gm-fixgap is never terminal. The cycle is /gm-fixgap → /gm-verify → /gm-evaluate. Evaluate either approves (→ /gm-accept) or surfaces new gaps (→ another /gm-fixgap).
FIRST ACTION — before anything else: Write fixgap to .godotmaker/current_role.
Read .godotmaker/stage.jsonl (treat as empty if missing) — each line is {"role": X, "ts": Y}.
role == "evaluate" exists anywhere in the file OR .godotmaker/evaluation.json does not exist → STOP. Tell user to run /gm-evaluate first.evaluation.json result is "approve" → STOP. Tell the user:
"The latest evaluation was already approved. Recommended next: /gm-accept. If you need to redo this step or have other plans, just tell me."
role == "fixgap" AND GAP.md is not at project root (already archived) → STOP. Tell the user:
"Fixgap already completed for the latest evaluation at {timestamp}. Recommended next: /gm-verify. If you need to redo this step or have other plans, just tell me."
Then read context:
GAP.md (if present) → existing fix progress; find tasks not yet verified. If missing, Step 1 will generate it from evaluation.json (and verify_report.json)..godotmaker/evaluation.json → the source of truth for product-layer issues to fix.godotmaker/verify_report.json → mechanical-layer failures from the most recent verifyPLAN.md → read-only; current tag's **Tag:** header tells you which tag's gaps you're fixing. The same tag-scope discipline as gm-build applies: previous tags' code is touchable only when a GAP item explicitly names it.STRUCTURE.md → architecture (fixes need to respect existing system boundaries)ASSETS.md → the generated-runtime authority; for a visual task, derive each asset with tools/asset_result_registration.py --snapshotMEMORY.md index + sub-files → stable architecture decisions and project constraintsASSETS.md is the sole runtime-asset authority. For a visual task,
derive the snapshot with tools/asset_result_registration.py --snapshot and
test cases passed, vs 2 / 9 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.