agentleFS
Sign inStart free
hiroppyhiroppy/tmux-agent-sidebar/.claude/skills/version-release/SKILL.md

version-release

Skill568 starsChanged 7 months agoMITView on GitHub

Use when bumping version, creating a release tag, or pushing a version tag. Triggers on "version up", "release", "tag push", "bump version".

  • Commits and pushes

11 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use issue-reply, changelog-collect and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • RisorseArtificialiSkill

    issue-reply

    Reply to GitHub issue discussions as the maintainer — fetch the issue and its thread, brief the user on the discussion and the open questions, verify technical claims against the code before endorsing them, draft the reply, and publish only after explicit approval. Use when the user says "rispondi alle issue", "respond to the issues", "guardiamo la #N", "reply to the comments", or hands over a list of issues to answer. The commenting counterpart of issue-triage, which stays read-only.

    Also in 3 projects that use this

  • NG-ZORROSkill

    changelog-collect

    Collect and draft NG-ZORRO changelog entries between releases or branches. Use when asked to compare release ranges, collect PR changes, or prepare changelog content before release staging.

    Also in 3 projects that use this

  • idlesilverSkill

    project-overview

    Build or update a repository-grounded project overview as a standalone offline HTML with three resizable panes: file explorer, nested architecture map, and module/source details. Use for codebase onboarding, maintainer documentation, clickable code maps, and architecture/roadmap readers. Supports current/target comparison, optional explanatory diagrams, and draw.io editing with screenshot feedback.

    Also in 3 projects that use this

  • SentrySkill

    create-pr

    Create pull requests following Sentry conventions. Use when opening PRs, writing PR descriptions, or preparing changes for review. Follows Sentry's code review guidelines.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 3 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 3

    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
  1. Very specific:

    Regenerate Cargo.lock: Run cargo check to update Cargo.lock

    line 19
  2. Very specific:

    Run checks: Run cargo fmt --check && cargo clippy && cargo test

    line 20
  3. Very specific:

    Commit: Commit Cargo.toml, Cargo.lock, and .claude-plugin/plugin.json (message example: Bump version to X.Y.Z)

    line 21
  4. Very specific:

    Treat any feat: commit as a minor bump trigger, even if the rest are fixes.

    line 37
  5. Distinctive:

    If the range is empty (no commits since the last tag), stop and tell the user there is nothing to release.

    line 40
  6. Distinctive:

    When in doubt between patch and minor, show the commit list and ask the user.

    line 42
  7. Distinctive:

    Always pass CI checks (fmt, clippy, test) before creating a tag

    line 55
  8. Very specific:

    Commit Cargo.lock together with Cargo.toml

    line 56

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Version Release

Workflow for updating the version in Cargo.toml, creating a git tag, and pushing it.

Workflow

  1. Check current version: Get current version with grep '^version' Cargo.toml.
  2. Propose the next version from commits since the last tag:
    • Find the previous release tag: git describe --tags --abbrev=0 --match 'v*'
    • List every commit since that tag: git log <prev-tag>..HEAD --oneline
    • Classify the commits using the Pre-1.0 Bump Policy below, decide patch / minor / major, and present the proposed version number to the user before editing any files. Do not skip this step even for a single commit — the user should always see the commit range and the classification you used.
  3. Update version: Edit the version field in Cargo.toml using the Edit tool.
  4. Sync the Claude Code plugin manifest: Edit .claude-plugin/plugin.json and update its version field to the same value. The two MUST stay in lockstep — tests/plugin_hooks_tests.rs enforces this. Without bumping plugin.json, users who installed via /plugin install will not see the new release because Claude Code uses this field for update detection.
  5. Regenerate Cargo.lock: Run cargo check to update Cargo.lock
  6. Run checks: Run cargo fmt --check && cargo clippy && cargo test
  7. Commit: Commit Cargo.toml, Cargo.lock, and .claude-plugin/plugin.json (message example: Bump version to X.Y.Z)
  8. Create and push tag: git tag vX.Y.Z && git push && git push origin vX.Y.Z

Pre-1.0 Bump Policy

This project is still pre-1.0, so SemVer is relaxed: the major stays at 0 and breaking changes ride on minor bumps.

Signal in commit rangeBumpExample
Any feat: / new user-visible behavior / breaking changeminor0.5.2 → 0.6.0
Only fix: / refactor: / chore: / docs: / test-onlypatch0.5.2 → 0.5.3
Post-1.0 only: breaking change (feat!:, BREAKING CHANGE footer)major1.x → 2.0.0

Rules of thumb when classifying:

  • Treat any feat: commit as a minor bump trigger, even if the rest are fixes.
  • Docs-only or CI-only commit ranges still ship as a patch (never skip the version bump — the tag is what downstream plugin managers key off).
  • If the range is empty (no commits since the last tag), stop and tell the user there is nothing to release.
  • When in doubt between patch and minor, show the commit list and ask the user.

Quick Reference

Bump typeExample
patch0.2.0 → 0.2.1
minor0.2.0 → 0.3.0
major0.2.0 → 1.0.0

Notes

  • Tags use the v prefix (e.g., v0.2.0)
  • Always pass CI checks (fmt, clippy, test) before creating a tag
  • Commit Cargo.lock together with Cargo.toml

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free