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.