Release Harness Skill

Automates the claude-code-harness release process.

Quick Reference

• "Release a new harness version" -> /release-harness
• "Bump patch version" -> /release-harness patch
• "Create a minor release" -> /release-harness minor

Execution Flow

Step 1: Change Verification

Run in parallel:

1. git status - Check uncommitted changes
2. git diff --stat - List changed files
3. git log --format="%h|%s|%an|%ad" --date=short -10 - Recent commit history (structured)

Git Log Flags (CC 2.1.30+)

Use structured log output for release note generation.

Commit List for Release Notes

# Structured format commit list
git log --format="%s" vPREV..HEAD

# Exclude merge commits (actual changes only)
git log --cherry-pick --no-merges --format="%s" vPREV..HEAD

# Detailed info (with author and date)
git log --format="%h|%s|%an|%ad" --date=short vPREV..HEAD

Key Use Cases

Step 2: Version Determination

Check current version:

cat VERSION

Determine version based on changes (Semantic Versioning):

• patch (x.y.Z): Bug fixes, minor improvements
• minor (x.Y.0): New features (backward compatible)
• major (X.0.0): Breaking changes

Ask user: "What should the next version be? (e.g., 2.5.23)"

Step 3: CHANGELOG Update (JP + EN)

Important: Focus on user-facing changes. Keep internal fixes brief.

Update both CHANGELOG_ja.md and CHANGELOG.md.

CHANGELOG Rules

Template

## [X.Y.Z] - YYYY-MM-DD

### What's Changed

**One-line description of user experience change**

| Before | After |
|--------|-------|
| Previous state | New state |

### Added

- Concise feature description

### Internal

- One-line summary of internal changes

Before/After Table Rules

• Only for user-facing changes
• Not needed for internal fixes (CI, tests, refactoring)
• Write from user perspective, not technical details

Step 3.5: README Update Check

Check if README needs update (JP/EN both)

Step 4: Version File Update

echo "X.Y.Z" > VERSION

Also update .claude-plugin/plugin.json:

"version": "X.Y.Z"

Step 5: Commit and Tag

git add -A
git commit -m "chore: release vX.Y.Z"
git tag -a vX.Y.Z -m "Release vX.Y.Z"

Step 6: Push

git push origin main
git push origin vX.Y.Z

Step 7: GitHub Release (Optional)

gh release create vX.Y.Z \
  --title "vX.Y.Z - Title" \
  --notes "$(cat <<'EOF'
## What's Changed

**One-line user experience change**

| Before | After |
|--------|-------|
| Previous state | New state |

### Added / Changed / Fixed

- Concise description

---

Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

GitHub Release Format

Follow .claude/rules/github-release.md:

## What's Changed

**One-line value description**

| Before | After |
|--------|-------|
| Previous state | New state |

### Added / Changed / Fixed

- Brief description

---

Generated with [Claude Code](https://claude.com/claude-code)

Related Skills

• verify - Pre-release verification