Critic Loop

Produce work that either clears a real acceptance gate or is reported honestly as not passing.

Required protocol

Before execution, read:

• references/protocol.md for role isolation, the task packet, revision handling, and final reporting.
• references/rubric.md for scoring, category floors, hard failures, and status rules.
• references/security-screen.md for the bounded security pass and its limits.
• references/evidence-protocol.md before creating requirement gates, evidence manifests, or verification records.
• references/scorecard-schema.md before creating or validating a scorecard or run manifest.

Non-negotiable rules

1. Freeze a versioned task packet before judging begins. A material requirement change creates a new version and invalidates affected scores.
2. Use separate minimal runtime contexts for execution and criticism. When the agent system supports history controls, start both roles without inherited conversation history and pass only the frozen task packet and necessary artifacts. The critic is read-only and must not repair the artifact it grades.
3. Give the critic the task packet, artifact, and evidence—not the executor's hidden reasoning or an intended answer.
4. Give every frozen must-have specification a binary requirement gate. A clean PASS requires every MUST gate to be independently VERIFIED; FAILED, BLOCKED, or WAIVED gates prevent PASS.
5. Award no points without criterion-specific evidence IDs linked to a verified evidence result. Missing, stale, prose-only, or unverifiable evidence earns zero for that item.
6. Fingerprint the frozen task packet, artifact set, every command-consumed file, evidence manifest, and evidence result. Any content change makes dependent reviews stale.
7. A PASS requires at least 85.00/100, every category floor, no hard failures, no critical unknowns, and no open or disputed defects.
8. Allow at most three critic reviews total: initial review plus up to two revised reviews. Do not interpret this as three send-backs.
9. Never lower a score threshold, erase a defect, or invent evidence to finish the loop.
10. A user-authorized waiver produces ACCEPTED_WITH_WAIVER, never PASS.
11. Treat the security step as a screen, not proof that an artifact is secure.
12. Do not expand permissions. Review approval does not authorize publication, deployment, deletion, external communication, purchases, or other actions outside the task.

Runtime behavior

• For a create/change task, assign an execution agent ownership of the in-scope artifact, then assign an independent critic read-only review responsibility.
• For an existing artifact that the user asked only to review, begin with the critic and do not create an executor unless revisions are authorized.
• If independent agent contexts are unavailable, return BLOCKED: INDEPENDENCE_UNAVAILABLE; do not simulate separate agents in one context.
• On REVISE, send the defect ledger to the same executor. The critic then verifies every prior defect and reruns the full rubric.
• Before awarding PASS, run one bounded improvement sweep and record either NO_MATERIAL_IMPROVEMENT_FOUND or IMPROVEMENTS_IDENTIFIED with linked evidence.
• Keep user-owned or unrelated changes intact. Only the executor may edit, and only within the authorized scope.
• Use the stalled-agent recovery policy in the protocol. A review round is consumed only when a critic returns a complete scorecard; a silent or interrupted attempt is not a review.

Create the v2.1 evidence manifest, declare every command-consumed file in inputArtifactIds, run approved checks without a shell, and create a v2.1 JSON scorecard:

node <skill-directory>/scripts/verify-evidence.mjs --actor CRITIC --allow-command <executable> --report <evidence-result.json> <evidence-manifest.json>
node <skill-directory>/scripts/validate-scorecard.mjs <scorecard.json>

After the critic returns, the orchestrator must independently rerun the evidence checks and validate the complete run:

node <skill-directory>/scripts/verify-review-run.mjs --allow-command <executable> --report <verified-report.json> <review-run.json>

Do not report PASS if root verification was not run successfully. V1 and v2.0 scorecards remain validator-compatible for archival inspection, but cannot complete a new run.

Return the artifact or its location, the machine-generated final status and score, requirement-gate counts, review-round count, hard failures, unresolved defects, security-screen status, evidence summary, hashes, and root-verification result.