ln-12-delivery-reviewer
starsforks
How to install ln-12-delivery-reviewer?
levnikolaevich/claude-code-skills/ln-12-delivery-reviewer
$npx -y skills add levnikolaevich/claude-code-skills --skill ln-12-delivery-reviewerReviews a completed scoped change and its affected runtime and contract paths. Use to find change-caused defects and verify readiness; not for codebase audit, implementation, or repair.
SKILL.md
| 1 | # Delivery Reviewer |
| 2 | |
| 3 | **Goal:** Review only the requested delivery change and the causal runtime, contract, and data paths needed to prove its business outcome. Judge whether that scope meets acceptance and is safe to release; do not audit unrelated code, repair findings, update trackers, or widen scope. |
| 4 | |
| 5 | **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete. |
| 6 | Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every incomplete item. |
| 7 | |
| 8 | ## Tool Routing |
| 9 | |
| 10 | | Need | Preferred tool | Use it when | Fallback | |
| 11 | |---|---|---|---| |
| 12 | | Business scope, requirements, and repository rules | Native file read plus Git | Always establish the business outcome, acceptance boundary, non-goals, branch, comparison base, and working-tree state | User-provided requirements plus explicit limitations | |
| 13 | | Changed behavior | `git diff`, `git status`, and focused file reads | Establishing the exact implementation delta and affected entrypoints | Compare the supplied implementation against its stated baseline | |
| 14 | | Definitions, callers, consumers, and contracts | Language server or host-native code intelligence | Correctness of an affected path depends on unchanged symbols, routes, events, or public surfaces | Targeted search and direct inspection that stops when the affected causal path is proven | |
| 15 | | Build and automated verification | Repository-defined shell commands | The repository exposes build, lint, type, test, migration, or smoke commands | Inspect CI and scripts; mark execution as unverified | |
| 16 | | User-visible behavior | Browser, application client, API client, or runtime logs | Acceptance depends on rendered UI, interaction, protocol response, or observable runtime behavior | Static trace plus an explicit manual-verification requirement | |
| 17 | | External contracts and standards | Official vendor documentation, specifications, advisories, and release notes | A current external fact can change severity or correctness | Web research from primary sources; otherwise mark `UNVERIFIED` | |
| 18 | | Independent review | Native subagents with separate contexts | Every code-bearing review; assign one evidence lens per subagent and run independent passes in parallel | Return `BLOCKED` when required independent coverage has no credible replacement; never claim the panel ran | |
| 19 | |
| 20 | The delivery gate is intentionally stricter than plan review: independent code-review coverage cannot be simulated by self-review because acceptance depends on genuinely separate evidence passes. |
| 21 | |
| 22 | Use tools to answer specific evidence questions. A failed tool is a limitation, not a product defect. Never convert an unavailable build, advisor, browser, or documentation source into a failing finding without implementation evidence. |
| 23 | |
| 24 | ## Evidence Rules |
| 25 | |
| 26 | | Evidence | Weight | |
| 27 | |---|---| |
| 28 | | Reproduced behavior, failing test, compiler output, or deterministic command | Strongest evidence of current behavior | |
| 29 | | Changed code plus verified caller, consumer, schema, or configuration path | Strong static evidence | |
| 30 | | Acceptance criterion mapped to an implementation and verification result | Required delivery evidence | |
| 31 | | Official external contract matching the used version | Strong evidence for standards and compatibility | |
| 32 | | Pattern match, reviewer intuition, or generic best practice | Lead only until connected to a concrete failure or risk | |
| 33 | |
| 34 | A finding must name the affected business behavior, its causal link to the change, evidence, impact, and smallest credible correction. Do not report style preferences or unrelated repository health concerns. |
| 35 | |
| 36 | The review unit is the business change, not the repository. Reading unchanged code is permitted only to prove an affected path and never brings unrelated defects into scope. Verify every accepted claim against the implementation, executable behavior, or an authoritative contract. |
| 37 | |
| 38 | ## Independent Review Panel |
| 39 | |
| 40 | Use a Six Thinking Hats-inspired protocol to create genuinely different review questions. This is a code-review adaptation: hats are temporary evidence lenses, not personalities. The lead reviewer holds the Blue role by scoping the review, selecting agents, verifying their claims, resolving conflicts, and issuing the verdict. |
| 41 | |
| 42 | ### Agent Count and Hats |
| 43 | |
| 44 | Scale the panel to the risk and size of the change. For a small, low-risk change that activates no specialist risk trigger, spawn White and Black; add another canonical hat |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
