sdlc-review

Review Kanban handoffs and route verified outcomes to approval, changes, or escalation.

Updated Jul 3, 2026
One-click install
npx skills add https://github.com/CHENHUI-X/toolbox --skill sdlc-review-chenhui-x
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdlc-review
Source: https://github.com/CHENHUI-X/toolbox/tree/main/official-skills/devops/sdlc-review
Command: npx skills add https://github.com/CHENHUI-X/toolbox --skill sdlc-review-chenhui-x

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams running Kanban-based AI workflows need an independent reviewer to verify implementation handoffs before tasks complete, preventing rubber-stamped approvals and unverified claims from reaching done. ## Core Features & Use Cases - Independent Verification: Reads the task record via kanban_show, inspects the actual deliverable, and runs builds, tests, and linters before issuing a verdict. - Structured Verdicts: Routes each review to exactly one terminal action: kanban_complete for approval, kanban_request_changes for correctable defects, or kanban_block for escalations. - Round-Based Review Lenses: Varies inspection strategy per review round (artifact cold-read, execution-based, contract audit) to catch different defect classes across re-reviews. - Use Case: An implementer submits a review_requested handoff claiming a bug fix with passing tests; the reviewer checks out the code, runs the test suite, maps each acceptance criterion to evidence, and either approves with documented checks or returns actionable findings to the implementer. ## Quick Start Review the current Kanban task in the review lane by reading its handoff with kanban_show, verifying the deliverable against the acceptance criteria, and submitting an approve, request-changes, or escalate verdict.

Frequently Asked Questions about sdlc-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a Kanban task handoff before approving it?

Start with kanban_show to read the task specification, acceptance criteria, and latest review_requested handoff. Then inspect the actual deliverable, run relevant tests or builds, and map every acceptance criterion to concrete evidence before choosing a verdict.

What verdicts can a Kanban reviewer issue on a task?

A reviewer chooses exactly one terminal action: kanban_complete to approve with documented checks, kanban_request_changes to return correctable defects to the implementer, or kanban_block to escalate decisions requiring human input or external prerequisites.

How should re-reviews differ from first-round reviews?

Re-reviews use different lenses per round: round one reads the artifact cold, round two executes and tests the work empirically, and round three audits strictly against the original contract. Each re-review must also confirm prior requested changes actually landed.

When should a reviewer escalate instead of requesting changes?

Escalate with kanban_block only when resolution requires a human decision or an external prerequisite that neither reviewer nor implementer can provide. Correctable implementation defects belong in kanban_request_changes, not blocker transitions.

Can a reviewer edit the implementation to fix defects directly?

No. The reviewer must preserve role separation and never edit the deliverable. Instead, record actionable findings via kanban_comment and return the task with kanban_request_changes so the original implementer produces the next candidate.