One-click install
npx skills add https://github.com/NousResearch/hermes-agent --skill sdlc-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdlc-review
Source: https://github.com/NousResearch/hermes-agent/tree/main/skills/devops/sdlc-review
Command: npx skills add https://github.com/NousResearch/hermes-agent --skill sdlc-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Software teams need an independent verifier between implementation and completion to catch defects, prevent rubber-stamping, and maintain clear ownership boundaries across review rounds.

Core Features & Use Cases

  • Independent Verification: Inspect deliverables against acceptance criteria using artifact, execution, and contract lenses that vary by review round.
  • Structured Verdicts: Route outcomes through approve, request changes, or escalate transitions with concrete evidence recorded in metadata.
  • Use Case: An implementer submits a feature branch for review. The reviewer checks out the code, runs the test suite, audits against the original spec, and either approves with documented checks or returns specific actionable defects to the implementer.

Quick Start

Review the current Kanban task in the review lane, inspect the deliverable against acceptance criteria, and submit exactly one verdict using kanban_complete, kanban_request_changes, or kanban_block.

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 independently?

Start with kanban_show to read the task specification and handoff summary, then inspect the actual deliverable using read_file, search_files, and terminal. Map every acceptance criterion to concrete evidence before choosing a verdict.

What is the difference between request changes and escalate in Kanban review?

Use kanban_request_changes for correctable implementation defects the implementer can fix. Reserve kanban_block for situations requiring a human decision or external prerequisite that the reviewer and implementer cannot resolve.

How to vary code review lenses across multiple rounds?

Apply the artifact lens on round 1 by reading the diff cold before the implementer's summary. Use the execution lens on round 2 by checking out and running the code. Switch to the contract lens on round 3+ by auditing strictly against original acceptance criteria.

Why does code review produce correlated findings across reviewers?

Identical review briefs produce correlated verdicts because reviewers apply the same inspection pattern. Vary the lens per reviewer—one diff-only, one full-context, one checkout-and-run—to cover more defect classes for the same review spend.

When should a reviewer not edit the implementation?

Reviewers must never edit implementation files because doing so hides ownership and weakens the re-review boundary. Request changes and let the implementer produce the next candidate, then independently verify that candidate in the next review run.