sdlc-review

Verify Kanban implementation handoffs and route review verdicts through approve, request-changes, or escalate transitions.

Updated Sep 20, 2026
One-click install
npx skills add https://github.com/GreenyZA/neo-light --skill sdlc-review-greenyza
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdlc-review
Source: https://github.com/GreenyZA/neo-light/tree/main/.hermes-home/skills/devops/sdlc-review
Command: npx skills add https://github.com/GreenyZA/neo-light --skill sdlc-review-greenyza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Work handed off from a Kanban implementation run needs independent verification before it can be marked complete, and rubber-stamping handoff summaries lets defects slip through. This Skill gives a reviewer agent a structured procedure to verify deliverables against acceptance criteria and record an evidence-backed verdict. ## Core Features & Use Cases - Independent verification workflow: Reads the durable task record via kanban_show, maps every acceptance criterion to concrete evidence, and inspects the actual deliverable rather than trusting the handoff narrative. - Round-based review lenses: Rotates between artifact, execution, and contract lenses across review rounds so repeated reviews catch different defect classes instead of re-finding the same issues. - Three terminal verdicts: Approves with kanban_complete, returns correctable defects with kanban_request_changes after a kanban_comment, or escalates human decisions with kanban_block. - Use Case: An implementer finishes a bug fix and requests review; the reviewer checks out the branch, runs the project's tests, confirms the fix and one control path, then approves with a summary naming the exact checks performed. ## Quick Start Ask the agent to review the task currently in the Kanban review lane and issue an approve, request-changes, or escalate verdict with supporting evidence.

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 verification, and issue exactly one verdict: kanban_complete, kanban_request_changes, or kanban_block.

What is the difference between requesting changes and blocking a Kanban task?▼

Requesting changes via kanban_request_changes handles specific, correctable implementation defects and returns the task to its original implementer. Blocking via kanban_block is reserved for genuine external blockers or decisions that require a human, not ordinary rework.

How do review rounds work when a task is re-submitted?▼

The current round equals the count of prior changes_requested entries plus one. Round 1 uses an artifact lens, round 2 uses an execution lens where you run the work yourself, and round 3 or later uses a contract lens auditing strictly against the original acceptance criteria.

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

No. The reviewer must preserve role separation and never edit implementation files. Defects are recorded as actionable findings in a kanban_comment, then the task returns to the implementer who produces the next candidate for independent re-review.

When should this review skill not be used?▼

Do not use it for a separate downstream review card, which is ordinary implementation work with a review-oriented specification that completes through its own lifecycle. It only applies when a dispatcher spawns you for a task claimed from the review lane with a review_requested handoff.