recipes
0/4 steps
Tutorial V6 · 6 minutes

Release validation

One release candidate, one team's changes, one report. For leads and QA deciding whether a build is ready for sign-off.

skill not merged yet maturity: experimental
V6

Video recording in progress

Status: shipping, not yet merged

Like V5, this skill lives on a branch rather than the skills repo's main branch. No install command here until it lands.

V5 reviews one pull request head. This sits a layer above: it takes the team's changes that actually shipped into one frozen release head and validates their assembled flows on that build.

The flow

  1. Two things, both exact

    One release target — a release/X.Y.Z ref, its release pull request, or an unambiguous version — and one team scope, given as explicit pull request URLs, owned paths, release labels, or a repository team definition. Ambiguity in either is refused rather than guessed, because a report scoped to the wrong changes is worse than no report.

  2. Criteria assembled across the release

    It reuses the same acceptance-criteria contract as PR review, then combines the criteria from every in-scope change into the user flows they add up to on the release build. A flow can break from the interaction of two individually correct changes; that is the class of problem this catches and per-PR review cannot.

  3. Four verdicts, not two

    VerdictMeans
    PASSDemonstrated on the release build, with evidence.
    FAILExercised and did not hold. A real result.
    UNTESTABLEThe surface cannot demonstrate it. Needs a human.
    NOT RUNIn scope, not attempted. Stated rather than omitted.

    NOT RUN is the one that keeps the report honest. A run that skipped something says so, instead of leaving a silent gap that reads as coverage.

  4. Ready for sign-off, which is not sign-off

    A first autonomous release QA result, not an approval. The report frames itself as ready for team QA sign-off. The sign-off is still a person's, and the report is the evidence they read to give it.

    What changes is where the human starts: from a report with per-criterion verdicts and evidence paths, rather than from a build and a list of tickets.

Next: a ticket end to end → Back to the series