delivery-audit

Audit completed spec deliveries against diffs, tests, and completion ledgers to produce verdict reports.

Updated Apr 20, 2026
One-click install
npx skills add https://github.com/astroville/sprout --skill delivery-audit-astroville
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: delivery-audit
Source: https://github.com/astroville/sprout/tree/main/.claude/skills/delivery-audit
Command: npx skills add https://github.com/astroville/sprout --skill delivery-audit-astroville

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering teams marking specs as complete often rely on self-reported completion ledgers from the same agent that did the work, which invites performative claims and unchecked PARTIAL rows. This Skill provides an independent cold audit that verifies each acceptance criterion against real diff and test evidence before a spec flips to completed. ## Core Features & Use Cases - Evidence-based verification: Maps every acceptance criterion and Changes item to concrete diff hunks, test assertions, and file paths, downgrading DONE rows that lack evidence. - Structured verdict output: Produces a durable delivery-audit.md report on disk plus a machine-readable verdict block (SHIP or HOLD, clean or noteworthy) for the orchestrator. - PARTIAL and skip scrutiny: Assesses whether SKIPPED or BLOCKED reasons are concrete or vague, flagging soft skips that should block delivery. - Use Case: After a feature-delivery workflow finishes, invoke this auditor with the spec path, a git diff command, and the completion ledger to get an honest what-landed report before merging. ## Quick Start Ask the auditor to cold-audit the completed spec at a given path using a specified git diff command and the pasted completion ledger, then read the generated delivery-audit report.

Frequently Asked Questions about delivery-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a spec was actually delivered before marking it complete?▼

Run a cold audit that maps each acceptance criterion to diff evidence and test assertions. The auditor checks every DONE row against real code changes and produces a SHIP or HOLD verdict with a written report.

What inputs does a delivery audit need to run?▼

The audit requires four inputs: the absolute spec file path, an exact git diff command, the engineer's completion ledger pasted verbatim, and test evidence or an explicit statement that none exists. Missing inputs halt the audit.

How is a delivery audit different from a code review?▼

A delivery audit checks whether the work matches the spec's claims, not code quality. It does not hunt bugs, critique architecture, or run functional tests; it verifies that claimed completions have real evidence.

What happens when a DONE row has no supporting evidence?▼

The row is downgraded to a performative claim and marked with no evidence found. Any downgraded row forces a HOLD verdict and a noteworthy surface level so the orchestrator routes it back to the engineer.

When should a delivery audit return HOLD instead of SHIP?▼

HOLD applies when any row lacks evidence or when PARTIAL rows have vague reasons like low priority. The auditor defaults to HOLD when uncertain because a false SHIP costs more than a false HOLD.