[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HF3H6SYTATA6EEWS40QKJ":3,"skill-same:01M71HF3H6SYTATA6EEWS40QKJ":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71HF3H6SYTATA6EEWS40QKJ","loop-judge",null,"Independent phase-level verifier for the Flywheel loop — a thin adapter over spec-driven's verifier + discrimination sensor, not a new engine. Enforces author≠verifier (fresh pass), runs the phase's declared gate (programmatic command or LLM-judge score 0-100), activates the discrimination sensor to catch self-approval, and emits a rich escalation status (DONE\u002FDONE_WITH_CONCERNS\u002FNEEDS_CONTEXT\u002FBLOCKED) with cited evidence — evidence-or-zero, no citation means FAIL. Appends to `.flywheel\u002Fruns\u002F{phase-id}.md` per the run-log template. Use when verifying a phase's work against its contract; never when applying changes (author≠verifier). Triggers (EN): `\u002Floop-judge`, \"verify this phase\", \"judge the change\", \"run the gate on this phase\". Triggers (PT): `\u002Floop-judge`, \"verificar fase\", \"julgar mudança\", \"rodar o gate nesta fase\". Do NOT use for applying changes, writing contracts, or generating roadmaps — use `\u002Floop-run`, `\u002Floop-contract`, or `\u002Floop-roadmap` respectively.","runecraftai\u002Farcanum","runecraftai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279098826?v=4","01M71HBGS1RCAJ490RAYST7M00","01M71HBGT1CB94MNS6T6SGAZKW",1,"CC-BY-4.0","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-judge\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"loop judge","judge","loop","change","work","catch","self","fresh","log","phase","done","when","roadmap","writing","spec-driven","new","sensor","programmatic","pt","never","2026-11-10 10:12:30",false,"---\nname: loop-judge\ndescription: >\n  Independent phase-level verifier for the Flywheel loop — a thin adapter over spec-driven's\n  verifier + discrimination sensor, not a new engine. Enforces author≠verifier (fresh pass), runs\n  the phase's declared gate (programmatic command or LLM-judge score 0-100), activates the\n  discrimination sensor to catch self-approval, and emits a rich escalation status\n  (DONE\u002FDONE_WITH_CONCERNS\u002FNEEDS_CONTEXT\u002FBLOCKED) with cited evidence — evidence-or-zero, no\n  citation means FAIL. Appends to `.flywheel\u002Fruns\u002F{phase-id}.md` per the run-log template.\n  Use when verifying a phase's work against its contract; never when applying changes\n  (author≠verifier). Triggers (EN): `\u002Floop-judge`, \"verify this phase\", \"judge the change\",\n  \"run the gate on this phase\". Triggers (PT): `\u002Floop-judge`, \"verificar fase\", \"julgar mudança\",\n  \"rodar o gate nesta fase\". Do NOT use for applying changes, writing contracts, or generating\n  roadmaps — use `\u002Floop-run`, `\u002Floop-contract`, or `\u002Floop-roadmap` respectively.\nlicense: CC-BY-4.0\nmetadata:\n  version: 1.0.0\n---\n\n# loop-judge\n\nIndependent phase-level verifier for the Flywheel loop. **This is an ADAPTER over `spec-driven`'s verifier + discrimination sensor — not a new engine.** It reads a phase contract, runs the declared gate, and returns a cited, nuanced verdict that the loop orchestrator (`loop-run`) acts on.\n\n```\nCONTRACT ─► JUDGE ─► status + verdict + evidence ─► run-log ─► loop-run\n              │\n              ├─ gate: programmatic (cmd → exit\u002Fnumber) ─ OR ─\n              ├─ gate: LLM-judge (score 0–100 vs BDD ACs)\n              └─ sensor: spec-driven's discrimination sensor (anti-self-approval)\n```\n\n## Overview\n\nEvery phase in the Flywheel loop has a **contract** (`program.md`) that declares:\n\n- **Acceptance Criteria** in BDD form (Given\u002FWhen\u002FThen)\n- **Verify Method**: `programmatic` (a command with a baseline) or `llm-judge` (a rubric score against ACs)\n- **Sensor**: on\u002Foff (discrimination sensor activation)\n- **Impact**: internal | user-facing | business-facing\n\n`loop-judge` reads this contract, runs the appropriate gate **as a fresh, independent pass** (author≠verifier), activates spec-driven's discrimination sensor when `sensor: on`, and produces a **rich escalation status** (not binary pass\u002Ffail) with **traceable cited evidence**.\n\n## When to Use\n\n| Trigger | Language |\n|---------|----------|\n| `\u002Floop-judge` | EN, PT |\n| `verify this phase`, `judge the change`, `run the gate on this phase` | EN |\n| `verificar fase`, `julgar mudança`, `rodar o gate nesta fase` | PT |\n\n**Do NOT use for:**\n- Applying changes (use `loop-run` — author≠verifier)\n- Writing contracts (use `loop-contract`)\n- Generating roadmaps (use `loop-roadmap`)\n- Learning\u002Fmemory recording (use `loop-learn`)\n- Spec-level task verification (use `spec-driven` directly)\n\n## Process\n\n### Step 1 — Load the Contract\n\nRead the phase's contract file:\n\n```\n.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md\n```\n\nConfirm the following fields exist and are well-formed:\n\n- `kind: programmatic | llm-judge`\n- `command:` (when `programmatic`)\n- `judge_rubric:` (when `llm-judge`) — scoring rubric with PASS threshold\n- `sensor: on | off`\n- Acceptance Criteria (BDD form)\n\nIf the contract is missing, malformed, or ambiguous, emit **NEEDS_CONTEXT** with the specific gap — do not guess.\n\n### Step 2 — Enforce author≠verifier\n\n**The agent that ran APPLY must not run JUDGE.** This is a non-negotiable separation inherited from `spec-driven`'s verifier pattern.\n\n- If this is a fresh agent session or invocation, confirm: no prior context from the APPLY step.\n- If the same agent is attempting to judge its own work, refuse and return **BLOCKED** with the reason: \"author≠verifier violation — judge must be a fresh pass.\"\n\nThis is not a soft guideline. The loop's trust model depends on it.\n\n### Step 3 — Run the Gate\n\n#### 3a. Programmatic Gate (`kind: programmatic`)\n\n1. Execute the declared `command` in the workspace.\n2. Capture:\n   - **exit code** (0 = pass, ≠0 = fail)\n   - **stdout\u002Fstderr output**\n   - **numeric result** (if the command prints a number)\n3. Compare the result to the baseline declared in the contract.\n4. Derive `measure`: number vs baseline.\n5. Gate passes when exit code = 0 AND the numeric result meets or exceeds baseline. Otherwise, REVERT.\n\n#### 3b. LLM-Judge Gate (`kind: llm-judge`)\n\n1. Load the contract's Acceptance Criteria (AC-1..N in BDD form).\n2. Load the **judge_rubric** — the scoring dimensions (e.g., correctness, completeness, friction) and the **PASS threshold**.\n3. Inspect the applied changes against each AC independently:\n   - Verify with concrete evidence: `file:line`, test output, command result.\n   - Do NOT rely on the author's claims — re-derive evidence independently.\n4. Score **0–100** per the rubric. Derive `measure`: score vs PASS threshold.\n5. Gate passes when score ≥ PASS threshold. Otherwise, REVERT.\n\n### Step 4 — Activate the Discrimination Sensor\n\nWhen the contract declares `sensor: on`, activate **spec-driven's discrimination sensor** (author≠verifier, evidence-or-zero):\n\n1. Inject a **known-bad variant** of the change into scratch state (a mutation that should cause the gate to fail).\n2. Re-run the gate against the mutant.\n3. Observe: does the gate reject the mutant?\n\n- **Sensor PASS**: the gate correctly rejects the known-bad variant → the gate is trustworthy.\n- **Sensor FAIL**: the mutant survives → the gate is too weak or the change is untestable. The verifier result is **invalid** regardless of the measured score. Treat as FAIL.\n\n**Do NOT re-specify the sensor mechanics.** This skill delegates to `spec-driven`'s verifier pattern. For the full sensor mechanics (mutation strategy, scratch state isolation, surviving-mutant handling), see `spec-driven`'s verifier documentation and the `verifier.md` reference in `loop-run\u002Freferences\u002F`.\n\n### Step 5 — Emit Escalation Status\n\nDerive a **rich escalation status** — never a binary pass\u002Ffail:\n\n| Status | Condition |\n|--------|-----------|\n| **DONE** | All ACs met, gate passed, sensor passed (if on), evidence cited for every claim. |\n| **DONE_WITH_CONCERNS** | ACs met and gate passed, but a concern surfaced: marginal score (within 10% of threshold), sensor near-miss, or evidence available but weak. Advance with a concern note attached. |\n| **NEEDS_CONTEXT** | Cannot reach a verdict — missing information, ambiguous AC, or the gate requires input not yet available. Loop pauses; `loop-run` dispatches a discovery subagent. Does NOT count as a revert. |\n| **BLOCKED** | Cannot proceed. Author≠verifier violation, sensor failure (mutant survives), gate unrecoverable, or scope violation detected. Phase is halted and escalated to human immediately regardless of autonomy mode. |\n\n**`BLOCKED` is the only status that forces immediate escalation** — all others are actionable by the loop.\n\n### Step 6 — Cite Evidence\n\nEvery verdict carries a **traceable citation**:\n\n| Gate type | Evidence form |\n|-----------|---------------|\n| Programmatic | Command line + exit code + captured output + baseline comparison (`file:line` of test result, or raw stdout) |\n| LLM-judge | Per-AC rationale tied to a concrete source (`file:line`, test output) + rubric dimension scores |\n| Sensor | Mutant injected + gate result against mutant + conclusion |\n\n**Evidence-or-zero:** if the judge cannot cite specific, traceable evidence for a verdict, the result is **FAIL** (score = 0, status = NEEDS_CONTEXT or BLOCKED depending on whether retrieval is possible). \"Seems right\" is not evidence.\n\n### Step 7 — Append to Run Log\n\nWrite the iteration to the phase's run log:\n\n```\n.flywheel\u002Fruns\u002F\u003Cphase-id>.md\n```\n\nFollow the **run-log template** (see `loop-run\u002Freferences\u002Frun-log.md`). Each iteration entry includes:\n\n```markdown\n## Iteration \u003CN>\n\n- **hypothesis**: \u003Cthe applied change, or null if first iteration>\n- **diff-range**: \u003Ccommit\u002Frange or file set touched>\n- **measure**: \u003Cprogrammatic number | judge score> vs baseline \u003C...>\n- **status**: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED\n- **verdict**: KEEP | REVERT\n- **evidence**: \u003Ccited source — file:line, command output, or judge rationale>\n- **note**: \u003Cwhy — one sentence>\n```\n\n- **Append** to the existing log; never overwrite prior iterations.\n- Include the `Outcome` section only on the final iteration (when phase is complete or escalated).\n- Use the exact field names from the run-log template so `loop-run` can parse them.\n\n## Example\n\n**Phase `m1-p1`** — \"POST \u002Fapi\u002Fregister returns 201 on success.\" Contract declares `kind: programmatic`, `command: \"npm test -- register.test.ts\"`, baseline exit code `0`, `sensor: on`, `impact: internal`.\n\n1. **Load contract**: `.flywheel\u002Fcontracts\u002Fm1-p1.md` — all required fields present and well-formed.\n2. **Enforce author≠verifier**: this is a fresh judge invocation with no APPLY context. Proceed.\n3. **Run the gate**: `npm test -- register.test.ts` → exit code `0`, all assertions pass.\n4. **Activate sensor** (`sensor: on`): inject a known-bad mutant (drop the `201` status assertion) into scratch state, re-run the gate against it → gate correctly fails on the mutant. Sensor **PASS**.\n5. **Emit status**: **DONE** — all ACs met, gate passed, sensor passed, evidence cited (`register.test.ts:42` assertion output).\n6. **Append to run log**: write the iteration to `.flywheel\u002Fruns\u002Fm1-p1.md` with hypothesis, measure, `status: DONE`, `verdict: KEEP`, cited evidence, and a one-line note.\n\n`loop-run` reads this entry and, per the decision flow, invokes `loop-learn` and advances to the next phase.\n\n## Output Contract\n\nAfter completing all steps, `loop-judge` emits:\n\n1. **Status**: one of DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED\n2. **Verdict**: KEEP | REVERT\n3. **Measure**: the raw gate result (number or score)\n4. **Evidence**: traceable citation for every claim\n5. **Sensor result** (when `sensor: on`): PASS or FAIL\n6. **Run-log entry** appended to `.flywheel\u002Fruns\u002F\u003Cphase-id>.md`\n\nThe loop orchestrator (`loop-run`) reads these fields from the run-log and acts according to the decision flow in the plan (§14).\n\n## Reuse\n\n| Capability | Source |\n|------------|--------|\n| author≠verifier enforcement | `spec-driven` verifier pattern |\n| Discrimination sensor | `spec-driven` verifier (mutation injection, scratch state, surviving-mutant detection) |\n| evidence-or-zero | `spec-driven` verifier (traceable citations mandatory) |\n| Run-log template | `loop-run\u002Freferences\u002Frun-log.md` |\n| Verifier contract | `loop-run\u002Freferences\u002Fverifier.md` |\n| Program contract format | `loop-run\u002Freferences\u002Fprogram.md` |\n\nThis skill does not re-implement or re-specify how the discrimination sensor works, how mutations are injected, or how scratch state is isolated. Those mechanics live in `spec-driven`'s verifier. `loop-judge` is the **integration point** that applies `spec-driven`'s verifier at roadmap-phase granularity with Flywheel's escalation statuses and run-log format.\n","# loop-judge\n\nIndependent phase-level verifier for the Flywheel loop. **This is an ADAPTER over `spec-driven`'s verifier + discrimination sensor — not a new engine.** It reads a phase contract, runs the declared gate, and returns a cited, nuanced verdict that the loop orchestrator (`loop-run`) acts on.\n\n```\nCONTRACT ─► JUDGE ─► status + verdict + evidence ─► run-log ─► loop-run\n              │\n              ├─ gate: programmatic (cmd → exit\u002Fnumber) ─ OR ─\n              ├─ gate: LLM-judge (score 0–100 vs BDD ACs)\n              └─ sensor: spec-driven's discrimination sensor (anti-self-approval)\n```\n\n## Overview\n\nEvery phase in the Flywheel loop has a **contract** (`program.md`) that declares:\n\n- **Acceptance Criteria** in BDD form (Given\u002FWhen\u002FThen)\n- **Verify Method**: `programmatic` (a command with a baseline) or `llm-judge` (a rubric score against ACs)\n- **Sensor**: on\u002Foff (discrimination sensor activation)\n- **Impact**: internal | user-facing | business-facing\n\n`loop-judge` reads this contract, runs the appropriate gate **as a fresh, independent pass** (author≠verifier), activates spec-driven's discrimination sensor when `sensor: on`, and produces a **rich escalation status** (not binary pass\u002Ffail) with **traceable cited evidence**.\n\n## When to Use\n\n| Trigger | Language |\n|---------|----------|\n| `\u002Floop-judge` | EN, PT |\n| `verify this phase`, `judge the change`, `run the gate on this phase` | EN |\n| `verificar fase`, `julgar mudança`, `rodar o gate nesta fase` | PT |\n\n**Do NOT use for:**\n- Applying changes (use `loop-run` — author≠verifier)\n- Writing contracts (use `loop-contract`)\n- Generating roadmaps (use `loop-roadmap`)\n- Learning\u002Fmemory recording (use `loop-learn`)\n- Spec-level task verification (use `spec-driven` directly)\n\n## Process\n\n### Step 1 — Load the Contract\n\nRead the phase's contract file:\n\n```\n.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md\n```\n\nConfirm the following fields exist and are well-formed:\n\n- `kind: programmatic | llm-judge`\n- `command:` (when `programmatic`)\n- `judge_rubric:` (when `llm-judge`) — scoring rubric with PASS threshold\n- `sensor: on | off`\n- Acceptance Criteria (BDD form)\n\nIf the contract is missing, malformed, or ambiguous, emit **NEEDS_CONTEXT** with the specific gap — do not guess.\n\n### Step 2 — Enforce author≠verifier\n\n**The agent that ran APPLY must not run JUDGE.** This is a non-negotiable separation inherited from `spec-driven`'s verifier pattern.\n\n- If this is a fresh agent session or invocation, confirm: no prior context from the APPLY step.\n- If the same agent is attempting to judge its own work, refuse and return **BLOCKED** with the reason: \"author≠verifier violation — judge must be a fresh pass.\"\n\nThis is not a soft guideline. The loop's trust model depends on it.\n\n### Step 3 — Run the Gate\n\n#### 3a. Programmatic Gate (`kind: programmatic`)\n\n1. Execute the declared `command` in the workspace.\n2. Capture:\n   - **exit code** (0 = pass, ≠0 = fail)\n   - **stdout\u002Fstderr output**\n   - **numeric result** (if the command prints a number)\n3. Compare the result to the baseline declared in the contract.\n4. Derive `measure`: number vs baseline.\n5. Gate passes when exit code = 0 AND the numeric result meets or exceeds baseline. Otherwise, REVERT.\n\n#### 3b. LLM-Judge Gate (`kind: llm-judge`)\n\n1. Load the contract's Acceptance Criteria (AC-1..N in BDD form).\n2. Load the **judge_rubric** — the scoring dimensions (e.g., correctness, completeness, friction) and the **PASS threshold**.\n3. Inspect the applied changes against each AC independently:\n   - Verify with concrete evidence: `file:line`, test output, command result.\n   - Do NOT rely on the author's claims — re-derive evidence independently.\n4. Score **0–100** per the rubric. Derive `measure`: score vs PASS threshold.\n5. Gate passes when score ≥ PASS threshold. Otherwise, REVERT.\n\n### Step 4 — Activate the Discrimination Sensor\n\nWhen the contract declares `sensor: on`, activate **spec-driven's discrimination sensor** (author≠verifier, evidence-or-zero):\n\n1. Inject a **known-bad variant** of the change into scratch state (a mutation that should cause the gate to fail).\n2. Re-run the gate against the mutant.\n3. Observe: does the gate reject the mutant?\n\n- **Sensor PASS**: the gate correctly rejects the known-bad variant → the gate is trustworthy.\n- **Sensor FAIL**: the mutant survives → the gate is too weak or the change is untestable. The verifier result is **invalid** regardless of the measured score. Treat as FAIL.\n\n**Do NOT re-specify the sensor mechanics.** This skill delegates to `spec-driven`'s verifier pattern. For the full sensor mechanics (mutation strategy, scratch state isolation, surviving-mutant handling), see `spec-driven`'s verifier documentation and the `verifier.md` reference in `loop-run\u002Freferences\u002F`.\n\n### Step 5 — Emit Escalation Status\n\nDerive a **rich escalation status** — never a binary pass\u002Ffail:\n\n| Status | Condition |\n|--------|-----------|\n| **DONE** | All ACs met, gate passed, sensor passed (if on), evidence cited for every claim. |\n| **DONE_WITH_CONCERNS** | ACs met and gate passed, but a concern surfaced: marginal score (within 10% of threshold), sensor near-miss, or evidence available but weak. Advance with a concern note attached. |\n| **NEEDS_CONTEXT** | Cannot reach a verdict — missing information, ambiguous AC, or the gate requires input not yet available. Loop pauses; `loop-run` dispatches a discovery subagent. Does NOT count as a revert. |\n| **BLOCKED** | Cannot proceed. Author≠verifier violation, sensor failure (mutant survives), gate unrecoverable, or scope violation detected. Phase is halted and escalated to human immediately regardless of autonomy mode. |\n\n**`BLOCKED` is the only status that forces immediate escalation** — all others are actionable by the loop.\n\n### Step 6 — Cite Evidence\n\nEvery verdict carries a **traceable citation**:\n\n| Gate type | Evidence form |\n|-----------|---------------|\n| Programmatic | Command line + exit code + captured output + baseline comparison (`file:line` of test result, or raw stdout) |\n| LLM-judge | Per-AC rationale tied to a concrete source (`file:line`, test output) + rubric dimension scores |\n| Sensor | Mutant injected + gate result against mutant + conclusion |\n\n**Evidence-or-zero:** if the judge cannot cite specific, traceable evidence for a verdict, the result is **FAIL** (score = 0, status = NEEDS_CONTEXT or BLOCKED depending on whether retrieval is possible). \"Seems right\" is not evidence.\n\n### Step 7 — Append to Run Log\n\nWrite the iteration to the phase's run log:\n\n```\n.flywheel\u002Fruns\u002F\u003Cphase-id>.md\n```\n\nFollow the **run-log template** (see `loop-run\u002Freferences\u002Frun-log.md`). Each iteration entry includes:\n\n```markdown\n## Iteration \u003CN>\n\n- **hypothesis**: \u003Cthe applied change, or null if first iteration>\n- **diff-range**: \u003Ccommit\u002Frange or file set touched>\n- **measure**: \u003Cprogrammatic number | judge score> vs baseline \u003C...>\n- **status**: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED\n- **verdict**: KEEP | REVERT\n- **evidence**: \u003Ccited source — file:line, command output, or judge rationale>\n- **note**: \u003Cwhy — one sentence>\n```\n\n- **Append** to the existing log; never overwrite prior iterations.\n- Include the `Outcome` section only on the final iteration (when phase is complete or escalated).\n- Use the exact field names from the run-log template so `loop-run` can parse them.\n\n## Example\n\n**Phase `m1-p1`** — \"POST \u002Fapi\u002Fregister returns 201 on success.\" Contract declares `kind: programmatic`, `command: \"npm test -- register.test.ts\"`, baseline exit code `0`, `sensor: on`, `impact: internal`.\n\n1. **Load contract**: `.flywheel\u002Fcontracts\u002Fm1-p1.md` — all required fields present and well-formed.\n2. **Enforce author≠verifier**: this is a fresh judge invocation with no APPLY context. Proceed.\n3. **Run the gate**: `npm test -- register.test.ts` → exit code `0`, all assertions pass.\n4. **Activate sensor** (`sensor: on`): inject a known-bad mutant (drop the `201` status assertion) into scratch state, re-run the gate against it → gate correctly fails on the mutant. Sensor **PASS**.\n5. **Emit status**: **DONE** — all ACs met, gate passed, sensor passed, evidence cited (`register.test.ts:42` assertion output).\n6. **Append to run log**: write the iteration to `.flywheel\u002Fruns\u002Fm1-p1.md` with hypothesis, measure, `status: DONE`, `verdict: KEEP`, cited evidence, and a one-line note.\n\n`loop-run` reads this entry and, per the decision flow, invokes `loop-learn` and advances to the next phase.\n\n## Output Contract\n\nAfter completing all steps, `loop-judge` emits:\n\n1. **Status**: one of DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED\n2. **Verdict**: KEEP | REVERT\n3. **Measure**: the raw gate result (number or score)\n4. **Evidence**: traceable citation for every claim\n5. **Sensor result** (when `sensor: on`): PASS or FAIL\n6. **Run-log entry** appended to `.flywheel\u002Fruns\u002F\u003Cphase-id>.md`\n\nThe loop orchestrator (`loop-run`) reads these fields from the run-log and acts according to the decision flow in the plan (§14).\n\n## Reuse\n\n| Capability | Source |\n|------------|--------|\n| author≠verifier enforcement | `spec-driven` verifier pattern |\n| Discrimination sensor | `spec-driven` verifier (mutation injection, scratch state, surviving-mutant detection) |\n| evidence-or-zero | `spec-driven` verifier (traceable citations mandatory) |\n| Run-log template | `loop-run\u002Freferences\u002Frun-log.md` |\n| Verifier contract | `loop-run\u002Freferences\u002Fverifier.md` |\n| Program contract format | `loop-run\u002Freferences\u002Fprogram.md` |\n\nThis skill does not re-implement or re-specify how the discrimination sensor works, how mutations are injected, or how scratch state is isolated. Those mechanics live in `spec-driven`'s verifier. `loop-judge` is the **integration point** that applies `spec-driven`'s verifier at roadmap-phase granularity with Flywheel's escalation statuses and run-log format.\n",{"name":5,"license":14,"metadata":48,"description":50},{"version":49},"1.0.0","Independent phase-level verifier for the Flywheel loop — a thin adapter over spec-driven's verifier + discrimination sensor, not a new engine. Enforces author≠verifier (fresh pass), runs the phase's declared gate (programmatic command or LLM-judge score 0-100), activates the discrimination sensor to catch self-approval, and emits a rich escalation status (DONE\u002FDONE_WITH_CONCERNS\u002FNEEDS_CONTEXT\u002FBLOCKED) with cited evidence — evidence-or-zero, no citation means FAIL. Appends to `.flywheel\u002Fruns\u002F{phase-id}.md` per the run-log template. Use when verifying a phase's work against its contract; never when applying changes (author≠verifier). Triggers (EN): `\u002Floop-judge`, \"verify this phase\", \"judge the change\", \"run the gate on this phase\". Triggers (PT): `\u002Floop-judge`, \"verificar fase\", \"julgar mudança\", \"rodar o gate nesta fase\". Do NOT use for applying changes, writing contracts, or generating roadmaps — use `\u002Floop-run`, `\u002Floop-contract`, or `\u002Floop-roadmap` respectively.\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Floop-judge",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add runecraftai\u002Farcanum --skill loop-judge",{"tool":64,"command":65},"bunx","bunx skills add runecraftai\u002Farcanum --skill loop-judge",{"tool":67,"command":68},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill loop-judge","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-judge\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"README.md","REFERENCE","参考文档",732,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-judge\u002FREADME.md",[79,108,133,159,179,203],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":90,"publishedAt":43},"01M71HGTN9FRQ3WEZMVVX7C3VZ","using-agent-skills","Discovers and invokes the right @runecraft\u002Fspells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: \u002Fskill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json \u002F Claude Code plugin paths).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[91,92,93,41,94,95,34,96,97,98,99,100,101,27,102,103,104,105,106,107],"using agent skills","standalone","which","pick","Meta","workflow","you","code","tasks","skill discovery","route","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":43},"01M71HGPD6N9JH2G8EVBXJR77X","typescript-patterns","TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: \u002Ftypescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: \u002Ftypescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftypescript-patterns\u002FSKILL.md",[],[115,116,117,118,119,120,41,121,122,123,124,125,126,127,128,129,130,131,98,132],"typescript","patterns","typescript patterns","do","projects","for","runtime","project","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":145,"publishedAt":43},"01M71HGJAKX4TFN0PECYPJ9S38","test-driven-development","Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: \u002Ftest, write tests first, TDD, prove it, 80\u002F15\u002F5 pyramid, Beyonce Rule. PT triggers: \u002Fteste, testes primeiro, provar com teste, pirâmide 80\u002F15\u002F5. Do NOT use for: production incident triage (use \u002Fdebug), or cosmetic-only changes with no behavioral surface.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[139,142],{"categoryNo":140,"categoryName":141,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":143,"categoryName":144,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000008","测试与质量",[146,147,148,149,41,150,151,152,127,34,153,154,155,156,157,118,120,124,126,158],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":160,"name":37,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":43},"01M71HGC1H4JQFJWH613XTJC59","Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",[],[165,166,149,167,168,169,170,41,122,171,151,172,173,174,175,176,34,177,99,178],"spec driven","spec","coverage","complexity","task breakdown","scope","decision","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":189,"publishedAt":43},"01M71HG5CSP04F29HRAG7XVYKG","skill-forge","Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: \u002Fforge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: \u002Fforge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch\u002Fmeta skill), planning feature implementation, or designing software architecture.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fskill-forge\u002FSKILL.md",[185,188],{"categoryNo":186,"categoryName":187,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},[190,191,192,93,193,194,41,195,95,196,197,173,178,198,199,153,200,106,201,202],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"publishedAt":43},"01M71HG1RAQY3GXX0Q5TMW0XD6","shipping-and-launch","Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: \u002Fship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: \u002Fshippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fshipping-and-launch\u002FSKILL.md",[],[210,211,212,41,213,214,34,215,216,217,218,27,219,26,220,221,199,222,223,224],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","exposure","plano","ship","Tools","pre-launch"]