reviewlisted

# /rein:review Thin orchestration for the **reviewer** role: *no agent approves its own implementation.* It does not reimplement the mechanical checks or the five-axis judgement — it **composes** both and records a registered verdict. Usage: `/rein:review [change-name]` ```bash R=$(command -v rein || ls -d ~/.claude/plugins/cache/*/rein/*/bin/rein 2>/dev/null | sort -V | tail -1) ``` ## Steps 1. **Record this invocation** — never blocks, never fails the run. Shell state does NOT persist between tool calls, so `R` is resolved and used in the SAME block or it is empty and nothing is recorded: ```bash R=$(command -v rein || ls -d ~/.claude/plugins/cache/*/rein/*/bin/rein 2>/dev/null | sort -V | tail -1); "$R" event review ``` 2. Load the plan and the real diff of what was implemented: `"$R" tasks .` and `git diff <base>...<branch>`. 3. **Mechanical part.** Run the project's configured `test`, `lint` and `typecheck` (`"$R" detect .`). If any is red the verdict **cannot** be `APPROVED` however good the code reads — record `CHANGES_REQUESTED` with the failing commands as `BLOCKING` findings (a red gate is by definition a blocker; see the severity vocabulary in step 8). If a slot is not configured, say it is absent rather than substituting one. If `verifyPolicy.mode` is `rendered`, a green suite alone is **not** a complete gate — a dedicated Verify-phase agent has already served and rendered the page and reports one of two outcomes: **failed*