han-release
Cut a Han release: update CHANGELOG.md with the changes since the last release, bump every plugin that changed, tag every plugin as {plugin-name}--v{version} so a version-constrained dependency can resolve, and publish a GitHub release whose notes attribute every merged pull request to its author, credit every closed issue to the person who opened it, the people who contributed to it, and the people who worked on the fix, and link back to the full changelog for that version. Han ships as a parent meta-plugin (`han`) plus child plugins (`han-core`, `han-github`, `han-reporting`, and any future
npx skills add testdouble/han --skill han-release --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
<!-- `AskUserQuestion` is deliberately absent from `allowed-tools`, and must stay absent. Listing it makes Claude Code's permission evaluator auto-approve the tool through its always-allow path and return empty answers without ever rendering the prompt, so every gate in this skill would silently pass. See han-plugin-builder/skills/guidance/references/skill-building-guidance/allowed-tools-AskUserQuestion.md. The tool still works unlisted; it prompts once for permission. --> ## Pre-requisites - gh CLI: !`which gh 2>/dev/null || echo "not installed"` - jq: !`which jq 2>/dev/null || echo "not installed"` - claude CLI: !`which claude 2>/dev/null || echo "not installed"` - git repo: !`git rev-parse --is-inside-work-tree 2>/dev/null || echo NO` **If `gh`, `jq`, or `claude` reads `not installed`, or this is not a git repo:** tell the operator which prerequisite is missing and that it must be installed/configured before `/han-release` can run, then **immediately stop**. The skill cannot proceed without all four. The `claude` CLI is what creates the per-plugin tags in Step 10. Every invocation of it in this skill goes through the shell's `command` builtin (`command claude ...`), never a bare
- Pre-requisites
- Project Context
- Vocabulary used throughout this skill
- Step 1: Parse the invocation and check release safety
- Step 2: Determine previous version, commit range, and PR list
- Step 3: Build the per-plugin version plan
- 3a. Classify each plugin
- 3b. Compute each changed plugin's bump level and target
- 3c. Decide each plugin's target (ahead path vs. compute path)
- 3d. Confirm the plan (conditional gate)
- Step 3.5: Validate every plugin before anything is written
- Step 4: Apply the versions
- Step 5: Update CHANGELOG.md
- Step 6: Assemble the release notes body
What does the han-release skill do?
Cut a Han release: update CHANGELOG.md with the changes since the last release, bump every plugin that changed, tag every plugin as {plugin-name}--v{version} so a version-constrained dependency can resolve, and publish a GitHub release whose notes attribute every merged pull request to its author, credit every closed issue to the person who opened it, the people who contributed to it, and the people who worked on the fix, and link back to the full changelog for that version. Han ships as a parent meta-plugin (`han`) plus child plugins (`han-core`, `han-github`, `han-reporting`, and any future
How do I install it?
Run `npx skills add testdouble/han --skill han-release --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From testdouble/han, a repository with 154 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.