drayline Critic Gate
Calibration: Tier 2 (Sonnet-graceful) - designed and tested against Opus 5 + Sonnet 5 dual-primary. Runs correctly on Sonnet 4.6 (legacy-graceful) with slightly less depth on multi-dimensional analysis; on Haiku 4.5 with extended thinking; fallback-graceful on Opus 4.8. Effort default is
highon Opus 5 and Sonnet 5; step down tomediumfor cost-sensitive runs where evals show quality holds. See repository README for model compatibility.
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_authorization": {
"pass": true,
"evidence": "Change is category 'additive_evolution' which is in-scope per authorization list; surfacing entry present in change_log.",
"findings": []
},
"detection_narrowness": {
"pass": false,
"evidence": "New code path gated on 'tables with 2+ rows'; this fires on 47 existing test cases that currently pass.",
"findings": [
{
"severity": "major",
"category": "REQUEST_CHANGES",
"description": "Detection criterion too broad; will fire on existing-passing cases.",
"recommended_action": "Narrow detection to 'tables with synthetic_headers=true AND 2+ rows' to match the specific failure shape."
}
]
},
"regression_risk": {
"pass": true,
"evidence": "Full test suite re-run (62 cases pass); regression sweep across 27 instances complete; no downstream contract changes.",
"findings": []
}
},
"all_findings": [
{
"severity": "major",
"category": "REQUEST_CHANGES",
"check": "detection_narrowness",
"description": "Detection criterion too broad; will fire on existing-passing cases.",
"recommended_action": "Narrow detection to 'tables with synthetic_headers=true AND 2+ rows' to match the specific failure shape."
}
],
"requires_human_escalation": false,
"summary": "REQUEST_CHANGES: detection narrowness check failed with one major finding. Author should tighten detection criterion as recommended; other checks pass. Re-submit after revision."
}
When verdict is APPROVE, all_findings is empty (or contains info-only entries) and the summary is a single sentence: "Change approved; all checks pass." When verdict is REJECT, requires_human_escalation is true and the summary names the specific REJECT-class finding.
Examples
Three worked examples illustrating how the 4 checks combine into the verdict — strict profile + additive engine fix → APPROVE; lenient profile + refactor with broad detection → REQUEST_CHANGES; any profile + test deletion → REJECT — are in references/checks-detailed.md (in the "Worked Examples" section). Consult that file when modeling a new use case against an existing pattern, or when authoring a profile and wanting to see how the routing logic plays out on real changes.
Profile Configuration
The Skill expects a profile config conforming to schema/profile.schema.json. Minimum profile structure:
{
"schema_version": "1.0.0",
"name": "profile-name",
"description": "When this profile applies",
"auto_approve_on": ["info"],
"request_changes_threshold": ["minor", "major"],
"reject_on": ["blocker"],
"skip_checks": [],
"escalation_required_for_categories": ["invariant_violation", "out_of_scope"]
}
Three example profiles ship with the Skill:
lenient— auto-approves on info findings; allows REQUEST_CHANGES auto-resolution if author addresses in same turnbalanced— moderate; auto-approves on info; REQUEST_CHANGES requires explicit author re-submissionstrict— auto-approves only on full pass; any major finding becomes REJECT (no auto-resolution available without HITL)
Users author their own profiles for their availability and risk tolerance using rootnode-profile-builder (if available), or by hand-editing JSON against schema/profile.schema.json. The full severity routing rules — including the coverage requirement that every severity be routed to exactly one outcome, the three example profile patterns explained, and severity classification heuristics — are in references/severity-coverage.md.
When to Use This Skill
Use this Skill when:
- An autonomous agent has proposed an engine change, refactor, or non-trivial modification during execution
- A Claude Code session has produced a diff that should be reviewed by a fresh evaluator before merge
- A sleeping/unattended profile requires independent re-derivation per its critic-required configuration
- An orchestrator is gating engine-evolution proposals before applying them to a stable codebase
Do NOT use this Skill when:
- Evaluating whether work is ready to hand off to autonomous execution (use rootnode-handoff-trigger-check)
- General code review feedback or improvement suggestions (different intent — critic is gate, not advisor)
- Design-time correctness checks during chat-based design work (no execution context yet)
- Reviewing changes to documentation only (no engine impact; over-engineered for the task)
- Authority matrix is unavailable or undefined (Skill cannot proceed; surface and halt)
Troubleshooting
Common failure modes and resolution guidance — covering input validation issues (no authority matrix, vague matrix, oversized diff, incomplete metadata), verdict behavior issues (Critic approves something that broke, rejects valid work, findings appear on APPROVE, author argues with verdict), profile authoring issues (unrouted severities, no fitting standard pattern), and inter-gate coordination (detection narrowness on non-additive changes, Critic vs handoff-gate verdict disagreement, broken verification surface) — are in references/troubleshooting.md. Consult that file when the gate's behavior in production doesn't match expectations.