skills-release

Original：🇺🇸 English

Translated

Use when cutting a release of the kitaru-skills repository — pushing develop to main, bumping the kitaru plugin version, tagging a version, or publishing a GitHub Release for the Claude Code marketplace.

4installs

Sourcezenml-io/kitaru-skills

Added on2026-08-26

NPX Install

npx skill4agent add zenml-io/kitaru-skills skills-release

SKILL.md Content

View Translation Comparison →

Skills Release

Overview

main

is the distribution branch:

/plugin marketplace add zenml-io/kitaru-skills

installs whatever

main

holds, immediately.

develop

is the working base. A release moves

main

forward to

develop

's current commit as a fast-forward and stamps a plugin version, so

main

is always an exact snapshot of

develop

at release time.

The

main-release-only

ruleset blocks all pushes and PR merges to

main

except by repository admins. A release is therefore an admin running this checklist — never a PR into

main

, never a force push.

Versions are this repository's own plugin versions. Do not reuse Kitaru product version numbers; state tested Kitaru compatibility in the release notes instead.

Preconditions

Stop and resolve before releasing if any of these fail:

On
```
develop
```
with a clean working tree.
```
git fetch origin
```
done; local
```
develop
```
in sync with
```
origin/develop
```
.
Fast-forward is possible:
```
git merge-base --is-ancestor origin/main origin/develop
```
exits 0. A non-zero exit means
```
main
```
has commits
```
develop
```
lacks — investigate how they got there; never force-push over them.

Steps

Review what ships:
```
git log --oneline origin/main..origin/develop
```
. Draft release notes from these commits (what changed, why it matters to installers), plus a "Tested against Kitaru X.Y" line when known.
Agree the next version with the user: minor for new or changed skills, patch for fixes and docs-only changes.

Bump all three version fields to the same value:

```
.claude-plugin/plugin.json
```
→
```
.version
```

.claude-plugin/marketplace.json

→

.metadata.version

.claude-plugin/marketplace.json

→

.plugins[0].version

Validate:

jq . .claude-plugin/plugin.json

and

jq . .claude-plugin/marketplace.json

parse, and all three fields match:

bash

jq -r .version .claude-plugin/plugin.json
jq -r '.metadata.version, .plugins[0].version' .claude-plugin/marketplace.json

Commit only the two JSON files on
```
develop
```
with subject
```
Release vX.Y.Z
```
, then push
```
develop
```
.

Tag the release commit:

git tag vX.Y.Z && git push origin vX.Y.Z

.

Fast-forward
```
main
```
:
```
git push origin develop:main
```
. No
```
--force
```
ever — a rejection means the push is not a fast-forward; go back to Preconditions.
Publish the drafted notes via a file, never inline in the command — commit subjects routinely contain backticks, which the shell would execute as command substitution inside a
```
--notes "..."
```
argument. Write the notes to a scratch file with a file-writing tool (or a quoted heredoc,
```
cat > notes.md <<'EOF'
```
), then:
bash
```
gh release create vX.Y.Z --title "vX.Y.Z" --notes-file notes.md
```
Verify:
```
git ls-remote origin refs/heads/main refs/heads/develop
```
shows identical SHAs, and the GitHub Release page exists.

Recovery

Push to
```
main
```
rejected: confirm admin (bypass) rights and re-run the ancestor check from Preconditions.
Wrong version committed but not yet tagged: fix the JSON files and amend the release commit before tagging.
Tag already pushed with wrong content: if the GitHub Release is not yet published, delete and re-create the tag; otherwise cut a follow-up patch release rather than rewriting history.

Maintenance

The canonical copy of this skill is

.claude/skills/skills-release/SKILL.md

.

.agents/skills/skills-release

is a symlink to it — edit only the canonical file.