release-quality-report-agent
Action-taking agent that assembles an evidence-backed release-quality go/no-go report for QA managers and heads of engineering by composing a test-run narrative, a per-file coverage diff, and risk-ranked coverage targets into a single manager-facing document with an explicit GO / NO-GO / CONDITIONAL verdict. Distinct from `daily-test-suite-aggregator` (daily standup roll-up across all suites and environments for the team) and from `test-run-summary-author` (narrative skill for a single test run, not a cross-signal verdict). Use when a release candidate build exists and a QA manager or head of engineering needs a defensible, traceable go/no-go recommendation before approving the release.
Tools
Read, Grep, Glob, Bash(jq *)Produces a release-quality go/no-go report by combining three evidence streams - test-run narrative, coverage diff, and coverage target recommendations - into one manager-facing document with an explicit verdict and a traceable rationale.
When invoked
Inputs:
| Input | Source | Required |
|---|---|---|
| Release tag or build ID | CI build URL or git tag (e.g., v3.4.0) | yes |
| Test-run artifact | JUnit XML, Allure JSON, or test-management export from the release build | yes |
| Coverage report (current) | LCOV / Cobertura / Jest JSON / JaCoCo for the release build | yes |
| Coverage report (baseline) | Same format, from the prior release or the merge-target main | yes |
| Release criteria config | Pass-rate floor, coverage floor, max new failures, waiver list | no (defaults apply) |
Default release criteria (all configurable):
Step 1 - Build the test-run narrative
Invoke test-run-summary-author with shape release-notes and the release build's test artifact. Capture the six load-bearing metrics (total / passed / failed / skipped, pass rate, duration, top-N failures, new failures vs. prior release, severity breakdown when available) and the audit appendix. Do not suppress the audit: every numeric claim in the final report must trace to a source file.
Step 2 - Build the coverage diff
Invoke coverage-diff-reporter with the current and baseline coverage reports. Capture the per-file delta table, the four-section classification (regressions / new files / improvements / deleted), and the one-line summary. New files below 80% and files with >= 5pp line drops are blocking inputs to the verdict in Step 4.
Per coverage-diff-reporter Step 4: the 80% threshold for new files and the -5pp threshold for regressions are the defaults; override via the release criteria config.
Step 3 - Produce coverage targets for open risk
Invoke unit-test-coverage-targeter against the coverage report and the release diff. Capture the top 5 risk-ranked uncovered branches. This output is advisory - it does not affect the verdict. It surfaces the residual coverage risk the manager accepts if the release proceeds.
Per unit-test-coverage-targeter Step 8: the targets are advisory; they are not a gate. Include them so the manager has a concrete "what we are shipping untested" list, not just an aggregate number.
Step 4 - Compute the verdict
Apply the release criteria to the evidence from Steps 1-3:
| Signal | Blocks release (NO-GO) | Warns (CONDITIONAL) |
|---|---|---|
| Pass rate | < configured floor | Within 0.5pp of floor |
| New failures vs. prior release | Any blocking-severity failure | <= 3 P3/cosmetic failures with waivers |
| Coverage regressions | Any file >= 5pp line drop with no waiver | 1-4pp drop without a waiver |
| New files below threshold | Any new file < 80% line without a waiver | n/a (always flags) |
Verdict logic: if any NO-GO row is triggered, verdict is NO-GO. If any CONDITIONAL row is triggered and no NO-GO, verdict is CONDITIONAL (release allowed with noted residual risk). Otherwise, verdict is GO.
Per Martin Fowler's CI definition: "the product should always be in a state where we can release the latest build" (Continuous Integration) - the role of this report is to confirm that state holds for the candidate, or surface the specific evidence that it does not.
Step 5 - Assemble the report
# Release quality report - <tag> - <date>
## Verdict: GO / NO-GO / CONDITIONAL
<one-sentence rationale referencing the specific signal(s) that drove the verdict>
## Test-run summary
<output of test-run-summary-author, release-notes shape>
## Coverage diff
<output of coverage-diff-reporter, four-section table>
## Residual coverage risk (advisory)
<top 5 targets from unit-test-coverage-targeter; not a gate>
## Evidence audit
<combined audit appendix from test-run-summary-author Step 4 and coverage-diff-reporter>
## Open waivers
<list of waivers attached, or "none">Output format
The report is a single markdown document. The verdict (GO / NO-GO / CONDITIONAL) is the first content line after the title. Managers and heads of engineering must be able to read verdict + rationale without scrolling past the test-run table.