Release Readiness Audit

What It Does

Release Readiness Audit guides AI agents through a structured, evidence-based audit before tagging a release. It verifies that every ticket in a milestone is genuinely implemented in merged code (not just closed), that documentation exists and is reachable from where users actually look, that CI is green across all workflow matrix platforms, and that coverage gates pass.

The audit produces a structured pass/fail report broken down by ticket, layer, and gate.

Workflow

1. Map release scope from a tracking issue or milestone — classify each sub-ticket as feature, dependency bump, or hotfix
2. Three-layer evidence check per feature ticket: source implementation, test coverage, and doc discoverability
3. CI verification via gh run list / gh run view — never local test runs
4. Doc discoverability check — confirms docs are linked at the point-of-action, not buried in a flat index
5. Gate checklist — explicit grep/file check per gate, not inferred from ticket close status

Example Use Cases

• Auditing a v2.0 milestone before tagging
• Cross-checking a tracking issue before a production deploy
• Confirming CI is green on all platforms (Linux, macOS, Windows) before a release
• Verifying that new modules have reference docs and changelog entries

Sample Output

Release Readiness Report — v2.1.0

[PASS] #42 — Stripe adapter: source present, tests cover all exports, docs linked from README
[PASS] #44 — CI matrix: Linux / macOS / Windows all green
[FAIL] #43 — Webhook events guide: file exists but NOT linked from point-of-use in README
[SKIP] #45 — Dependency bump: no feature check needed

Verdict: NOT READY — 1 gate failing (doc discoverability)

Requirements

• GitHub CLI (gh) authenticated to the target repository
• Read access to the repository (issues, PRs, CI runs)
• Works with TypeScript, Python, and Go projects out of the box; adaptable to any stack with standard CI

Release audit workflow

Release Readiness Audit guides AI agents through a structured, evidence-based audit before tagging or shipping a release. It verifies that every ticket in a milestone is genuinely implemented in merged code, that documentation is discoverable from where users actually look, that CI is green across all required platforms, and that release gates such as coverage, security, rollback, and version consistency are satisfied.

Core audit stages

• map release scope from a tracking issue or milestone
• verify implementation evidence per ticket across source, tests, and docs
• verify CI from platform evidence, not local wishful thinking
• check documentation discoverability, not just file existence
• produce a structured release-readiness verdict with concrete action items

Documentation lookup policy

• Context7: use proactively when a release gate depends on third-party library/API docs, setup requirements, configuration expectations, or migration guidance.
• Astro Docs MCP: if the release is Astro-specific, use it first for Astro APIs, integrations, setup, config, import paths, and version-specific behavior when it is available.
• Official live web sources via search/fetch: still use these for freshness-sensitive public facts such as latest versions, release dates, deprecations, migration notes, CVE advisories, or current support status.
• Fallback order: MCP docs first for structured reference; official live web sources via search/fetch second for freshness; repository docs, lockfiles, CI state, and source evidence for project-specific truth.

What the package includes

This download packages the audit skill layer and its evidence-driven release methodology. It does not depend on a hosted service to install. In practice, many audits will also rely on repository access and optional tools like GitHub CLI or CI metadata, but those are runtime evidence sources, not install-time requirements for the download package.