A release needs a receipt that says what is actually live
Connect the intended source, current live state, required gates, deployed components, and observed behavior in a dated release report.
Where it came from: Historical Portravo releases required fresh live-source ancestry, paired app/compute source, migration and idle-state gates, and public health verification. Current Portravo and Soxoa receipts retain source identity, check results, observed behavior, and configuration-preservation evidence. The portable skill deliberately uses each project's declared rules and grants no mutation authority.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Current project release policy
- Candidate source or artifact identity
- Live version and health endpoints
- Test results and deployment evidence
- Authorized configuration and migration metadata
You get back
- Readiness verdict or post-release receipt
- Evidence-linked gates table
- Source and component identity verification
- Explicit unresolved checks and next action
The build succeeds, the deployment command exits, and the homepage loads. Someone asks whether the change is live. The honest answer depends on what those three observations actually establish.
Across our product releases, the useful record became a dated receipt connecting the intended source, required checks, deployed components, and observed public behavior. It made later reviews much easier because the evidence traveled with the conclusion.
The verify-release-readiness Claude skill draft packages that review method. It can assess a candidate release or inspect evidence from a completed rollout. The new package has not been behaviorally tested in Claude, and running the review gives it no authority to deploy.
Tie each check to the source being released
Test results are useful when they identify what was tested. A passing suite from yesterday's commit may leave today's change unexamined. A clean build can package a branch that lacks a fix already serving customers.
The review therefore starts with source identity. It records the candidate, the current live version, the repository context, and any ancestry requirement in the project's release policy. It also checks whether local changes make the intended artifact ambiguous.
This is particularly useful when several agents or people can release the same product. The branch that was current at the start of a task can be behind production by the time a build finishes. A fresh check closes that gap before anyone makes a release decision.
Verify the system's actual compatibility rule
An application may depend on a separate worker, container, or processing service. Some systems require both components to run the same source revision. Others deliberately release them independently through compatible interfaces.
The skill reads the project's rule and checks evidence against it. It should never invent a same-commit requirement for every architecture. Where exact pairing is required, observing only the app leaves half the release unverified.
Data changes create another dependency. A migration plan needs to be compared with the current migration ledger. A candidate can contain an apparently new migration whose identifier was used by another release. Readiness review should expose the collision before deployment, while leaving the database unchanged.
Separate evidence levels in the receipt
An illustrative release table might look like this:
| Check | Evidence | Conclusion |
|---|---|---|
| Intended source | Public version response matches candidate | Source observed at that endpoint |
| Required tests | Results tied to candidate | Declared test scope passed |
| App and processor | Both report the required revision | Pairing rule satisfied |
| Configuration | Binding names and types match | Metadata preserved |
| Purchase workflow | No transaction exercised | Commerce outcome remains unverified |
That last row is useful. A receipt becomes misleading when it turns a health check into an end-to-end business claim. Likewise, preserved binding metadata cannot prove that secret values are unchanged or that a fresh application request used them.
A known baseline test failure should remain visible too. Reproducing it on unchanged code can support an assessment of relevance, but the suite still contains a failure. Accurate wording preserves the distinction.
Ask for a readiness report before the release decision
Use a request such as:
Use verify-release-readiness to review this candidate against our current release policy. Compare it with the live source, map required checks to their evidence, and identify unresolved component, migration, runtime, and behavior gates. Use read-only access. Return a dated report with a clear boundary between readiness and authorization.
Supply the candidate identity, live endpoints, project instructions, and available test or deployment records. If a required gate needs access Claude does not have, the report should name the gap. Missing in-flight job data cannot become an assumption that the system is idle.
A person responsible for the release still makes the deployment decision and manages recovery. The skill's job is to make that decision reviewable. Start by applying it to one completed release and check whether its receipt could explain the rollout to someone who missed the conversation.
Use verify-release-readiness to review this candidate against our current release policy. Compare it with the live source, map required checks to their evidence, and identify unresolved component, migration, runtime, and behavior gates. Use read-only access. Return a dated report with a clear boundary between readiness and authorization.
/plugin marketplace add johnarndt/john-lab /plugin install john-lab@john-labDownload verify-release-readiness.zipView on GitHub
View SKILL.md
--- name: verify-release-readiness description: Review candidate and live release evidence to produce a dated readiness report or deployment receipt, including source identity, required gates, and unresolved proof gaps. --- # Verify release readiness Produce read-only evidence of whether a candidate meets the project's release requirements, or whether an already completed rollout serves the intended source and behavior. This skill does not deploy, migrate, rotate secrets, change feature flags, create paid work, or authorize those actions. ## Establish the release contract Use the project's current instructions, candidate commit or artifact identity, release target, live health or version endpoints, required checks, and supplied deployment receipts. Determine whether this is pre-release readiness or post-release verification. Record the observation time and environment. Never treat a historical runbook's source floor, runtime version, rollback identifier, or command as current without checking it. Confirm the repository and remote context through available read-only tools. For a candidate release, verify the live source and required release branch are included in the candidate's history when the project's policy requires it. Record dirty files or an unverifiable build identity. A successful test run from a different source cannot establish readiness for the intended artifact. ## Inspect evidence proportionally - Map required checks to their actual result, source identity, time, and scope. Distinguish focused checks, full suites, skipped cases, pre-existing failures, and missing results. Do not call a suite passing when a known failure is merely considered unrelated. - For multiple deployed components, verify the project's compatibility rule. Where app and compute must match, compare exact source identities and health for both. Do not impose same-commit deployment on systems whose declared design allows independent releases. - If data changes are included, compare the candidate migration inventory with the current ledger evidence and identify additions, collisions, partial state, and restore/recovery provisions. Inspect only authorized metadata; do not apply migrations. - Where in-flight work matters, use authorized aggregate status or supplied evidence to assess the required quiet window. Missing access leaves this gate unverified; it does not imply zero work. - Compare allowed runtime, configuration and binding metadata before and after when available. Do not retrieve secret values merely to compare metadata. Binding names and types cannot prove that remote secret bytes are identical or that the application used them. - Check the public behavior relevant to the change. Use safe read-only paths or existing synthetic evidence. A healthy status endpoint does not establish a complete payment, fulfillment or customer workflow. Do not start charges, email, provider inference, or other effects solely to strengthen a receipt. For an already completed release, verify intended source identities at the actual endpoints, record the observed deployment and runtime metadata, inspect relevant public behavior, and state what is supported by observation versus a provider acknowledgment or saved receipt. ## Deliverable and stopping condition Return a concise verdict, candidate/live identities, observation time, checks table, preserved-configuration evidence, unresolved gates, and next required action. Link to sanitized evidence where possible. Separate readiness from authorization and observed rollout from untested business outcomes. Stop when all applicable gates have dispositions or required evidence is inaccessible. Request the specific missing evidence rather than inferring success. If live state changes during the review, mark the earlier observations stale and reread the affected gates; do not repeatedly poll unchanged state or mutate production to resolve ambiguity. Package status: this Claude skill draft has not been behaviorally tested in Claude. Historical release-verification methods informed it; this package carries no production deployment authority.