Review-tier
/mx:review is the one-shot verdict. These five commands go deeper — each is review-grade, opinionated, and refuses rather than generates. Reach for them when you need a sharper, more specific kind of scrutiny than the headline command.
All of them are read-only unless noted, and all reuse the same scope conventions as /mx:review (default: everything differing from trunk, including untracked files).
/mx:hallucination-check
Section titled “/mx:hallucination-check”Catch invented APIs and non-existent imports — cross-referenced against your installed dependencies
/mx:hallucination-check [--staged | --commit <sha> | --branch <name>] [--scope <path>]The single most AI-specific check. Generators confidently invent methods that were never on a library, function signatures with the wrong arguments, type imports for symbols that aren’t exported, and whole packages that aren’t installed. This command extracts every external and internal reference from your changes and verifies each one against the code actually present — node_modules, site-packages, the module cache, the repo itself.
Every flag is evidence-based (“verifyJwt is not an export of jose@5.2.0”), and anything it can’t resolve is reported as UNVERIFIED rather than inflated into a false positive.
/mx:second-look
Section titled “/mx:second-look”Run the review team on code generated by other tools
/mx:second-look <PR number | url> | --diff <file> | <base>..<head>The review layer on top of whatever wrote the code. Point it at a Claude Tag PR, a Cursor or Copilot diff, or a teammate’s branch, and it runs the full mx review team on output you didn’t supervise — leaning harder on hallucination checking and silent-failure hunting, because that’s what unsupervised generation gets wrong. Takes a PR number/URL by default (via gh), or a diff file or commit range offline. It can post the verdict as a PR comment, but only if you confirm.
/mx:reject
Section titled “/mx:reject”A formal CI gate — strict review with a machine-readable verdict
/mx:reject [--staged | --commit <sha> | --branch <name>] [--scope <path>]Where /mx:review informs, /mx:reject decides. It runs the review team in strict mode (REJECT on any CRITICAL or HIGH finding) and emits a stable MX_VERDICT=PASS|REJECT marker as its final output so CI can gate deterministically. Slash commands can’t set a process exit code, so the command ships a documented headless recipe:
claude -p "/mx:reject --branch origin/main" 2>/dev/null | grep -q '^MX_VERDICT=PASS' \ || { echo "mx:reject blocked the change"; exit 1; }/mx:ratchet
Section titled “/mx:ratchet”Quality only goes up — block any regression vs trunk
/mx:ratchet [--branch <name>] [--dimensions coverage,types,lint,suppressions]A one-way gate against slow erosion. It measures objective dimensions — test coverage, type-check errors, lint cleanliness, suppression count — on trunk and on your branch, then fails if any regressed. The bar is computed live from trunk every run (no stored baseline to drift), measured in a throwaway git worktree so your working tree is never touched. Regressions are named down to the file:line, not just a count.
/mx:audit
Section titled “/mx:audit”Whole-repo quality audit with trend tracking — the cron-friendly evolution of /mx:qa
/mx:audit [--scope <path>] [--since <date>] [--no-trend]Where /mx:qa audits your current diff, /mx:audit audits the whole repository and tracks how its health moves over time. It wraps /mx:qa --full’s checks at repo scope and compares against prior dated reports, so it answers “is the codebase getting better or worse,” not just “is it clean today.” Built to run weekly on a scheduler; each run appends a dated report and the trend builds itself.
How these relate to
/mx:reviewand/mx:qa—/mx:reviewis the everyday verdict;/mx:rejectis its CI-gate sibling./mx:hallucination-checkand/mx:second-lookare sharper, more targeted scrutiny./mx:ratchetguards direction over time on a branch;/mx:auditguards the whole repo’s health across weeks./mx:qaremains the fast diff-scoped structural + spec audit underneath them all.