mcpField
C
create-release-checklist

create-release-checklist

github.com/posit-dev開発551713 回インストール今日更新
リポジトリ

create-release-checklist について

R パッケージのリリースチェックリストを生成し、GitHub issue を作成できるスキルです。パッケージのバージョンと NEWS.md からリリース種別を提案し、issue 作成前に内容を調整できます。

主な機能

  1. 01パッケージのバージョンと NEWS.md の確認
  2. 02メジャー、マイナー、パッチを提案
  3. 03リリースチェックリストの生成
  4. 04チェックリスト内容のカスタマイズ
  5. 05gh による GitHub issue の作成

活用シーン

  1. 01次回の R パッケージリリース用チェックリストを準備
  2. 02リリース作業を調整して GitHub で管理
  3. 03リリースチェックリストの issue を作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/posit-dev/skills --skill create-release-checklist

インストール後、Claude Code で/create-release-checklistを入力して読み込まれたか確認します。

同梱ファイルscripts/generate_checklist.R

詳細

R パッケージのリリースチェックリストを作成する

R パッケージのリリースチェックリストを生成し、対応する GitHub issue を作成します。

概要

このスキルでは、以下の手順で GitHub 上に R パッケージのリリースチェックリスト issue を作成します。

  • 現在のバージョンを確認し、リリースの種類を尋ねます。
  • 初期チェックリストを生成します。
  • 追加のカスタマイズについてユーザーに尋ねます。
  • 最終チェックリストから GitHub issue を作成します。

前提条件

  • 作業ディレクトリが R パッケージであり、ルートに DESCRIPTION ファイルがあること。
  • R パッケージ usethis が利用可能であること。

issue の自動作成を有効にするには、以下も必要です。

  • gh CLI がインストールされ、認証済みであること。
  • R パッケージが GitHub リポジトリに関連付けられていること。

ワークフロー

ステップ 1：検証

まず、前提条件が満たされているか、効率化のため以下の順序で確認します。

  1. 作業ディレクトリに DESCRIPTION という名前のファイルがあることを確認します。ない場合は、R パッケージのルートディレクトリから実行する必要があることをユーザーに伝え、停止します。
  2. Rscript -e 'utils::packageVersion("usethis")' を使って、usethis パッケージがインストールされているか確認します。インストールされていない場合は、install.packages("usethis") でインストールするようユーザーに案内し、停止します。
  3. リポジトリの GitHub URL が存在する場合は、それを特定します。まず gh repo view --json url を試します。失敗した場合は、エラーを診断します。
    • gh がインストールされていない場合は、GitHub URL を探すために git remote -v を実行してみます。
    • ローカルリポジトリに GitHub リモートがない場合は、usethis::use_github() を使ってパッケージを GitHub に接続するようユーザーに提案します。このコマンドを代わりに実行することを申し出ます。ユーザーが断った場合は、GitHub URL なしで続行します。
    • gh がインストールされているものの認証されておらず、リポジトリに GitHub リモートがある場合は、gh auth login を実行するようユーザーに提案します。

いずれかの確認に失敗した場合は、問題の内容と解決方法を明確にユーザーに伝え、ワークフローを停止します。すべての前提条件が満たされるまで、次のステップに進まないでください。

ステップ 2：初期化

次に、現在のパッケージ名とバージョンを特定します。 DESCRIPTION ファイルを読み取り、Version: と Package: のフィールドを抽出します。

次に、NEWS.md ファイルがあるか確認します。ある場合は、最初のセクション（通常は最新の未リリースの変更）を読み、どのような変更が行われたかを把握します。これをもとに、適切なリリースの種類を提案します。

  • NEWS に「breaking changes」、「breaking」、「BREAKING」などの表現がある場合は、メジャーリリースを提案します。
  • NEWS に新機能の記載がなく、「bug fixes」、「fixes」、「patch」などの表現のみがある場合は、パッチリリースを提案します。
  • それ以外（新機能、改善、機能強化）の場合は、マイナーリリースを提案します。

現在のバージョンをユーザーに表示し、AskUserQuestion ツールを使ってリリースの種類を尋ねます。提案するリリースの種類を最初の選択肢にし、ラベルに「(Recommended)」を付けます。

質問：「これはどの種類のリリースですか？」 ヘッダー：「リリースの種類」 選択肢（推奨する選択肢を先頭に表示）：

  • Major (X.0.0) - 破壊的変更（提案する場合は「(Recommended)」を追加）
  • Minor (x.X.0) - 破壊的変更を伴わない新機能（提案する場合は「(Recommended)」を追加）
  • Patch (x.x.X) - バグ修正のみ（提案する場合は「(Recommended)」を追加）

ユーザーの回答に従って現在のバージョンを変更し、新しいバージョンを計算します。例：

  • 現在のバージョン 1.2.3 ＋ Major リリース → 2.0.0
  • 現在のバージョン 1.2.3 ＋ Minor リリース → 1.3.0
  • 現在のバージョン 1.2.3 ＋ Patch リリース → 1.2.4
  • 現在のバージョン 0.2.1.9000 ＋ Patch リリース → 0.2.2
  • 現在のバージョン 0.2.1.9003 ＋ Minor リリース → 0.3.0

注：現在のバージョンが .9xxx で終わる場合（R 形式の開発バージョン）は、新しいバージョンを計算する前にそのサフィックスを削除します。

表示：「${PACKAGE_NAME} ${CURRENT_VERSION} → ${NEW_VERSION} のリリースチェックリストを準備しています」。

ステップ 3：チェックリストの生成

このスキルに含まれている scripts/generate_checklist.R スクリプトを使用して、最初のチェックリストを生成します。

# If the GitHub URL is known:
Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}" "${GITHUB_URL}"

# Otherwise:
Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}"

（${SKILL_DIR} は、このスキルがインストールされているディレクトリを表します。）

出力内の「Setting active project...」という行は無視してください。

生成されたチェックリスト（Markdown 形式）を読み取り、ユーザーに表示します。

ステップ 4：ユーザーによるカスタマイズ

AskUserQuestion ツールを使用して、次の質問をします。

質問：「issue を作成する前に、チェックリストをカスタマイズしますか？」 ヘッダー：「カスタマイズしますか？」 選択肢：

  • いいえ、このまま issue を作成する
  • はい、カスタマイズする

ユーザーがチェックリストのカスタマイズを希望する場合は、反復的な調整ループに入ります。

  1. 次のように質問します：「追加する項目や、安全に削除できる項目を提案してください。または、これ以上変更の希望がないことを確認してください。」
  2. ユーザーのフィードバックに基づいて、チェックリストを更新します（項目の追加、削除、表現の変更など）。適切なチェックボックス構文（タスクには - [ ]）を使用し、チェックリストを Markdown 形式に保ちます。
  3. 更新したチェックリストをユーザーに表示します。
  4. 次のように質問します：「これでよさそうですか？それとも、ほかに提案がありますか？」
  5. ユーザーに追加の提案がある場合は、ステップ 2 に戻ります。問題ないと確認された場合は、ループを終了し、ステップ 5 に進みます。

この処理中、チェックリストは Markdown 文字列として保持します。これにより、GitHub issue 作成コマンドに簡単に渡せます。

ステップ 5：GitHub issue の作成

最終的なチェックリストは、適切なセクションとチェックボックスを含む Markdown 形式にします。

gh が利用可能で、認証済みの場合は、チェックリストの内容を標準入力経由で直接渡して、GitHub issue を作成します。

gh issue create \
  --title "Release ${PACKAGE_NAME} ${NEW_VERSION}" \
  --body-file - <<'EOF'
[checklist content here]
EOF

その後、ユーザーに次の内容を表示します。

  • issue の URL を含む成功メッセージ。
  • 「チェックリストのタスクを進めるには、do-release-checklist スキルを使用できます。」という提案。（注：これは、ユーザーがチェックリストの項目を実行できるよう支援する関連スキルです。このスキルがまだリポジトリに存在しない場合、この提案は省略できます。）

gh が利用できない場合は、チェックリストをユーザーに表示し、GitHub issue を手動で作成するよう案内します。

  • 推奨する issue タイトルを表示します：「Release ${PACKAGE_NAME} ${NEW_VERSION}」
  • Markdown 形式のチェックリスト全体を表示します。
  • 内容をコピーし、リポジトリの issues ページから issue を手動で作成するようユーザーに案内します。

エラー処理

GitHub issue の作成に失敗した場合（gh を使用した場合）、よくある問題を確認します。

  • 認証エラー：gh auth status でユーザーがログインしていることを確認します。必要に応じて gh auth login を実行するよう提案します。
  • リポジトリの権限：issue を作成するには、ユーザーに書き込み権限が必要です。gh repo view で適切な権限があることを確認します。
  • ネットワークエラー：接続に問題がある場合は、コマンドを再実行するか、インターネット接続を確認するよう提案します。
  • 無効な Markdown：issue の本文に書式エラーがある場合は、チェックリストの Markdown が正しく、有効な構文になっていることを確認します。

issue の作成に失敗した場合は、チェックリストの内容を保持し、次のいずれかを提案します。

  • コマンドを再試行する。
  • 代わりに、手動で issue を作成できるようチェックリストを表示する。

コメント

Markdown 対応