Skills-SIMarket
skills-si.com
Proposer une Skill
/
L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

create-github-release

create-github-release

適切なタグ付け、リリースノート、オプションのビルド成果物を含む GitHubリリースを作成します。セマンティックバージョニング、 チェンジログ生成、GitHub CLIの使用方法を網羅。安定バージョンを 配布用にマーク、ライブラリやアプリケーションの新バージョン公開、 ステークホルダー向けリリースノート作成、ビルド成果物の配布時に使用。

Independent GitHub snapshot · Automated classification · Original documentation governs

Ppjt222 / agent-almanacMIT

Documentation de la Skill

GitHub

name: create-github-release description: > 適切なタグ付け、リリースノート、オプションのビルド成果物を含む GitHubリリースを作成します。セマンティックバージョニング、 チェンジログ生成、GitHub CLIの使用方法を網羅。安定バージョンを 配布用にマーク、ライブラリやアプリケーションの新バージョン公開、 ステークホルダー向けリリースノート作成、ビルド成果物の配布時に使用。 locale: ja source_locale: en source_commit: 6f65f316 fence_basis_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）に従う:

変更の種類例タイミング
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を通じたリリースの自動化

More skills to explore

Voir toutes les Skills
Skills enregistrées