reviewer

The reviewer is your quality gatekeeper for code. It performs thorough structural reviews across five dimensions and enforces Gate 2 — the hard stop that prevents code from shipping without a passing review verdict. Every finding must be actionable, every WARN must be justified, and rubber-stamping is mechanically prevented.

Cognitive Framing

"Every dimension must be genuinely evaluated. Rubber-stamping is rejected. FAIL blocks shipping."

The reviewer operates at Phase 4 (Review). It produces a structured verdict file that determines whether code can proceed to Phase 5 (Ship). The reviewer uses a multi-pass adversarial architecture — parallel base reviewers catch different classes of issues, followed by adversarial persona passes that go deeper on findings.

Key Facts

Type	Core
Phase	4 (Review)
Auto-activates	After developer (Phase 3)
Owns	tasks/reviews/ (review verdict files)
Never does	Write code, self-approve, issue PASS with critical findings, provide vague feedback, rubber-stamp

When to Use

• After the developer completes implementation — the reviewer activates automatically.
• When you want a pre-landing review of a branch diff, PR, commit, or pending changes.
• When you need a structured verdict across five quality dimensions before shipping.
• Via /mk:review for explicit invocation with options: branch diff (default), PR number (#123), commit hash, or --pending for uncommitted changes.

Key Capabilities

• Five review dimensions — every review evaluates Correctness, Maintainability, Performance, Security, and Coverage.
• Adversarial review architecture — multi-phase review with isolated reviewer subagents:
  • Phase A (3 parallel base reviewers): Blind Hunter (diff-only, no plan context), Edge Case Hunter (branch tracing, boundary analysis), Criteria Auditor (plan AC to implementation mapping).
  • Phase B (adversarial personas): Security Adversary + Failure Mode Analyst (full scope), Assumption Destroyer + Scope Complexity Critic (full scope, high-complexity only).
• Anti-rubber-stamp enforcement — zero findings triggers a mandatory re-analysis. Forces reviewers to look harder rather than approving by default.
• WARN justification — every WARN finding requires 3-part justification: what the WARN means, why it is acceptable, what would make it a FAIL. If the reviewer cannot articulate all three, WARN becomes FAIL.
• Scope-aware dispatch — classifies diffs as minimal (Blind Hunter only) or full (all reviewers + personas) based on scope.

Behavioral Checklist

• [x] Evaluates all five dimensions — never skips a dimension
• [x] Issues FAIL for unevaluated dimensions rather than silently skipping
• [x] Provides actionable feedback with suggested resolutions for every finding
• [x] Enforces 3-part WARN justification — incomplete justification becomes FAIL
• [x] Re-analyzes when zero findings are found (anti-rubber-stamp)
• [x] Distinguishes current-change findings (blocks shipping) from incidental ones (logged to backlog)
• [x] In TDD mode: coverage gaps are FAIL; in default mode: coverage gaps are WARN
• [x] Delegates to security agent for deep audit when security concerns are found

Five Review Dimensions

Dimension	What it checks
Correctness	No critical/major bugs. Logic matches requirements. Architecture fits existing patterns.
Maintainability	Clean, readable, follows conventions. No any types, no unsafe casts. Type safety enforced.
Performance	No N+1 queries, no blocking in async, no unnecessary re-renders, no unbounded data fetches.
Security	Security checklist compliance. Security BLOCK verdict from the security agent triggers automatic FAIL.
Coverage	Acceptance criteria covered by tests. Edge cases tested. Tests verify behavior, not implementation.

Verdicts

Verdict	Meaning	Effect
PASS	No blocking issues	Proceed to shipper (Phase 5)
WARN	Non-blocking suggestions	Proceed to shipper with acknowledged warnings
FAIL	Critical findings	Route back to developer — must fix before re-review

Skill Loading

Skill	When	Purpose
mk:review	Always (Phase 4)	Multi-pass adversarial review with step-file workflow
mk:scout	Complex changes (3+ files)	Edge case detection: dependents, data flow, async races
mk:elicit	After verdict, user-triggered	Structured second-pass reasoning via 8 methods
mk:cso	Security concerns found	Deep security audit delegation
mk:vulnerability-scanner	Security dimension flagged	Automated vulnerability detection

Pro Tips

Scope Reviews Strategically

Not every review needs the full adversarial architecture. Minimal diffs (small, well-scoped changes) get the Blind Hunter only, saving time and context. Full reviews activate all base reviewers plus adversarial personas. Let the scope gate make this determination automatically rather than manually choosing a review depth.

Combine with the Elicit Workflow

After a review verdict, you can invoke mk:elicit for structured second-pass reasoning. Choose from 8 methods (pre-mortem, inversion, red team, Socratic, etc.) to re-examine findings through a specific lens. This is particularly valuable for Complex tasks where the first review pass may not catch subtle architectural issues.

Key Takeaway

The reviewer ensures that no code ships without genuine quality verification across five dimensions. The adversarial architecture prevents the most common review failure mode — rubber-stamping — by using multiple isolated reviewers with different focus areas and mandatory re-analysis when zero findings emerge.

Related Agents

• developer — receives FAIL verdict with required changes; re-submits for re-review
• evaluator — complements the reviewer by verifying runtime behavior (reviewer = code quality, evaluator = product behavior)
• security — security BLOCK verdict automatically fails the Security dimension
• shipper — receives handoff after PASS or WARN verdict (Gate 2)
• tester — coverage adequacy check informs the Coverage dimension