release-verify
Skill0 starsChanged 4 months agoMITView on GitHub
Phase 5 of 5 (final) in the release chain (changelog → bump → tag → publish → verify). Confirms the published version is actually live and the release is intact, then closes the chain. Trigger when the previous phase says "run release-verify next", or standalone via "release-verify", "phase 5 of release", "verify the release went live".
In this repository21 other files it gives its agents.
- bughunt-diagnoseSkill
- bughunt-fixSkill
- bughunt-reproSkill
- bughunt-verifySkill
- feature-ship-buildSkill
- feature-ship-reviewSkill
- feature-ship-shipSkill
- feature-ship-specSkill
- migrate-inventorySkill
- migrate-transformSkill
- migrate-verifySkill
- onboard-deepenSkill
- onboard-digestSkill
- onboard-mapSkill
- release-bumpSkill
- release-changelogSkill
- release-publishSkill
- release-tagSkill
- research-artifactSkill
- research-gatherSkill
- research-synthesizeSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
All chain state is managed by the chain tool: authoritative JSON at .pi/fairy-tales/chains/release/state.json with a human-readable …
- Very specific: line 30
Call the chain tool with action: "status", chain: "release" (a legacy .release-state.md from an older version is imported automatically):
- Very specific: line 33
If there is no run → abort: "No release run found.
- Very specific: line 34
If the run is not active with currentPhase: "verify" → abort: "Expected the run to be at phase verify but it is at <currentPhase/status>.
- Very specific: line 37
If data.package / data.version, or the publish phase's artifacts.npmUrl / artifacts.releaseUrl (or its summary), is missing → abort: "Phase …
- Very specific: line 41
If the tool reports the chain is locked by another session, abort.
- Distinctive: line 61
Call the chain tool:
- Distinctive: line 80
After completing this phase, output exactly:
- Distinctive: line 86
Do not continue. Stop here.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Release: Verify
Chain version: 2 (durable state contract — see docs/STATE-CONTRACT.md)
Phase 5 of 5: release-changelog → release-bump → release-tag → release-publish → release-verify
Overview
Final phase. Proves the release actually landed — the npm version resolves, the tag and GitHub release exist, and the published metadata matches what was intended — then marks the chain complete. Reports faithfully: if a check fails, it says so rather than declaring success.
All chain state is managed by the chain tool: authoritative JSON at
.pi/fairy-tales/chains/release/state.json with a human-readable state.md
projection beside it. Never create or edit state files by hand, and never create lock
files — the tool locks for you.
Load State
Call the chain tool with action: "status", chain: "release" (a legacy
.release-state.md from an older version is imported automatically):
- If there is no run → abort: "No release run found. Run
release-changelogfirst." - If the run is not
activewithcurrentPhase: "verify"→ abort: "Expected the run to be at phaseverifybut it is at<currentPhase/status>. Run that phase's skill instead." - If
data.package/data.version, or the publish phase'sartifacts.npmUrl/artifacts.releaseUrl(or its summary), is missing → abort: "Phase pointer looks right but the Phase 4 output is missing. Treat as corrupted — restart the chain or repair via chain action 'update'." - If the tool reports the chain is locked by another session, abort; a dead session's
lock can be cleared with
action: "unlock". Never create lock files yourself.
Workflow
Step 1 — Verify the publish
- npm:
npm view <package>@<version> versionreturns the version; optionally confirmdist.tarballresolves (HTTP 200) andpi.image/keywords are intact for pi packages. - git:
git ls-remote --tags origin | grep v<version>shows the pushed tag. - GitHub:
gh release view v<version>shows the release.
Step 2 — Report
Produce a short release report: package, version, npm URL, tag, release URL, and the result of each check (✓ / ✗). Name any check that failed and what to do about it — do not paper over a failure.
Step 3 — Complete the phase
Call the chain tool:
action: "complete-phase", chain: "release", phase: "verify",
summary: "verification report: all checks ✓ / <listed failures>; release confirmed live at <npm URL> / <release URL>",
data: { "verificationReport": "<the report from Step 2>" },
artifacts: {
"npmUrl": "<npm package page URL>",
"releaseUrl": "<GitHub release URL>",
"tag": "v<version>"
}The tool validates this is the current phase, marks the run complete, and rewrites
the JSON + markdown projection atomically — this is the final phase, so the run's
status becomes complete and its lock is released.
Handoff
After completing this phase, output exactly:
Chain complete! All 5 phases finished. Chain state updated (
.pi/fairy-tales/chains/release/state.json). Runrelease-changelogagain to start a new release.
Do not continue. Stop here.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

