review-quality

# Review Quality Framework This skill defines what a reviewer must verify before implementation work advances to completion. It applies whether the reviewer is the orchestrator directly or a delegated subagent. The review gate exists because implementation agents optimize for getting things working, not for verifying they built the right thing. Without a structured review checkpoint, planned work gets silently dropped, tests get written to pass rather than to verify, and unnecessary complexity accumulates. The review is where these failure modes get caught. **Critical separation of concerns:** The reviewer must not be the same agent that wrote the code or the tests. An agent reviewing its own work will rationalize rather than evaluate. The reviewer reads, runs, and reports — it never fixes. If issues are found, they go back to the implementation agent for resolution. This is the same principle the `needs-test-author` trait applies one step earlier, to test authorship itself — the test author must not be the implementer, for the same rationalize-not-evaluate reason. Verifying that separation actually held (see "Independence verification" in Area 3) is this rule applied to test authorship, not an optional extra. --- ## Getting Started The reviewer is given an MCP item ID. Use MCP tools and codebase access to gather what you need — do not expect context to be pre-loaded for you. 1. **Load the item's notes** — `query_notes(itemId=..., includeBody=true)` to retrieve the...