agentleFS
Sign inStart free
patmeh1patmeh1/product-docs-kit/.claude/skills/release-prep/SKILL.md

release-prep

Skill0 starsChanged 2 months agoMITView on GitHub

Prepare a release by determining the correct semantic version, assembling the changelog, verifying that everything which should have shipped actually shipped, and producing release notes with deploy and rollback plans. Use when the user asks to "cut a release", "prepare a version", "ship it", "tag a release", or "write release notes".

23 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

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 21 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read AGENTS.md and the full procedure in prompts/06-release-prep.md.

    line 12
  2. Distinctive:

    Ask the user for the previous release tag if you cannot determine it.

    line 13
  3. Distinctive:

    Every commit since the last tag, grouped by requirement ID.

    line 18
  4. Distinctive:

    Every migration in range is additive and backward-compatible, tested against a copy of production data, with a documented rollback

    line 37
  5. Distinctive:

    No dependency was bumped as a side effect of feature work

    line 41
  6. Distinctive:

    If a migration is involved, spell out the exact ordering and the verification step between each stage.

    line 61
  7. Distinctive:

    Run the smoke test before announcing.

    line 66

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

Release Preparation

The last checkpoint before real users are affected. Be rigorous.

Before you start

Read AGENTS.md and the full procedure in prompts/06-release-prep.md. Ask the user for the previous release tag if you cannot determine it.

Six steps

1. Assemble the change set

Every commit since the last tag, grouped by requirement ID. List commits with no requirement ID — they should not exist, but untracked changes must at least be visible.

Identify breaking changes independently. Do not trust the labels — check every change against the criteria in docs/06-api-contract.md §5, even if it was not marked.

2. Determine the version

Strict SemVer: any breaking change → MAJOR; any new feature → MINOR; fixes only → PATCH. Justify it by citing the specific commits that drive it.

Pre-1.0, MINOR may carry breaking changes — but the changelog must say so prominently.

3. Pre-release verification

Work the checklists honestly. Do not tick a box you have not verified.

Completeness · quality · safety · documentation. Specifically confirm:

  • Every migration in range is additive and backward-compatible, tested against a copy of production data, with a documented rollback
  • No TECH- entry is at EOL or Unsupported
  • No UPG- item is past its deadline without status Accepted risk
  • No dependency was bumped as a side effect of feature work

Report any failure explicitly and recommend whether to block the release.

4. Assemble the changelog

Convert [Unreleased] into the new version heading. Verify every entry cites a requirement ID. Mark breaking changes **BREAKING** with the migration path.

Write for users, not developers. "Fixed null pointer in getUser" tells a user nothing. "Fixed an error that could log you out while uploading a large file" tells them everything.

5. Update documentation state

Requirements → Shipped. Traceability matrix Released column. Migrations marked applied. Recalculate the coverage summary.

6. Produce the artefacts

Release notes (user-facing), deploy plan, rollback plan, post-deploy smoke test, risk assessment, and the tag command.

If a migration is involved, spell out the exact ordering and the verification step between each stage.

Remind the user

Run the smoke test before announcing. Watch monitoring for 30 minutes with the rollback command ready in a terminal — not in a browser tab they have to find.

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