OpenSkillIndex← back to search
claude-code

Agent-almanac create-github-release

install
source · Clone the upstream repo
git clone https://github.com/pjt222/agent-almanac
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/create-github-release" ~/.claude/skills/pjt222-agent-almanac-create-github-release-e2ea6a && rm -rf "$T"
manifest: i18n/ja/skills/create-github-release/SKILL.md
source content

GitHubリリースの作成

タグ付きGitHubリリースをリリースノートとオプションの成果物とともに作成する。

使用タイミング

  • ソフトウェアの安定バージョンを配布用にマークするとき
  • ライブラリやアプリケーションの新バージョンを公開するとき
  • ステークホルダー向けのリリースノートを作成するとき
  • ビルド成果物（バイナリ、tarball）を配布するとき

入力

  • 必須: バージョン番号（セマンティックバージョニング）
  • 必須: 前回リリースからの変更点の概要
  • 任意: 添付するビルド成果物
  • 任意: プレリリースかどうか

手順

ステップ1: バージョン番号の決定

セマンティックバージョニング（

MAJOR.MINOR.PATCH
）に従う:

変更の種類例タイミング
MAJOR1.0.0 -> 2.0.0破壊的変更
MINOR1.0.0 -> 1.1.0後方互換性のある新機能
PATCH1.0.0 -> 1.0.1バグ修正のみ

期待結果： 前回リリースからの変更の範囲を正確に反映するバージョン番号が選択される。

失敗時： 変更が破壊的かどうか不明な場合、公開APIの差分をレビューする。エクスポートされた関数の削除またはシグネチャ変更はすべて、MAJORのバンプが必要な破壊的変更である。

ステップ2: プロジェクトファイルのバージョン更新

  • DESCRIPTION
    （Rパッケージ）
  • package.json
    （Node.js）
  • Cargo.toml
    （Rust）
  • pyproject.toml
    （Python）

期待結果： バージョン番号が適切なプロジェクトファイルで更新され、バージョン管理にコミットされる。

失敗時： 前の手順（例: Rの 

usethis::use_version()
）でバージョンがすでに更新されている場合、意図したリリースバージョンと一致しているか確認する。

ステップ3: リリースノートの作成

チェンジログを作成または更新する。カテゴリ別に整理する:

## What's Changed

### New Features
- Added user authentication (#42)
- Support for custom themes (#45)

### Bug Fixes
- Fixed crash on empty input (#38)
- Corrected date parsing in UTC (#41)

### Improvements
- Improved error messages
- Updated dependencies

### Breaking Changes
- `old_function()` renamed to `new_function()` (#50)

**Full Changelog**: https://github.com/user/repo/compare/v1.0.0...v1.1.0

期待結果： リリースノートがカテゴリ別（機能、修正、破壊的変更）に整理され、トレーサビリティのためにIssue/PRの参照が含まれている。

失敗時： 変更の分類が難しい場合、

git log v1.0.0..HEAD --oneline
で前回リリース以降の変更リストを再構成する。

ステップ4: Gitタグの作成

git tag -a v1.1.0 -m "Release v1.1.0"
git push origin v1.1.0

期待結果： アノテーション付きタグ 

v1.1.0
がローカルとリモートに存在する。
git tag -l
にタグが表示される。

失敗時： タグがすでに存在する場合、

git tag -d v1.1.0 && git push origin :refs/tags/v1.1.0
で削除してから再作成する。プッシュが拒否される場合、リモートへの書き込みアクセス権があるか確認する。

ステップ5: GitHubリリースの作成

GitHub CLI使用（推奨）:

gh release create v1.1.0 \
  --title "v1.1.0" \
  --notes-file CHANGELOG.md

成果物を添付する場合:

gh release create v1.1.0 \
  --title "v1.1.0" \
  --notes "Release notes here" \
  build/app-v1.1.0.tar.gz \
  build/app-v1.1.0.zip

プレリリースの場合:

gh release create v2.0.0-beta.1 \
  --title "v2.0.0 Beta 1" \
  --prerelease \
  --notes "Beta release for testing"

期待結果： GitHubにリリースがタグ、ノート、添付成果物（ある場合）とともに表示される。

失敗時： 

gh
が認証されていない場合、
gh auth login
を実行する。タグがリモートに存在しない場合、先に 
git push origin v1.1.0
でプッシュする。

ステップ6: リリースノートの自動生成

GitHubはマージされたPRからノートを自動生成できる:

gh release create v1.1.0 \
  --title "v1.1.0" \
  --generate-notes


.github/release.yml
でカテゴリを設定する:

changelog:
  categories:
    - title: New Features
      labels:
        - enhancement
    - title: Bug Fixes
      labels:
        - bug
    - title: Documentation
      labels:
        - documentation
    - title: Other Changes
      labels:
        - "*"

期待結果： リリースノートがマージされたPRのタイトルからラベル別にカテゴリ化されて自動生成される。

.github/release.yml
でカテゴリが制御される。

失敗時： 自動生成ノートが空の場合、PRがクローズではなくマージされていること、ラベルが割り当てられていることを確認する。代替手段としてノートを手動で記述する。

ステップ7: リリースの確認

# List releases
gh release list

# View specific release
gh release view v1.1.0

期待結果： 

gh release list
に新しいリリースが表示される。
gh release view
に正しいタイトル、タグ、ノート、アセットが表示される。

失敗時： リリースが見つからない場合、Actionsタブで失敗したリリースワークフローを確認する。

git tag -l
でタグが存在するか確認する。

バリデーション

  • バージョンタグがセマンティックバージョニングに従っている
  • Gitタグが正しいコミットを指している
  • リリースノートが変更を正確に説明している
  • 成果物（ある場合）が添付されダウンロード可能である
  • GitHubリポジトリページにリリースが表示されている
  • プレリリースフラグが正しく設定されている

よくある落とし穴

  • 誤ったコミットへのタグ付け: タグ付け前に必ず 
    git log
    を確認する。バージョンバンプのコミット後にタグ付けする。
  • タグのプッシュ忘れ: 
    git push
    はタグをプッシュしない。
    git push --tags
    または 
    git push origin v1.1.0
    を使用する。
  • バージョン形式の不統一: 
    v1.0.0
    と 
    1.0.0
    のどちらかに決めて統一する。
  • 空のリリースノート: 常に意味のあるノートを提供する。ユーザーは何が変わったかを知る必要がある。
  • タグの削除と再作成: プッシュ後のタグ変更は避ける。必要であれば新しいバージョンを作成する。

関連スキル

  • commit-changes
    - ステージングとコミットのワークフロー
  • manage-git-branches
    - リリース準備のためのブランチ管理
  • release-package-version
    - R固有のリリースワークフロー
  • configure-git-repository
    - Gitセットアップの前提条件
  • setup-github-actions-ci
    - CIを通じたリリースの自動化