Independently verify work handed from a Kanban implementation run to the review lane, then approve it, request changes, or escalate. This skill reviews the deliverable and its evidence; it does not take over the implementer's work.

Use this skill when all of the following are true:

Do not use it for a separate downstream review card. A downstream card is ordinary implementation work with a review-oriented specification and completes through its own lifecycle.

This skill is loaded automatically by the review dispatcher. Start with before inspecting files or choosing a verdict.

kanban_complete

kanban_comment

kanban_request_changes

kanban_block

A requested-changes transition returns the task to its original implementer. When that implementer requests review again without naming a reviewer, the persisted reviewer provenance routes the re-review back to the same reviewer profile.

Vary how you look at the work on each round instead of repeating the same inspection. Decorrelated lenses catch different defect classes: a cold read of the artifact surfaces design and correctness problems that the implementer's narrative would have framed away, execution surfaces claims that do not reproduce, and a strict contract audit surfaces quiet scope drift. Repeating the round-1 lens on round 3 mostly re-finds what round 1 already found.

Determine the current round from the history the task record already gives you: count the entries in the "Prior attempts on this task" section of your worker context (also visible as prior runs in ). The current review round is that count plus one. Round 1 therefore shows zero attempts; round 2 shows one; and so on.

terminal

kanban_request_changes

The baseline duties in the Procedure section still apply on every round; the lens sets which inspection you lead with and weight most heavily.

The same principle applies outside the Kanban review lane. When spawning multiple parallel reviewers via , give each reviewer a different lens — one diff-only brief, one full-context brief, one checkout-and-run brief — rather than identical briefs. Identical briefs produce correlated verdicts and duplicate findings; varied briefs cover more defect classes for the same review spend.

Call and identify:

Treat the handoff as a claim to verify, not as proof that the work is correct.

Map every acceptance criterion to concrete implementation or output evidence. Note omissions, changed semantics, and unrelated scope before deciding whether to run deeper checks.

For code work:

For non-code work:

Approve only when the acceptance criteria are satisfied and the evidence is sufficient. Call:

kanban_complete(
    summary="Reviewed and approved. <what was verified>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

Include the exact checks that passed and any bounded caveat that does not block acceptance.

Use this for specific, correctable defects. First record actionable findings:

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <file or artifact + defect>\n2. <required correction>",
)

Then return the same task to its implementer:

kanban_request_changes(
    reason="<concise summary of the required corrections>"
)

State where the defect is, how it reproduces, why it violates the task, and what minimum outcome would resolve it. The transition does not use blocker recurrence accounting.

Use escalation only when the reviewer and implementer cannot resolve the problem without a human decision or external prerequisite:

kanban_block(
    reason="escalation: <decision or prerequisite required>"
)

Explain the blocked decision and the smallest information needed to continue.

Do not edit the implementation while acting as reviewer. Request changes and let the implementer produce the next candidate; then independently verify that candidate in the next review run.

Before submitting the verdict, confirm: