SKILLπ JOURNAL ↗ Our tools

Skillπ Release Readiness: turn release evidence into a clear handoff

Meet our original release-review skill: a local evidence checker and bilingual handoff templates that distinguish observed results from incomplete acceptance.

A release can have a working homepage and still lack evidence for the task that matters. Skillπ Release Readiness is our original skill package for reviewing supplied release evidence and writing a clear ready/hold handoff. It is a skill and a local helper, not a hosted deployment service.

Start with the evidence, not the badge

Gather the release revision, target environment, required checks and references to the actual observations. Mark unknown behavior as unknown. For a commerce release, a checkout screenshot does not establish a captured payment, an entitlement or a delivered file. Each step needs its own evidence.

The package contains a SKILL.md workflow, evidence-format notes, two illustrative evidence files and bilingual reporting templates. The helper evaluates the consistency of your record. It cannot authenticate a receipt, grant authorization or decide whether a legal agreement is valid.

Run the local checker when appropriate

After obtaining the package through its current listing and reading the instructions, Python 3.9 or later can run this command from the package directory:

python scripts/check_evidence.py path/to/evidence.json --lang en

The command reads the specified evidence file and prints JSON. Exit code 0 means the supplied record meets the helper’s ready conditions; exit code 2 means hold. It does not deploy the application, make network calls, sign a contract or issue a payment. The files included as examples are illustrative fixtures, not proof that your release passed.

Distinguish local, sandbox and live

  • Local checks can exercise application logic without a provider transaction.
  • Sandbox checks can exercise an integration within a provider’s test environment.
  • Live acceptance needs the observations required for the actual live scope.

If a required check needs live evidence, a synthetic or sandbox result cannot satisfy it. Missing evidence references, stale timestamps, failed required checks and incomplete owner actions produce concrete blockers. Review the referenced receipts yourself instead of treating a consistent JSON record as external verification.

Write a handoff someone can act on

Lead with the decision and the smallest unresolved blocker. State the tested revision and environment, the checks actually exercised, which outcomes were simulated, and what remains with the owner. Keep private keys, tokens and customer data out of the report.

For example, “Hold: the buyer entitlement was not exercised after capture” is actionable. “Payment works” after opening a payment page is too broad. The skill helps preserve that distinction; it cannot remove the need to test.

Find the current package

The Product launch collection links to the current Release Readiness listing when it is publicly available. Check that detail page for price, license, included files and availability. This article is a product explanation, not an additional sales authorization or a successful live-payment acceptance record.

References & sources

Share articleX ↗LinkedIn ↗

CONTINUE YOUR WORKFLOW

Put this guide to work.

Selected through explicit skill links and shared collections. Check each listing and its source for requirements.