pull-request-msg-with-gh について
現在のセッションの変更内容と会話をもとに `PR_MESSAGE.md` を作成するスキルです。プルリクエストの説明を準備する開発者向けで、GitHub で関連 issue を検索し、コミット形式と Markdown の検証も行います。
主な機能
- 01会話と Git の変更を確認
- 02GitHub で issue を検索
- 03`PR_MESSAGE.md` を生成
- 04ファイルを `.gitignore` に追加
- 05コミット形式と Markdown を検証
活用シーン
- 01開発セッションの PR 説明を作成
- 02プルリクエストに関連する GitHub issue を特定
- 03PR メッセージの形式と Markdown を確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ rshade/ agent-skills --skill pull-request-msg-with-ghインストール後、Claude Code で/pull-request-msg-with-ghを入力して読み込まれたか確認します。
同梱ファイルevals/evals.jsonreferences/pr-message-format.md
詳細
プルリクエストメッセージジェネレーター
現在のセッションでの作業を要約した PR_MESSAGE.md ファイルを生成します。
対象のリポジトリで gh CLI に認証済みである必要があります。
前提条件の確認
gh --version 2>/dev/null && gh auth status 2>/dev/null
gh がインストールされていない場合は、処理を中止して次の内容を報告してください。
- https://cli.github.com からインストールしてください
ghは npm ではインストールできません- インストール後、
gh auth loginを実行して認証してください
動作する認証済みの gh CLI がなければ、処理を進めないでください。
ワークフロー
- セッションのコンテキストを分析する — 現在のセッションで行った変更を確認します。会話履歴に加えて、
git diffとgit statusで変更されたファイルを調べ、作業の全容を把握してください。どちらの情報源もプルリクエストメッセージの作成に使用します。 - Issue 番号を検出する — 以下の Issue 検出アルゴリズムを使用します。ユーザーが関連する Issue はないと明示した場合は、
Closes #<issue-number>のフッターを完全に省略してください。 - コミットタイプを決定する — 変更の内容に基づいて決定します(タイプの一覧は
references/pr-message-format.mdを参照) - PR_MESSAGE.md を作成する —
references/pr-message-format.mdの形式を使用します - .gitignore に追加する — まだ存在しない場合は
PR_MESSAGE.mdを追加します - 検証する — commitlint と markdownlint のチェックを実行します
Issue 番号の検出
Issue 番号は、ブランチ名から数字を抽出するのではなく、GitHub を検索して特定する必要があります。
アルゴリズム
# Step 1: Get branch name
BRANCH=$(git branch --show-current)
# Step 2: Extract keywords (strip leading numbers and hyphens)
# Example: "125-greenops-equivalencies" → "greenops equivalencies"
KEYWORDS=$(echo "$BRANCH" | sed 's/^[0-9]*-//' | tr '-' ' ')
# Step 3: Search GitHub issues
gh issue list --search "$KEYWORDS" --state all \
--json number,title --limit 5
評価ルール
- 結果がちょうど 1 件で、タイトルに最も多くのキーワードが含まれている場合 → その Issue を使用します
- 結果が 0 件の場合 → ユーザーに Issue 番号を尋ねます
- 結果が 2 件以上の場合 → 選択肢を示してユーザーに選んでもらいます
- 一致が曖昧な場合 → ユーザーに確認を求めます
Issue 番号の抽出元として使用しないもの
- ブランチ名の数字(例:
125-は Issue #125 ではありません) - spec フォルダー名(例:
specs/125-xyz/) - ワークツリーのフォルダー名
これらは内部識別子であり、GitHub の Issue 番号ではありません。
重要なルール
- 重複を避ける — 要約にはコミットの件名に加えて、追加のコンテキストを含める必要があります
## Commit Messageセクションを作成しない — 1 行目がコミットメッセージそのものです.markdownlint.jsonは変更しない — 代わりに CLI フラグを使用します- 末尾の改行 — ファイルの末尾は改行 1 つにしてください
- 曖昧な場合は確認する — Issue 検索結果が 0 件、2 件以上、または不明確な場合は、ユーザーに確認してください
検証
現在のコンテキストで commitlint と markdownlint のスキルが利用可能な場合は、それらを使用して PR_MESSAGE.md を検証してください。利用できない場合は、次を直接実行してください。
# Validate commit message format
cat PR_MESSAGE.md | npx commitlint
# Validate markdown (MD041 disabled — first line is commit subject,
# not heading)
npx markdownlint --disable MD041 -- PR_MESSAGE.md
スキルも npx も利用できない場合は、必ず失敗として扱ってください。
- commitlint をインストールします:
npm install -g @commitlint/cli @commitlint/config-conventional - markdownlint をインストールします:
npm install -g markdownlint-cli
検証を黙って省略しないでください。
問題を修正し、成功を報告する前に再検証してください。
コメント
Markdown 対応