release-bump
Skill0 starsChanged 4 months agoMITView on GitHub
Phase 2 of 5 in the release chain (changelog → bump → tag → publish → verify). Applies the agreed version to package.json and writes the drafted entry into CHANGELOG.md. Trigger when the previous phase says "run release-bump next", or standalone via "release-bump", "phase 2 of release", "apply the version bump".
6 other projects use a version of this.
Adopted by
Most recently taken up by
- tony/skillstheir own version, first seen Oct 31, 2026
- shinobiashi/claude-skillstheir own version, first seen Oct 17, 2026
- skforecast/skforecast-aitheir own version, first seen Oct 13, 2026
- skforecast/skforecasttheir own version, first seen Oct 9, 2026
- jamiepine/voiceboxtheir own version, first seen Oct 8, 2026
- mikeyobrien/ralph-orchestratortheir own version, first seen Mar 14, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- jamiepine/voicebox★ 57ksame name
- mikeyobrien/ralph-orchestrator★ 3.2ksame name
- skforecast/skforecast★ 1.5ksame name
- skforecast/skforecast-ai★ 52same name
- shinobiashi/claude-skills★ 0same name
- tony/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
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-changelogSkill
- release-publishSkill
- release-tagSkill
- release-verifySkill
- research-artifactSkill
- research-gatherSkill
- research-synthesizeSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 3 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
3
Distinctive
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 22
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 29
Call the chain tool with action: "status", chain: "release" (a legacy .release-state.md from an older version is imported automatically):
- Very specific: line 32
If there is no run → abort: "No release run found.
- Very specific: line 33
If the run is not active with currentPhase: "bump" → abort: "Expected the run to be at phase bump but it is at <currentPhase/status>.
- Very specific: line 36
If data.package / data.version / data.changelogEntry (or the changelog phase summary) is missing → abort: "Phase pointer looks right but …
- Very specific: line 39
If the tool reports the chain is locked by another session, abort.
- Distinctive: line 63
Call the chain tool:
- Distinctive: line 77
After completing this phase, output exactly:
- Distinctive: line 82
Do not start the next phase.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Release: Bump
Chain version: 2 (durable state contract — see docs/STATE-CONTRACT.md)
Phase 2 of 5: release-changelog → release-bump → release-tag → release-publish → release-verify
Overview
Applies the version decided in Phase 1 to package.json and prepends the drafted
CHANGELOG entry to CHANGELOG.md. Makes no git tag and does not publish — those are
later phases — so this stays a reviewable, reversible edit.
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: "bump"→ abort: "Expected the run to be at phasebumpbut it is at<currentPhase/status>. Run that phase's skill instead." - If
data.package/data.version/data.changelogEntry(or the changelog phase summary) is missing → abort: "Phase pointer looks right but the Phase 1 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 — Apply the version
Set package.json version to data.version (exact value — never a different number
than Phase 1 agreed).
Step 2 — Write the changelog
Prepend data.changelogEntry to CHANGELOG.md, creating the file with a # Changelog
header if it does not exist. Keep existing entries below the new one.
Step 3 — Sanity check
node -e "require('./package.json')"(orpython3 -c "import json;json.load(open('package.json'))") to confirmpackage.jsonis still valid.- Confirm the new version does not already exist on the registry if this is an npm
package:
npm view <package>@<version> versionshould 404.
Step 4 — Complete the phase
Call the chain tool:
action: "complete-phase", chain: "release", phase: "bump",
summary: "package.json set to <version>; CHANGELOG.md updated; files staged but NOT committed (release-tag handles the commit)",
data: {},
artifacts: {}The tool validates this is the current phase, advances the run to tag, and rewrites
the JSON + markdown projection atomically.
Handoff
After completing this phase, output exactly:
Phase 2 complete. Chain state updated (
.pi/fairy-tales/chains/release/state.json). Run/release-tagto begin Phase 3.
Do not start the next phase. Do not offer to continue. Output only the handoff line and stop.
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.

