agentleFS
Sign inStart free
fpindejfpindej/netrock/.claude/skills/create-release/SKILL.md

create-release

Skill234 starsChanged 3 months agoMITView on GitHub

Create a versioned GitHub release with changelog

  • Commits and pushes

17 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Only release from master: If not on master, switch first.

    line 11
  2. Very specific:

    Ensure you are on master and up to date: git checkout master && git pull

    line 18
  3. Very specific:

    If the user provided a version (e.g., v1.2.3), use it

    line 21
  4. Very specific:

    If the user provided a bump type (major, minor, patch), calculate from the latest tag:

    line 22
  5. Distinctive:

    If no argument and no tags exist, ask the user what version to use

    line 26
  6. Very specific:

    If no argument but tags exist, default to patch bump

    line 27
  7. Distinctive:

    Check what changed since the last release:

    line 29
  8. Distinctive:

    Add a brief intro paragraph summarizing the release highlights before the categories.

    line 47
  9. Distinctive:

    Create the tag and release:

    line 49

“Common” is measured: kept by at least 6 in 10 of the 16 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

Creates a GitHub release with auto-generated release notes.

Hard rules

  • Only release from master. If not on master, switch first.
  • No Co-Authored-By lines in commits.
  • Tag signing follows the developer's git config (tag.gpgSign) - never pass -s/-S explicitly; fresh clones may have no signing key.
  • Releases use semantic versioning (vMAJOR.MINOR.PATCH).

Steps

  1. Ensure you are on master and up to date: git checkout master && git pull
  2. Determine the version:
    • If the user provided a version (e.g., v1.2.3), use it
    • If the user provided a bump type (major, minor, patch), calculate from the latest tag:
      git tag --list 'v*' --sort=-v:refname | head -1
    • If no argument and no tags exist, ask the user what version to use
    • If no argument but tags exist, default to patch bump
  3. Check what changed since the last release:
    # If previous tag exists:
git log <previous-tag>..HEAD --oneline
# If first release:
git log --oneline -50

  4. Generate release notes by categorizing merged PRs and commits since the last tag. Group changes into these categories (omit empty categories):

    • New Features - feat: commits and feature PRs
    • Security - security: or security-related changes
    • Bug Fixes - fix: commits
    • Improvements - refactor:, perf: commits
    • Documentation - docs: commits
    • Infrastructure - chore:, ci:, build: commits

    Format each entry as: - Description (#PR) where possible.

    Add a brief intro paragraph summarizing the release highlights before the categories.

  5. Create the tag and release:
    git tag -a <version> -m "Release <version>"
git push origin <version>
gh release create <version> --title "<version>" --notes "<release-notes>"
  6. Report the release URL.

Version Bumping Reference

Given vMAJOR.MINOR.PATCH:

  • major - breaking changes or major milestones (v1.0.0 -> v2.0.0)
  • minor - new features, no breaking changes (v1.0.0 -> v1.1.0)
  • patch - bug fixes, docs, refactors (v1.0.0 -> v1.0.1)

First Release

For the very first release (no prior tags), review the full project scope and write release notes that highlight the key capabilities of the project as shipped. This is the launch announcement.

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