Reviewer

Overview

The Reviewer is the quality gatekeeper. It verifies that every implementation meets requirements, follows security standards, and satisfies the Definition of Done. No code passes through the pipeline without the Reviewer's assessment — it catches what automated tests miss.

When It's Used

Invoked during /dr-qa — the quality assurance stage that follows implementation. The Reviewer examines code changes against the task definition, checks security compliance, and validates that all DoD criteria are met.

Capabilities

• Code review — examines implementation for correctness, readability, and adherence to project standards
• Security compliance — checks for vulnerabilities, injection points, authentication issues, and data exposure
• Definition of Done validation — verifies each DoD criterion from the task plan is satisfied
• Acceptance recheck — independently rechecks every due acceptance case against current evidence and returns discrepancies to their source stage; a green test suite alone is not acceptance
• Spec-graph gate (QA Layer 3c) — runs the automatic spec-graph gate, reports evaluated artifacts and trace buckets, and fails closed on adapter exit 2
• Reflection updates — documents findings in datarim/reflection/*.md for future learning

How It Works

The Reviewer reads the task definition (including the DoD) and the style guide, then systematically examines the implementation. It applies security checks from the security skill and testing patterns from the testing skill. Each finding is categorized by severity. The review produces a clear pass/fail verdict with specific items to fix if needed.

Example

/dr-qa
→ Reviewer reads tasks.md (DoD: 5 criteria)
→ Code review: 2 issues found (missing input validation, unclear naming)
→ Security check: 1 finding (SQL parameters not parameterized)
→ DoD validation: 4/5 criteria met
→ Verdict: FAIL — 3 items to fix
→ Updates reflection/reflection-<TASK-ID>.md

Context Loading

Reads datarim/tasks.md (for DoD) and datarim/style-guide.md. Applies security (loaded before any source read), immutability, testing, datarim-system and cta-format skills on every invocation; a blocked verdict uses the fail-routing Next Step variant.

Skills Used

security (always), immutability (always), testing (always), datarim-system (always), cta-format (always).

Reporting the result

Apply Human Outcome Reporting before a human-facing update or result. Explain the user-visible outcome, the original conditions, checks and evidence, and open limitations. A stage result does not mean the entire task is complete. Keep exact protocols and technical records intact. To explain again without continuing work, use /dr-explain.