Sdlc Review

SDLC Review Skill

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.

When to Use

Use this skill when all of the following are true:

• the dispatcher spawned you for a task claimed from the review lane;
• an implementer submitted a review_requested handoff;
• the task needs an independent verdict before it can be completed.

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.

Prerequisites

• A Kanban worker context with the current task and run identifiers.
• Native Kanban tools: kanban_show, kanban_comment, kanban_complete, kanban_request_changes, and kanban_block.
• Workspace access through read_file, search_files, and terminal when the deliverable is code.
• The task's original specification, acceptance criteria, handoff summary, and prior run history must be available through kanban_show.

How to Run

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

1. Read the task specification and the latest review_requested handoff.
2. Inspect the actual deliverable and run relevant verification.
3. Choose exactly one verdict: approve, request changes, or escalate.
4. Record concrete evidence in the terminal Kanban transition.

Quick Reference

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.

Review Lenses

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 changes_requested entries in the "Prior attempts on this task" section of your worker context (also visible as prior runs in kanban_show). The current review round is that count plus one. Round 1 therefore shows zero changes_requested attempts; round 2 shows one; and so on.

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

Lens variation for ad-hoc review fan-outs

The same principle applies outside the Kanban review lane. When spawning multiple parallel reviewers via delegate_task, 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.

Procedure

1. Orient from the durable task record

Call kanban_show and identify:

• the original task body and acceptance criteria;
• the latest implementation summary and structured metadata;
• changed files, commit identifiers, and test evidence;
• comments and decisions from earlier runs;
• findings from prior review rounds.

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