QA Release Sign-off Skill

A release sign-off turns "QA says it's fine" into an evidence-based decision: here's what we tested, here's what passed and what's still open, here's the risk, and here's the recommendation. This skill produces that report so the go/no-go is accountable — and so anyone reading it later knows exactly what shipped and what didn't.

Working from a brief

Given test results and a list of open bugs, produce the sign-off anyway — organise the evidence, weigh the open defects, and make a clear recommendation with conditions, marking anything unverified (confirm). Never invent test results or pass rates; if coverage is thin, say so as a risk.

Required Inputs

Ask for these only if they aren't already provided (else mark unknown / as a risk):

• The release — what's shipping (version/scope) and the target date.
• Testing done — what was tested (areas, types), results/pass rate, and what wasn't covered.
• Open defects — known bugs with severity, and any with workarounds.
• Risk & ops — known risks, rollback/feature-flag availability, and any acceptance criteria/exit gates.

Output Format

QA Sign-off: [release] — [date]

• Recommendation — Go / Go with conditions / No-go, in one line, up front, with the headline reason.
• Scope — what's in this release.
• Testing summary — what was tested (areas + test types), results (pass/fail, pass rate), and what was not tested.
• Open defects — a table by severity, with impact and any workaround:

ID	Severity	Area	Impact	Workaround	Blocker?

• Coverage & residual risk — what's well-covered vs. thin, and the honest risk of shipping now.
• Conditions to ship (if "go with conditions") — what must be true/fixed/monitored before or right after release.