agentleFS
Sign inStart free
frostneyfrostney/pascal-mcp-sdk/.agents/skills/create-release/SKILL.md

create-release

Skill2 starsChanged 3 months agoMITView on GitHub

Prepares a changelog-first release and, only when explicitly requested, publishes it through the repository's single established release path. Use when the user asks to prepare, cut, tag, or publish a release, bump the version, or generate release notes.

We split this skill into the rules it gives an agent

11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Publish: after the PR merges, create or trigger the tag/release through the repository's established publisher.

    line 25
  2. Distinctive:

    When ambiguous, perform Prepare only.

    line 28
  3. Distinctive:

    Use the repository's configured tools and current documentation.

    line 33
  4. Distinctive:

    Use an explicit version or recommend one from unreleased conventional commits and wait for the user's decision.

    line 35
  5. Distinctive:

    Run the declared release-relevant gate and report only observed results.

    line 37
  6. Distinctive:

    Never amend, force-push, force-update a tag, skip hooks, or publish through more than one path.

    line 38
  7. Distinctive:

    Stop if there are no releasable commits.

    line 46
  8. Distinctive:

    Create a release branch from the fresh remote base.

    line 49
  9. Very specific:

    Run the release-relevant project gate, commit chore(release): <version>, and open a draft release PR through /create-pr.

    line 53
  10. Distinctive:

    Wait for and verify the squash merge.

    line 59
  11. Distinctive:

    Stop when ownership is ambiguous or documentation and workflow disagree.

    line 71

“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

Create release

Prepare a release whose tag contains its changelog, then publish through exactly one evidence-backed path when publication is authorized.

Authorization

  • Prepare: determine the version, update changelog/version declarations, validate, and open the release PR. Requests to prepare, bump, or generate notes authorize only this stage.
  • Publish: after the PR merges, create or trigger the tag/release through the repository's established publisher. Requests to cut, tag, publish, or run /create-release authorize this stage too.
  • When ambiguous, perform Prepare only.

Invariants

  • The changelog and version bump land before the tag, through a squash-merged PR.
  • Use the repository's configured tools and current documentation. Regenerate generated changelogs rather than hand-editing them.
  • Use an explicit version or recommend one from unreleased conventional commits and wait for the user's decision.
  • Run the declared release-relevant gate and report only observed results.
  • Never amend, force-push, force-update a tag, skip hooks, or publish through more than one path.

Prepare

  1. Resolve the authorization stage, remote default branch, clean working tree, changelog/version tooling, last release, remote tags, workflows, and release documentation.
  2. Stop if there are no releasable commits.
  3. Validate a supplied version, or recommend and confirm the next version from unreleased commits.
  4. Create a release branch from the fresh remote base.
  5. Generate the changelog section and update every authoritative version declaration using project tooling. Do not invent a manifest bump when the project derives its version from tags.
  6. Run the release-relevant project gate, commit chore(release): <version>, and open a draft release PR through /create-pr. Include the changelog section and observed validation. Stop here for Prepare-only requests.

Publish

  1. Wait for and verify the squash merge; never tag the open PR branch.
  2. Refresh the merged base, then re-read the actual workflow YAML and release documentation. Identify separate owners for tag creation, GitHub release creation, artifact signing, and registry publishing.
  3. Select exactly one route:
    • workflow owns tag and release: trigger or monitor it only;
    • agent owns tag, workflow owns release: push the verified tag once, then monitor;
    • workflow owns tag, agent owns release: verify its tag, then create one GitHub release;
    • agent owns both: only when no workflow owns either action, push the verified tag once and create one release.
  4. Stop when ownership is ambiguous or documentation and workflow disagree.
  5. Execute only the selected route and verify the final tag target, release, workflow result, artifacts, and registry state that the route owns.

Lead with the release outcome, PR/release URL, selected publisher, and current evidence. Never describe an unobserved state as complete.

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.

Reviews can't be read right now.

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