create-github-release

pjt222

Aktualisiert Yesterday

6 Ansichten

Metageneral

Über

Diese Claude Skill erstellt GitHub-Releases mit korrekter Versionierung, Release-Notes und optionalen Build-Artefakten. Sie verarbeitet semantische Versionierung und Changelog-Generierung mithilfe der GitHub CLI und eignet sich ideal zum Markieren stabiler Versionen oder zur Verteilung neuer Bibliotheks-/Anwendungs-Releases. Entwickler können damit Versionen mit angehängten Binärdateien veröffentlichen und Release-Notes für Stakeholder generieren.

Schnellinstallation

Claude Code

Dokumentation

name: create-github-release description: > 適切なタグ付け、リリースノート、オプションのビルド成果物を含む GitHubリリースを作成します。セマンティックバージョニング、チェンジログ生成、GitHub CLIの使用方法を網羅。安定バージョンを配布用にマーク、ライブラリやアプリケーションの新バージョン公開、ステークホルダー向けリリースノート作成、ビルド成果物の配布時に使用。 locale: ja source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: basic language: multi tags: github, release, git-tags, changelog, versioning

GitHubリリースの作成

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

使用タイミング

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

入力

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

手順

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

セマンティックバージョニング（MAJOR.MINOR.PATCH）に従う:

変更の種類	例	タイミング
MAJOR	1.0.0 -> 2.0.0	破壊的変更
MINOR	1.0.0 -> 1.1.0	後方互換性のある新機能
PATCH	1.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 のどちらかに決めて統一する。
空のリリースノート: 常に意味のあるノートを提供する。ユーザーは何が変わったかを知る必要がある。
タグの削除と再作成: プッシュ後のタグ変更は避ける。必要であれば新しいバージョンを作成する。

GitHub Repository

pjt222/agent-almanac

Pfad: i18n/ja/skills/create-github-release

agentsagentskillsai-assisted-developmentclaude-codeskillsteams