Release publisher

Skill fermeridamagni/skills/skills/release-publisher

A collection of AI skills created for me

Install

npx -y skills add fermeridamagni/skills --skill release-publisher

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Automate releasing packages/apps/products to GitHub repositories. Use this whenever the user asks to release, publish, ship a new version, bump a version, create tags, generate changelog/release notes, or prepare a GitHub Release. Always use this skill for release automation requests, including npm/GitHub Packages/VS Code Marketplace/Open VSX publishing and release workflow setup.

SKILL.md

4.3 KB, as published. Nobody here has run it

Release Publisher

Use this skill to run an end-to-end release flow with deterministic outputs and explicit user approval before mutating repository state.

Why this skill exists

Releases often fail because teams do release tasks manually and out of order. This skill standardizes the process so every release has:

Commits gathered since the last release/tag
Draft release notes and changelog content
A clear confirmation checkpoint
A created tag + GitHub Release
Workflow-based publishing (with automatic release.yml creation when missing)

Trigger guidance

Use this skill when users ask for anything related to:

publish/release/ship/version bump
changelog generation or release notes drafting
tagging versions and creating GitHub releases
release automation via GitHub Actions
publishing to npm, GitHub Packages, VS Code Marketplace, Open VSX, or another registry

Required inputs

Collect these before execution:

version (for example: 1.4.0)
target registries (for example: npm,github-packages)
release channel (stable or prerelease)
whether the user wants draft release first

Release workflow

Follow these steps in order.

1) Ensure release workflow exists

Detect whether a release workflow already exists in .github/workflows/. If none exists or it needs to be updated for a specific registry, read the corresponding guide in the guides/ directory of this skill:

guides/npm.md for npm registry
guides/github-packages.md for GitHub Packages
guides/vscode-marketplace.md for VS Code Marketplace
guides/open-vsx.md for Open VSX Registry

Use these guides to create or update .github/workflows/release.yml. If the registry requires manual setup from the user (e.g., configuring Trusted Publishing in NPM, setting up Azure DevOps PAT for VS Code Marketplace, claiming a namespace on Open VSX, or adding a scope in package.json), you MUST explain these steps to the user clearly.

2) Build release draft from commit history

Create draft artifacts from commits since the latest tag/release:

bun run .agents/skills/release-publisher/scripts/prepare-release.ts --version 1.4.0

Artifacts written to .release/:

commits.json
release-notes.md
changelog-entry.md

Important: Because this step creates a .release folder in the project root, ensure that .release/ or .release is added to the repository's .gitignore file to avoid pushing it into the remote repository.

3) Mandatory confirmation checkpoint

Before mutating files, tags, or GitHub releases:

Show the generated release notes/changelog draft to the user
Show the planned tag and release title
Show whether release.yml will be created/updated
Ask for explicit confirmation

Do not continue until the user confirms.

4) Apply changelog update after approval

bun run .agents/skills/release-publisher/scripts/prepare-release.ts \
  --version 1.4.0 \
  --apply-changelog

5) Create tag and GitHub release

bun run .agents/skills/release-publisher/scripts/publish-release.ts \
  --version 1.4.0 \
  --confirm

Optional flags:

--draft
--prerelease
--tag v1.4.0
--title "v1.4.0"

Output format

Respond with this structure:

## Release plan
- Version:
- Last tag:
- Commits found:
- Registries:
- Workflow status:

## Draft notes
<content from .release/release-notes.md>

## Draft changelog entry
<content from .release/changelog-entry.md>

## Confirmation required
Proceed with changelog + tag + GitHub Release? (yes/no)

After completion:

## Release complete
- Tag:
- GitHub Release:
- Changelog path:
- Workflow path:
- Publishing trigger:

Safety rules

Fail fast on command errors; do not silently continue.
Never create a release without user confirmation.
If no previous tag exists, use full commit history and state this clearly.
Do not edit unrelated files.