release-package-version
について
このスキルはRパッケージの完全なリリースサイクルを自動化し、バージョン更新、NEWS.mdの編集、gitタグ付け、GitHubリリース作成を処理します。新規パッチ、マイナー、メジャーリリースの準備時、CRAN承認後、または次の開発バージョンの設定時に使用されます。このツールは、バージョン増分からリリース後の設定まで、ワークフロー全体を管理します。
クイックインストール
Claude Code
推奨npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/release-package-versionこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
name: release-package-version description: > RパッケージのリリースサイクルをすべてとおしてI実行する。バージョンバンプ、 NEWS.mdの更新、gitタグ付け、GitHubリリースの作成、リリース後の開発バージョン設定を含む。 パッケージが新しいパッチ、マイナー、またはメジャーリリースの準備完了時、 CRANへの承認後に対応するGitHubリリースを作成する時、またはリリース直後に 開発バージョンバンプを設定する時に使用する。 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: r-packages complexity: intermediate language: R tags: r, versioning, release, git-tags, changelog
パッケージバージョンのリリース
Rパッケージの完全なバージョンリリースサイクルを実行する。
使用タイミング
- 新しいバージョンをリリースする準備ができた時(バグ修正、機能追加、または破壊的変更)
- CRANへの承認後に対応するGitHubリリースを作成する時
- リリース後の開発バージョンを設定する時
入力
- 必須: リリース準備が完了した変更を持つパッケージ
- 必須: リリースタイプ:patch(0.1.0 -> 0.1.1)、minor(0.1.0 -> 0.2.0)、またはmajor(0.1.0 -> 1.0.0)
- 任意: CRANに投稿するかどうか(デフォルト:いいえ、別途
submit-to-cranスキルを使用)
手順
ステップ1: バージョンバンプの決定
セマンティックバージョニングに従う:
| 変更タイプ | バージョンバンプ | 例 |
|---|---|---|
| バグ修正のみ | Patch | 0.1.0 -> 0.1.1 |
| 新機能(後方互換) | Minor | 0.1.0 -> 0.2.0 |
| 破壊的変更 | Major | 0.1.0 -> 1.0.0 |
期待結果: 最後のリリース以降の変更の性質に基づいて正しいバンプタイプ(patch、minor、またはmajor)が決定される。
失敗時: 不明な場合は最後のタグ以降のgit logを確認して各変更を分類する。API破壊的変更はメジャーバンプが必要。
ステップ2: バージョンの更新
usethis::use_version("minor") # または"patch"または"major"
これによりDESCRIPTIONのVersionフィールドが更新され、NEWS.mdに見出しが追加される。
期待結果: DESCRIPTIONのバージョンが更新される。NEWS.mdにリリースバージョンの新しいセクション見出しが追加される。
失敗時: usethis::use_version()が利用できない場合、DESCRIPTIONのVersionフィールドを手動で更新し、NEWS.mdに# packagename x.y.z見出しを追加する。
ステップ3: NEWS.mdの更新
新しいバージョン見出しの下にリリースノートを記入する:
# packagename 0.2.0
## New Features
- Added `new_function()` for processing data (#42)
- Support for custom themes in `plot_results()` (#45)
## Bug Fixes
- Fixed crash when input contains all NAs (#38)
- Corrected off-by-one error in `window_calc()` (#41)
## Minor Improvements
- Improved error messages for invalid input types
- Updated documentation examples
トレーサビリティのためにイシュー/PR番号を使用する。
期待結果: NEWS.mdにカテゴリ別に整理されたユーザー向けの変更の完全なまとめが含まれ、トレーサビリティのためにイシュー/PR番号が付いている。
失敗時: 変更の再構築が困難な場合はgit log --oneline v<previous>..HEADを使用して最後のリリース以降のすべてのコミットをリストアップして分類する。
ステップ4: 最終チェック
devtools::check()
devtools::spell_check()
urlchecker::url_check()
期待結果: devtools::check()が0エラー、0警告、0ノートを返す。スペルチェックとURLチェックで問題が見つからない。
失敗時: リリース前にすべてのエラーと警告を修正する。スペルチェッカーの誤検知にはinst/WORDLISTに単語を追加する。壊れたURLを置き換える。
ステップ5: リリースのコミット
git add DESCRIPTION NEWS.md
git commit -m "Release packagename v0.2.0"
期待結果: DESCRIPTIONのバージョンバンプと更新されたNEWS.mdを含む単一のコミット。
失敗時: 他のコミットされていない変更が存在する場合は、DESCRIPTIONとNEWS.mdのみをステージングする。リリースコミットにはバージョン関連の変更のみを含めること。
ステップ6: リリースのタグ付け
git tag -a v0.2.0 -m "Release v0.2.0"
git push origin main --tags
期待結果: アノテーション付きタグv0.2.0が作成されてリモートにプッシュされる。git tag -lでローカルにタグが表示され、git ls-remote --tags originでリモートに確認できる。
失敗時: プッシュが失敗する場合は書き込みアクセスがあることを確認する。タグが既に存在する場合はgit show v0.2.0で正しいコミットを指しているか確認する。
ステップ7: GitHubリリースの作成
gh release create v0.2.0 \
--title "packagename v0.2.0" \
--notes-file NEWS.md
または以下を使用する:
usethis::use_github_release()
期待結果: リポジトリのReleasesページにリリースノートが表示されたGitHubリリースが作成される。
失敗時: gh release createが失敗する場合はgh auth statusでghCLIが認証されているか確認する。usethis::use_github_release()が失敗する場合はGitHubで手動でリリースを作成する。
ステップ8: 開発バージョンの設定
リリース後、開発バージョンにバンプする:
usethis::use_dev_version()
これにより開発中を示す0.2.0.9000にバージョンが変更される。
git add DESCRIPTION NEWS.md
git commit -m "Begin development for next version"
git push
期待結果: DESCRIPTIONのバージョンが0.2.0.9000(開発バージョン)になる。NEWS.mdに開発バージョンの新しい見出しが追加される。変更がリモートにプッシュされる。
失敗時: usethis::use_dev_version()が利用できない場合、DESCRIPTIONのバージョンを手動でx.y.z.9000に変更し、NEWS.mdに# packagename (development version)見出しを追加する。
バリデーション
- DESCRIPTIONのバージョンが意図したリリースと一致する
- NEWS.mdに完全で正確なリリースノートがある
-
R CMD checkがパスする - gitタグがバージョンと一致する(例:
v0.2.0) - GitHubリリースがリリースノートとともに存在する
- リリース後の開発バージョンが設定されている(x.y.z.9000)
よくある落とし穴
- タグのプッシュ忘れ:
git pushだけではタグはプッシュされない。--tagsを使用するかgit push origin v0.2.0を使用する - NEWS.md形式: pkgdown/CRANが期待するMarkdown見出し形式を使用する
- 間違ったコミットへのタグ付け: 常にバージョンバンプコミットの後にタグを付ける
- CRANに既に存在するバージョン: CRANは既に公開されているバージョンを受け付けない。常にインクリメントする
- リリースに開発バージョンを含める: CRANに
.9000バージョンを決して投稿しないこと
関連スキル
submit-to-cran- バージョンリリース後のCRAN投稿create-github-release- 一般的なGitHubリリースの作成setup-github-actions-ci- リリース時にpkgdownの再ビルドをトリガーするbuild-pkgdown-site- ドキュメントサイトが新しいバージョンを反映する
GitHub リポジトリ
関連スキル
llamaguard
その他LlamaGuardは、暴力やヘイトスピーチなど6つの安全性カテゴリーにおいて、LLMの入力と出力をモデレートするMetaの70-80億パラメータモデルです。94〜95%の精度を提供し、vLLM、Hugging Face、Amazon SageMakerを使用してデプロイ可能です。このスキルを使用して、AIアプリケーションにコンテンツフィルタリングと安全策を簡単に統合できます。
cost-optimization
その他このClaudeスキルは、リソースの適正サイジング、タグ付け戦略、支出分析を通じて、開発者がクラウドコストを最適化することを支援します。AWS、Azure、GCPにわたるクラウド支出の削減とコストガバナンスの実施のためのフレームワークを提供します。インフラコストの分析、リソースの適正サイジング、または予算制約への対応が必要な際にご利用ください。
quantizing-models-bitsandbytes
その他このスキルは、bitsandbytesを使用してLLMを8ビットまたは4ビット精度に量子化し、精度の低下を最小限に抑えつつ50〜75%のメモリ削減を実現します。限られたGPUメモリでより大規模なモデルを実行したり、推論を高速化するのに理想的で、INT8、NF4、FP4などのフォーマットをサポートしています。HuggingFace Transformersと統合され、QLoRAトレーニングや8ビットオプティマイザーを可能にします。
dispatching-parallel-agents
その他このClaudeスキルは、複数のエージェントを配備し、3つ以上の独立した問題を並行して調査・修正します。共有状態や依存関係がなく解決可能な、無関係な障害が発生するシナリオ向けに設計されています。中核となる機能は並列問題解決であり、効率を最大化するために独立した問題領域ごとに1つのエージェントを割り当てます。
