devrites

Fresh-context, feature-scoped code reviewer for /rite-review and /rite-seal. Use to get an independent full-discipline review of a DevRites feature diff — tests-first, correctness, readability, architecture, maintainability, standards. Adversarial — finds problems, does not rubber-stamp.

Fresh-context adversarial reviewer for the devrites-doubt loop. Use to stress-test a single claim or decision with zero anchoring context. Its job is to break the claim, not to validate it.

Fresh-context frontend/UX reviewer for /rite-seal on UI features. Use to independently review UX flow, accessibility, responsive behavior, design-system alignment, and anti-AI-slop on a DevRites feature. Adversarial about UI quality.

Fresh-context, measure-first performance reviewer for /rite-seal. Use to independently review a DevRites feature diff for N+1s, hot-path work, payload/bundle size, and Core Web Vitals risks. Won't claim a slowdown without a number or a measurement to take.

Fresh-context, read-only reviewer for the /rite-vet engineering plan-review loop. Judges a defined implementation plan (plan.md + tasks.md, against spec.md intent) on the engineering rubric — architecture / plan code-quality / test-coverage design / performance / scope-discipline / reversibility / failure-mode coverage — BEFORE any code exists. Every finding carries a 1-10 confidence band and must quote the line that motivates it or be suppressed (the verification gate). Bands the axes, gates on the weakest, returns labeled findings. Adversarial — hunts for what will cost a redo; does not validate or edit.

Design stable APIs and interface contracts before implementation — REST/GraphQL endpoints, module boundaries, type contracts, FE/BE splits. Use when the user says "design the API", "contract this out", "split frontend and backend", or a slice crosses a boundary. Not for internal helpers or post-ship interfaces (use `/rite-review`).

Read-only audit dispatch for the active feature on the requested axis — security (OWASP, trust boundary, secrets), perf (measure-first, N+1, CWV), or simplify (Chesterton's Fence, deletion test). Use when the user says "security review", "is this safe", "is this fast enough", "perf check", "N+1", "simplify this", "Chesterton's Fence". Not for write actions or whole-project audits.

Prove UI behavior via the browser-proof ladder — browser-harness → Chrome DevTools MCP → `/run`+`/verify` → project E2E → manual — recording routes, viewports, screenshots, console, network, interactions, design-reference match to `browser-evidence.md`. Use when the user says "check the UI in browser", "screenshot this", "prove it renders". Not for backend-only features.

Debug systematically when tests, builds, or runtime/browser checks fail — deterministic feedback loop, reproduce, 3-5 ranked hypotheses, instrument, fix root cause, regression-test. Use when the user says "debug this", "why is it failing", "it broke", "the build is red", "the tests fail". Not for code review or flaky tests (fix the flake first).

Stress-test a single non-trivial decision via CLAIM → EXTRACT → DOUBT → RECONCILE → STOP with `devrites-doubt-reviewer` for an independent take. Use when the user says "are we sure", "double-check this", "what could go wrong", or a boundary / data-model / auth / public-API / migration change is about to commit. Not for post-merge review or trivial choices.