sdlc-review

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

Updated Oct 16, 2025
One-click install
npx skills add https://github.com/hugotown/dotfiles --skill sdlc-review-hugotown
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdlc-review
Source: https://github.com/hugotown/dotfiles/tree/main/hermes/skills/devops/sdlc-review
Command: npx skills add https://github.com/hugotown/dotfiles --skill sdlc-review-hugotown

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When an implementer hands work off for review in a Kanban workflow, someone must independently verify the deliverable against the original acceptance criteria instead of rubber-stamping the handoff summary. This Skill provides a structured review procedure that produces a single evidence-backed verdict. ## Core Features & Use Cases - Independent verification: Reads the task record with kanban_show, inspects the actual deliverable, and runs builds, tests, and lint checks before deciding. - Round-based review lenses: Rotates between artifact, execution, and contract lenses across review rounds so repeated reviews catch different defect classes. - Three terminal verdicts: Approves with kanban_complete, returns correctable defects with kanban_request_changes, or escalates human decisions with kanban_block. - Use Case: An implementer submits a review_requested handoff claiming a bug fix passes tests. The reviewer checks out the change, runs the test suite, maps each acceptance criterion to evidence, and either approves with a concrete summary or sends back specific, reproducible findings. ## Quick Start Ask the agent to review the current Kanban task in the review lane by reading the handoff with kanban_show, verifying the deliverable, and recording a 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 handoff before approving it?▼

Start with kanban_show to read the task specification, acceptance criteria, and the latest review_requested handoff. Then inspect the actual deliverable, run relevant tests or builds, and record exactly one verdict: approve, request changes, or escalate.

How do I request changes on a Kanban task as a reviewer?▼

First call kanban_comment with specific, reproducible findings stating the defect location, how it reproduces, and the required correction. Then call kanban_request_changes with a concise reason, which returns the task to its original implementer.

When should a reviewer escalate instead of requesting changes?▼

Escalate with kanban_block only when a human decision or external prerequisite is required, such as an unresolved design decision. Correctable implementation defects belong in kanban_request_changes, not blockers.

Can a reviewer edit the implementation to fix defects directly?▼

No. The skill enforces role separation: reviewers must not edit the deliverable. Instead, request changes and let the implementer produce the next candidate, then independently verify that candidate in the next review round.

How do repeated review rounds avoid missing the same defects?▼

Each round applies a different lens: round 1 reads the artifact cold, round 2 executes and tests the work, and round 3+ audits strictly against the original acceptance criteria. The round number is derived from prior changes_requested entries in the task history.