Appropriate use
Use for release candidates, scheduled deployments, platform releases, or coordinated changes spanning several tickets.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to approve an unverified build, hide missing coverage, replace business ownership of accepted risk, or bypass incident and security processes.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 5
- defined result states
- 10
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Release candidate attestation Gate 1 · approve candidate
Resolve the release ID, artifact digests, source commits, included tickets, configuration, migrations, rollout controls, target environments, and rollback artifact.
release manifest · ticket set · artifacts · config · rollback
Phase 2: Evidence aggregation
Collect version-bound feature QA, smoke, regression, fix verification, automation, security, accessibility, performance, and platform results.
source reports · report hashes · freshness · environment match
Phase 3: Coverage and gap analysis
Map required release criteria to evidence, identify not-tested platforms and scenarios, expired results, conflicting verdicts, and missing owners.
required criteria · covered · missing · stale · conflicting
Phase 4: Defect and risk review
Review unresolved defects, severity, release-blocking flags, workarounds, customer exposure, data risk, monitoring ability, and rollback impact.
blockers · accepted risks · owners · expiry · mitigations
Phase 5: Operational readiness
Verify deployment plan, staged rollout, observability, alert thresholds, support readiness, communication, rollback conditions, and decision ownership.
rollout stages · metrics · rollback · support · comms
Phase 6: Recommendation calculation
Apply ordered policy to candidate integrity, release-blocking defects, required coverage, blocked evidence, accepted optional risk, and operational readiness.
invalid · reject · blocked · conditional · pass
Phase 7: Release review Gate 2 · approve release decision
Present the calculated recommendation, evidence matrix, known gaps, risk owners, rollout conditions, and rollback triggers. Manual overrides remain separate.
calculated outcome · override · approver · reason
Phase 8: Publish sign-off and monitoring handoff Gate 3 · publish sign-off
Publish one immutable sign-off record, create the rollout monitoring handoff, and invalidate the decision if the candidate or release configuration changes.
sign-off ID · release hash · monitoring owner · expiry
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve candidate | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve release decision | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish sign-off | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
PASS
All required criteria are satisfied for the verified candidate.
CONDITIONAL PASS
Required criteria pass, with explicitly accepted optional risk or staged conditions.
BLOCKED
Required evidence, environment, approval, or operational readiness is incomplete.
REJECT
A release-blocking product, security, data, or compliance issue remains.
INVALID CANDIDATE
The candidate identity or evidence binding cannot be trusted.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Candidate | Signed release manifest | All artifacts, configuration, migrations, and rollback versions are identified. |
| Ticket coverage | Traceability matrix | Every included ticket has a current outcome or explicit exclusion. |
| Defects | Open-defect register | Severity, release-blocking status, owner, and workaround are current. |
| Platforms | Coverage matrix | Supported platforms not tested are explicit. |
| Operations | Rollout and rollback plan | Thresholds, owners, and commands or procedures are verified. |
| Monitoring | Dashboard and alert references | Signals can detect the expected failure modes during rollout. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No evidence laundering
A summary cannot turn stale, blocked, or mismatched reports into a pass.
Runtime control
Candidate immutability
Any artifact, config, migration, or ticket-set change invalidates sign-off.
Runtime control
Ordered policy
Invalid candidate and release blockers take precedence over aggregate pass counts.
Runtime control
Override separation
Business acceptance never rewrites the calculated QA recommendation.
Runtime control
Risk ownership
Every accepted risk has an authorised owner, reason, mitigation, and expiry.
Runtime control
Operational coupling
A technically correct build remains blocked when rollback or monitoring is inadequate.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
INVALID CANDIDATE
Candidate identity or evidence binding is invalid.
REJECT
An unresolved release-blocking risk exists.
BLOCKED
Required evidence or operational readiness is missing.
CONDITIONAL PASS
Required criteria pass under explicit conditions and accepted risk.
PASS
All required technical and operational criteria pass.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. A QA pass is not a business command to release.
- Limit 2. Release evidence may become stale when configuration or dependencies change.
- Limit 3. A staged rollout still requires explicit thresholds and rollback ownership.
- Limit 4. Low-frequency severe failures may outweigh broad pass counts.
- Limit 5. Third-party release windows and store approvals can affect readiness.
- Limit 6. Post-release monitoring is part of release control, not proof that pre-release testing was unnecessary.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
release-context.jsonVersioned output produced by the workflow.
release-manifest.jsonVersioned output produced by the workflow.
evidence-index.yamlVersioned output produced by the workflow.
coverage-matrix.csvVersioned output produced by the workflow.
defect-register.yamlVersioned output produced by the workflow.
risk-acceptance.jsonlVersioned output produced by the workflow.
rollout-plan.mdVersioned output produced by the workflow.
release-decision.jsonVersioned output produced by the workflow.
sign-off.mdVersioned output produced by the workflow.
release-report.htmlVersioned output produced by the workflow.
artifacts/qa/release-qa/<run-id>/ ├── release-context.json ├── release-manifest.json ├── evidence-index.yaml ├── coverage-matrix.csv ├── defect-register.yaml ├── risk-acceptance.jsonl ├── rollout-plan.md ├── release-decision.json ├── sign-off.md └── release-report.html
Example
Example request and controlled output
Input
Prepare QA sign-off for Android Player 4.11.5. Include tickets QA-5501 to QA-5512, open defects, staged rollout thresholds, and rollback readiness.
Output excerpt
Release recommendation: CONDITIONAL PASS Conditions: - Start at 1%. - Hold each stage for at least four hours. - Roll back if playback-start failures exceed baseline by 0.5 percentage points. - Keep QA-5510 accepted as a low-impact screenshot latency issue until 20%. Candidate: Artifact and source manifest verified. Required coverage: All P0 and P1 release criteria passed.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/release-qa
Combines ticket-level results, open defects, platform coverage, rollout safeguards, monitoring, rollback readiness, and accepted risk into one auditable release recommendation.