cm-review

Reviews feature branches adversarially using blind subagents and executed-command evidence.

3|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/PurdueRCAC/rcac-mcp --skill cm-review-purduercac
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: cm-review
Source: https://github.com/PurdueRCAC/rcac-mcp/tree/main/.agents/skills/cm-review
Command: npx skills add https://github.com/PurdueRCAC/rcac-mcp --skill cm-review-purduercac

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews of AI-built feature branches suffer from self-grading bias when the same context that wrote the code also reviews it. This Skill performs adversarial QA on a completed cluster-mcp feature branch by delegating the correctness pass to a fresh reviewer subagent that sees only the locked GOAL.md contract, the spec-excluded diff, and the AGENTS.md invariant checklist — never the author's PLAN.md or TECH.md. ## Core Features & Use Cases - Blind delegated review: A fresh subagent grades the diff against GOAL.md requirement IDs and invariants, with every finding backed by an executed command (pytest runs, CLI drives through a sandbox that blocks real cluster access). - Verdict routing and bounded loop: CONFIRMED findings loop back to /cm-build with a changes-requested verdict; clean branches route to /cm-publish; findings touching the auth/executor core force a mandatory human gate, capped at 2-3 review cycles. - Debate and completeness modes: The debate argument runs two independent reviewers (ship vs. block) for high-risk diffs, and completeness runs a separate sub-pass checking whether every planned phase shipped. - Use Case: After /cm-build finishes a feature branch and marks TECH.md as in_review, run /cm-review to get an evidence-backed REVIEW.md, a requirement-to-evidence matrix, and a verdict commit — without the author's plan biasing the grade. ## Quick Start Run /cm-review on the current feature branch to perform a blind correctness review and record the verdict in REVIEW.md.

Frequently Asked Questions about cm-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review an AI-generated feature branch without bias?▼

Delegate the correctness pass to a fresh reviewer subagent that sees only the locked GOAL.md contract, the spec-excluded diff, and the invariant checklist — never the author's PLAN.md or TECH.md. Require every finding to cite an executed command as evidence.

How do I run the cm-review skill on a feature branch?▼

Invoke /cm-review once the branch's TECH.md status is in_review. It runs a blind correctness pass, writes REVIEW.md, sets the verdict in TECH.md, and routes to /cm-build for fixes or /cm-publish when approved.

What is the difference between CONFIRMED and PLAUSIBLE findings in code review?▼

CONFIRMED findings are reproduced by executed commands and block the branch, looping back to the build step. PLAUSIBLE findings could not be reproduced in the sandbox and are surfaced to a human for triage without auto-blocking.

When should I use the debate mode for branch review?▼

Use /cm-review debate for high-risk diffs that change who a command runs as, on which host, or under whose identity. It launches two independent reviewers arguing ship versus block and reconciles their findings.

Can the reviewer test against a live HPC cluster?▼

No. The reviewer drives the CLI only through a sandbox script that unsets RCAC_SSH_HOST so SSH paths fail closed. Criteria requiring a live cluster are reported as not-verifiable and handed to a human.

What happens when review findings keep recurring across cycles?▼

The review loop is bounded to 2-3 cycles tracked by a durable counter in TECH.md. If the branch does not converge within that bound, the skill escalates to a human instead of continuing the review-build loop.