Critic Gate

Independent re-derivation of proposed changes during autonomous execution. Returns a structured verdict before any change lands. The load-bearing safety mechanism for autonomous engine evolution — without it, multi-cycle drift is guaranteed.

The premise: the agent that proposes a change cannot be the agent that approves it. When Claude Code is iterating on an engine, every proposed change has an author who has reasoned themselves into the change's necessity. That author's judgment is exactly what the change is grounded in — making them an unreliable evaluator of the change's safety. The critic gate runs on a fresh evaluator with no commitment to the change, applying narrow, named checks against the work's invariants.

This Skill is the rootnode runtime layer's analog to a "Critic Agent" role — an independent re-derivation pass over proposed changes. Generalized for portability: the authority matrix is supplied as input, not baked in.

Important

The critic does not re-derive the diagnosis. It does not verify that the bug exists or that the proposed fix would solve it. Those are the change author's responsibility. The critic checks one thing: would applying this change violate any invariant, exceed any authorization, or introduce regression risk that wasn't accepted in the work's design? The diagnosis can be wrong; that's a verification problem, not a critic problem.

Authority matrix is mandatory input. The critic cannot evaluate compliance against rules it doesn't have. If no authority matrix is provided in work_context, the gate halts with evidence_not_provided rather than fabricating rules. This is the most common failure mode to design against.

Structured JSON output is the deliverable. Same shape as rootnode-handoff-trigger-check (if available; the shape is documented inline below regardless). An orchestrator should be able to parse the verdict and act on it without an LLM round-trip.

Three verdicts, not two. Unlike handoff-trigger-check (PASS/FAIL), critic gate has three: APPROVE (proceed), REQUEST_CHANGES (specific issues to address; change author re-proposes), REJECT (proposed change violates non-negotiable constraints; do not re-propose without scope-authorization escalation). The middle verdict matters — most real critic findings are fixable, not fatal.

Profile thresholds calibrate strictness. Same profile pattern as handoff-trigger-check. Sleeping profiles run all checks at strictest thresholds; desk profiles allow REQUEST_CHANGES on minor findings to be auto-approved if the change author resolves them in the same turn.

Severity coverage requirement. Every severity (info, minor, major, blocker) must be routed by the profile to exactly one of auto_approve_on, request_changes_threshold, or reject_on. Unrouted severities create ambiguous runtime behavior. The Skill validates coverage on profile load and rejects misconfigured profiles before any change is evaluated. See references/severity-coverage.md for the full routing rules and example profile patterns.

The 4 Checks — Overview

Each check evaluates pass/fail/conditional with evidence and findings. The profile determines how findings combine into the verdict. Per-check pass evidence requirements, full REQUEST_CHANGES finding language, REJECT finding language, edge cases, and worked examples are in references/checks-detailed.md.

1. Invariant Compliance

The proposed change does not modify any element protected by the authority matrix. Pass requires that every tier of the matrix has been examined against the change diff and no protected content is touched (or only authorized tiers are touched). REQUEST_CHANGES findings handle inadvertent tier crossings the author can re-scope; REJECT findings handle deliberate invariant violations that require scope-authorization escalation.

2. Scope Authorization

The proposed change falls within the in-scope authorization for autonomous iteration. Pass requires the change's category appears in the in-scope list (or in-scope-with-notification list with proper surfacing). REQUEST_CHANGES findings handle in-scope changes missing required surfacing; REJECT findings handle out-of-scope categories that the Critic has no authority to approve.

3. Detection Narrowness

For changes that add new code paths gated by detection criteria (the additive-evolution pattern): the detection criterion is narrow enough that the new path only fires on the target failure shape, not on existing-passing cases. Pass requires specific detection (named pattern, named field, named state) plus regression-sweep evidence. REQUEST_CHANGES findings handle overly-broad detection the author can tighten; REJECT findings handle detection so broad the change is effectively non-additive.

This check is skipped for changes that are not additive-evolution pattern (recorded as pass: null, skipped: true, reason: "not_additive_evolution").

4. Regression Risk

The change has acceptable regression risk given the work's verification surface and the active profile's risk tolerance. Pass requires documented verification gates (test suite, regression sweep, smoke tests as appropriate) all clean and no unmodified-but-affected downstream contracts. REQUEST_CHANGES findings handle incomplete verification the author can complete; REJECT findings handle deferred-fix patterns or broken verification surfaces.

Workflow

When invoked:

Step 1 — Receive inputs. The Skill expects three inputs:

• profile: A profile config matching the included schema. Names verdict thresholds, behavior on REQUEST_CHANGES, and skip rules.
• work_context: Must include the authority matrix (full text or path), the in-scope/out-of-scope authorization lists, and the proposed change (diff or change description with affected files/sections named).
• change_metadata: Author identity, diagnosis statement, claimed verification, and category (engine_fix / additive_evolution / refactor / test_addition / config_change / other).

Step 2 — Validate inputs. If authority matrix is missing, halt with evidence_not_provided and surface to caller. If the change diff is too vague to evaluate (no specific files/sections named), halt with evidence_too_vague and request specifics.

Step 3 — Run the 4 checks in order. Each check produces pass / fail / conditional / skipped with evidence and findings. Findings include severity (info / minor / major / blocker) and concrete language describing what's wrong.

Step 4 — Apply profile threshold to determine verdict:

• APPROVE — all checks pass with no findings, OR all findings are info-severity only AND profile permits info-only auto-approval
• REQUEST_CHANGES — at least one check has minor or major findings, but no blockers AND no REJECT-class findings. Author can re-propose after addressing findings.
• REJECT — at least one blocker-severity finding, OR any finding marked REJECT-class regardless of severity (invariant violation, out-of-scope, etc.). Author cannot re-propose without scope-authorization escalation.

Step 5 — Generate verdict. Produce structured JSON output (see Output Format). Include per-check results, all findings with severity, recommended actions per finding, and a requires_human_escalation boolean for any REJECT-class outcome.

Step 6 — Return. Output the JSON. If verbose mode, append a 3-5 sentence human-readable summary explaining the verdict and naming the most critical findings.

Output Format

{
  "verdict": "APPROVE | REQUEST_CHANGES | REJECT",
  "profile_applied": "profile-name-from-input",
  "checked_at": "ISO-8601 timestamp",
  "change_id": "identifier from change_metadata",
  "checks": {
    "invariant_compliance": {
      "pass": true,
      "evidence": "Change touches only Tier 3 UI chrome per authority matrix; no Tier 1 or Tier 2 modifications detected.",
      "findings": []
    },
    "scope_authori