Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-12-delivery-reviewer
Reviews 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.
0 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 1 comparable cases; this report requires 8.
The instructions your model reads when the skill loads.
Goal: Review only the requested delivery change and the causal paths needed to prove its business outcome. Judge scoped acceptance and release safety with concise evidence; do not audit unrelated code, repair findings, update trackers, or widen scope.
Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
| Need | Preferred capability | Use when | Fallback |
|---|---|---|---|
| Scope and repository state | Native file reads plus Git | Establishing outcome, non-goals, base, head, and worktree | Supplied requirements with explicit limitations |
| Changed behavior | Diff, status, and focused reads | Resolving the implementation delta and entrypoints | Compare supplied artifacts with their stated baseline |
| Definitions and consumers | Code intelligence | An affected path depends on unchanged symbols or contracts | Targeted search that stops when the causal path is proven |
| Automated verification | Repository-defined commands | Build, lint, type, test, migration, or smoke gates exist | Inspect scripts and CI; mark execution UNPROVEN |
| Observable behavior | Browser, client, or runtime evidence | Acceptance depends on UI, interaction, protocol, or logs | Static trace plus an exact manual check |
| Reuse and correction research | Installed manifests plus current official documentation, specifications, and package sources | A changed generic mechanism needs a reuse decision, external behavior affects correctness, or an externally dependent correction needs verification | Reputable primary engineering material; otherwise mark the decision or correction UNVERIFIED |
| Independent review | Native subagents in separate contexts | An unresolved distinct risk warrants independent evidence | Linked panel protocol; otherwise direct review with independence limits |
Use tools only for the current evidence question. Tool failure is a limitation, not a defect. Do not convert an unavailable command, runtime, or source into a finding without implementation evidence.
| Evidence | Weight |
|---|---|
| Reproduced behavior, failing test, compiler output, or deterministic command | Strongest current-behavior evidence |
| Changed code plus verified caller, consumer, schema, or configuration path | Strong static evidence |
| Acceptance criterion mapped to implementation and verification | Required delivery evidence |
| Official external contract matching the used version | Strong compatibility evidence |
| Pattern, intuition, or generic practice | Lead only until tied to a concrete failure or risk |
Apply the finding fields in Output Contract. Repository evidence establishes the defect; external guidance supports corrections and cannot invent local requirements. The review unit is the business change, not the repository. Read unchanged code only to prove an affected path; do not report style preferences or unrelated repository health.
The lead owns scope, evidence, and verdict. Use no panel when direct evidence suffices or the user excludes delegation. When a distinct unresolved risk warrants independent review, read the panel protocol before selecting or launching reviewers; it owns lens selection, frozen context, round limits, retries, and result handling. Missing independence is a limitation unless it leaves essential evidence unproven.
test cases passed with the skill
More skills from the same source and nearby in the registry, with their headline benchmark lift.