release-version
Skill0 starsChanged 8 months agoMITView on GitHub
Bump version on main, tag, run release pipeline, then deploy docs. Auto-increments patch if no version given.
- Commits and pushes
9 other projects use a version of this.
Adopted by
Most recently taken up by
- Nucs/Agentmastertheir own version, first seen Nov 3, 2026
- foldkit/foldkittheir own version, first seen Nov 2, 2026
- ngthluu/my-dev-skillstheir own version, first seen Nov 1, 2026
- cachewraith/cachewraith-skillstheir own version, first seen Oct 25, 2026
- corvo007/MioSubtheir own version, first seen Oct 8, 2026
- corvo007/Gemini-Subtitle-Protheir own version, first seen Oct 8, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- foldkit/foldkit★ 1.1ksame name
- corvo007/Gemini-Subtitle-Pro★ 835same name
- corvo007/MioSub★ 835same name
- Byte-n/larkDocx2md★ 34same name
- hhhyyyy99/prot-skills★ 7same name
- Vochsel/dump.page★ 3same name
- ngthluu/my-dev-skills★ 2same name
- Nucs/Agentmaster★ 1same name
- cachewraith/cachewraith-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 repository4 other files it gives its agents.
- address-issuesSkill
- create-prSkill
- release-workflowSkill
- review-prSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 8 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
If a version argument was provided, use it.
- Distinctive: line 21
If no version argument:
- Very specific: line 28
Verify VERSION is greater than CURRENT.
- Distinctive: line 48
Commit and push directly to main:
- Distinctive: line 77
If the release pipeline fails:
- Very specific: line 78
Read failure logs: gh run view <run-id> --log-failed
- Distinctive: line 89
Wait for docs deployment:
- Very specific: line 113
Update the version in the claude-marketplace repo so the plugin's SessionStart hook installs the correct version:
- Very specific: line 121
Update plugins/crux/.claude-plugin/plugin.json — set "version" to "<VERSION>".
- Very specific: line 123
Update plugins/crux/hooks/hooks.json — set PLUGIN_VERSION='<VERSION>' in the hook command.
- Distinctive: line 136
If tagged but release pipeline failed:
- Distinctive: line 143
If already published to PyPI, publish a patch fix instead — PyPI versions cannot be deleted.
- Distinctive: line 150
Always verify the release pipeline succeeds before deploying docs
“Common” is measured: kept by at least 6 in 10 of the 8 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 Version
Bump the version in pyproject.toml on main, tag the release, run the release pipeline, and deploy docs.
Step 0: Resolve Version
If a version argument was provided, use it. Otherwise, auto-increment:
# Read current version from pyproject.toml
CURRENT=$(grep -m1 '^version' pyproject.toml | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $CURRENT"If no version argument:
- Parse
CURRENTasMAJOR.MINOR.PATCH - Increment
PATCHby 1 - Set
VERSIONtoMAJOR.MINOR.(PATCH+1)
Example: 1.0.1 → 1.0.2
Verify VERSION is greater than CURRENT. If not, abort.
Step 1: Ensure Clean Main
git checkout main
git pull origin main
git statusWorking tree must be clean. If not, abort with a message.
Step 2: Bump Version
Update pyproject.toml:
version = "<VERSION>"Commit and push directly to main:
git add pyproject.toml
git commit -m "chore: bump version to <VERSION>"
git push origin mainStep 3: Tag and Push
git tag v<VERSION>
git push origin v<VERSION>This triggers .github/workflows/release.yml which:
- Runs full CI gate
- Builds sdist + wheel
- Publishes to PyPI
- Creates GitHub Release
Step 4: Wait for Release Pipeline
# Find the run triggered by the tag
gh run list --workflow=release.yml --limit=1
gh run watchIf the release pipeline fails:
- Read failure logs:
gh run view <run-id> --log-failed - Report the failure and stop. Do NOT proceed to docs.
Step 5: Deploy Docs
The docs pipeline does not auto-trigger from GitHub Actions releases. Dispatch manually:
gh workflow run docs.yml -f version=<VERSION>Wait for docs deployment:
gh run list --workflow=docs.yml --limit=1
gh run watchStep 6: Verify
# PyPI
pip index versions crux-cli
# GitHub Release
gh release view v<VERSION>
# Docs
echo "Docs: https://crux-cli.github.io/crux/"Report the version, PyPI status, and docs URL.
Step 7: Update Marketplace Plugin Version
Update the version in the claude-marketplace repo so the plugin's SessionStart hook installs the correct version:
cd ../claude-marketplace
git checkout main
git pull origin mainUpdate plugins/crux/.claude-plugin/plugin.json — set "version" to "<VERSION>".
Update plugins/crux/hooks/hooks.json — set PLUGIN_VERSION='<VERSION>' in the hook command.
Commit and push:
git add plugins/crux/.claude-plugin/plugin.json plugins/crux/hooks/hooks.json
git commit -m "chore: bump crux plugin version to <VERSION>"
git push origin main
cd ../cruxRollback
If tagged but release pipeline failed:
git tag -d v<VERSION>
git push origin :refs/tags/v<VERSION>If already published to PyPI, publish a patch fix instead — PyPI versions cannot be deleted.
Notes
- This skill operates directly on main — no branch or PR involved
- The release pipeline requires a PyPI trusted publisher configured in GitHub repo settings
- The docs pipeline uses
mikefor versioned documentation - Always verify the release pipeline succeeds before deploying docs
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.

