mcpField
P
pull-request-msg-with-gh

pull-request-msg-with-gh

github.com/rshade開発391 回インストール3 週間前に更新
リポジトリ

pull-request-msg-with-gh について

現在のセッションの変更内容と会話をもとに `PR_MESSAGE.md` を作成するスキルです。プルリクエストの説明を準備する開発者向けで、GitHub で関連 issue を検索し、コミット形式と Markdown の検証も行います。

主な機能

  1. 01会話と Git の変更を確認
  2. 02GitHub で issue を検索
  3. 03`PR_MESSAGE.md` を生成
  4. 04ファイルを `.gitignore` に追加
  5. 05コミット形式と Markdown を検証

活用シーン

  1. 01開発セッションの PR 説明を作成
  2. 02プルリクエストに関連する GitHub issue を特定
  3. 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 がなければ、処理を進めないでください。

ワークフロー

  1. セッションのコンテキストを分析する — 現在のセッションで行った変更を確認します。会話履歴に加えて、git diff と git status で変更されたファイルを調べ、作業の全容を把握してください。どちらの情報源もプルリクエストメッセージの作成に使用します。
  2. Issue 番号を検出する — 以下の Issue 検出アルゴリズムを使用します。ユーザーが関連する Issue はないと明示した場合は、Closes #<issue-number> のフッターを完全に省略してください。
  3. コミットタイプを決定する — 変更の内容に基づいて決定します(タイプの一覧は references/pr-message-format.md を参照)
  4. PR_MESSAGE.md を作成する — references/pr-message-format.md の形式を使用します
  5. .gitignore に追加する — まだ存在しない場合は PR_MESSAGE.md を追加します
  6. 検証する — 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. 結果がちょうど 1 件で、タイトルに最も多くのキーワードが含まれている場合 → その Issue を使用します
  2. 結果が 0 件の場合 → ユーザーに Issue 番号を尋ねます
  3. 結果が 2 件以上の場合 → 選択肢を示してユーザーに選んでもらいます
  4. 一致が曖昧な場合 → ユーザーに確認を求めます
Issue 番号の抽出元として使用しないもの
  • ブランチ名の数字(例:125- は Issue #125 ではありません)
  • spec フォルダー名(例:specs/125-xyz/)
  • ワークツリーのフォルダー名

これらは内部識別子であり、GitHub の Issue 番号ではありません。

重要なルール

  1. 重複を避ける — 要約にはコミットの件名に加えて、追加のコンテキストを含める必要があります
  2. ## Commit Message セクションを作成しない — 1 行目がコミットメッセージそのものです
  3. .markdownlint.json は変更しない — 代わりに CLI フラグを使用します
  4. 末尾の改行 — ファイルの末尾は改行 1 つにしてください
  5. 曖昧な場合は確認する — 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

検証を黙って省略しないでください。

問題を修正し、成功を報告する前に再検証してください。

コメント