harness-release

Harness Release (v3)

Harness v3 integrated release skill. Integrates the following legacy skills:

• release-har — General-purpose release automation
• x-release-harness — Harness-specific release automation
• handoff — Handoff to PM / completion report

Quick Reference

/release          # インタラクティブ（バージョン種別を確認）
/release patch    # パッチバージョンバンプ（バグ修正）
/release minor    # マイナーバージョンバンプ（新機能）
/release major    # メジャーバージョンバンプ（破壊的変更）
/release --dry-run  # プレビューのみ（実行しない）
/release --announce # Slack 等への告知も実行

Release-only policy

• Normal PR: VERSION / .claude-plugin/plugin.json / versioned CHANGELOG.md do not touch entry
• Normal PR changelog: CHANGELOG.md の [Unreleased] append to
• /release only when running, update version bump, versioned CHANGELOG entry, tag / GitHub Release all together

Branch Policy

• Solo development: Allow direct push to main (CI functions as a quality gate)
• Collaborative development: Merging via PR is mandatory
• force push（--force / --force-with-lease) is always prohibited

Execution flow

Pre-flight check (mandatory)

# 1. gh コマンド確認
command -v gh &>/dev/null || echo "⚠️ gh なし: GitHub Release はスキップ"

# 2. 未コミット変更確認
git diff --quiet && git diff --cached --quiet || {
  echo "⚠️ 未コミット変更あり。先にコミットしてください。"
  exit 1
}

# 3. CI 状態確認
gh run list --branch main --limit 3 --json status,conclusion

Step 1: Get current version

CURRENT=$(cat VERSION 2>/dev/null || jq -r '.version' package.json 2>/dev/null)

Step 2: Calculate new version

Follow Semantic Versioning (SemVer):

• patch: x.y.Z → x.y.(Z+1) (bug fix)
• minor: x.Y.z → x.(Y+1).0 (new feature, backward compatible)
• major: X.y.z → (X+1).0.0 (breaking change)

Step 3: Update CHANGELOG

For the release entry, organize the [Unreleased] changes accumulated in normal PRs with the intent of finalizing them into a versioned section.

Detailed Before/After format(in Japanese). Divide each feature into numbered sections and explain "Before" and "After" with concrete examples.

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

### テーマ: [変更全体を一言で]

**[ユーザーにとっての価値を1〜2文で]**

---

#### 1. [機能名]

**今まで**: [旧動作を具体的に。ユーザーが「あるある」と感じる課題描写]

**今後**: [新動作を具体的に。何が解決するか]

[Actual output examples and command examples]

#### 2. [次の機能名]

**今まで**: ...

**今後**: ...

Writing rules:

Rules	Description
Language	Japanese
Put each feature in an independent section	#### N. 機能名 numbered with
"Before" describes the problem	Concretely write the inconvenience the user experienced
"After" shows the solution	What changes and how + concrete examples (code/output)
Always include concrete examples	Command examples, output examples, Plans.md snippets, etc.
Keep technical details to a minimum	File names and step numbers as supplementary notes in "After"
Long is OK	3–10 lines per feature. Readability is the top priority

Step 4: Update version file

echo "$NEW_VERSION" > VERSION
# package.json がある場合
jq --arg v "$NEW_VERSION" '.version = $v' package.json > tmp && mv tmp package.json
# .claude-plugin/plugin.json がある場合
jq --arg v "$NEW_VERSION" '.version = $v' .claude-plugin/plugin.json > tmp && mv tmp .claude-plugin/plugin.json

Step 5: Commit & Tag

git add CHANGELOG.md VERSION package.json .claude-plugin/plugin.json
git commit -m "chore: release v$NEW_VERSION"
git tag -a "v$NEW_VERSION" -m "Release v$NEW_VERSION"
git push origin main --tags

Step 6: Create GitHub Release

gh release create "v$NEW_VERSION" \
  --title "v$NEW_VERSION - $(head -n 2 CHANGELOG.md | tail -n 1)" \
  --notes "$(cat <<'EOF'
## What's Changed

**[変更の概要]**

### Before / After

| Before | After |
|--------|-------|
| 旧状態 | 新状態 |

---

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

GitHub Release Notes Format

Required elements:

• ## What's Changed Sections
• Boldone-line summary
• Before / After Table
• Generated with [Claude Code](...) Footer
• Language: English(Japanese prohibited)

PM Handoff

Completion report to PM after release:

## リリース完了報告

**バージョン**: v{{NEW_VERSION}}
**リリース日**: {{DATE}}

### 実施内容
{{CHANGELOG の内容}}

### GitHub Release
{{URL}}

### 次のアクション
- PM によるリリースノートの確認
- 本番環境へのデプロイ（該当する場合）

Related skills

• review — Perform code review before release
• execute — Implement the next task after release
• plan — Create a plan for the next version