mcpField
W
write-pr

write-pr

github.com/2ykwang開発1991 回インストール14 週間前に更新
リポジトリ

write-pr について

write-prは、現在のブランチの変更からPRのタイトルと本文を作成する読み取り専用スキルです。履歴、差分、プロジェクトの慣例やPRテンプレートを確認し、PRの作成やプッシュは行いません。

主な機能

  1. 01ベースブランチの検出
  2. 02コミット履歴と差分の分析
  3. 03プロジェクトのPRテンプレート確認
  4. 04既存のタイトル慣例への準拠
  5. 05タイトルとPR本文の下書き

活用シーン

  1. 01ブランチのPR説明文の準備
  2. 02リポジトリのPRテンプレート記入
  3. 03プロジェクトの形式に沿ったPRタイトル作成

インストール

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

$npx skills add https://github.com/2ykwang/agent-skills --skill write-pr

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

同梱ファイルREADME.ko.mdREADME.md

詳細

PR を作成する

現在のブランチの変更内容を、プロジェクト既存の慣例に沿った PR のタイトルと本文にまとめます。ファイル名だけでなく、Git の履歴と差分を分析して変更の意図を把握してください。

このスキルを使用する場合

  • 現在のブランチのプルリクエストの説明を作成、または下書きする場合
  • プロジェクトのコミット／PR のスタイルに沿った PR タイトルを作成する場合
  • 実際のコード変更に基づいて PR テンプレートに記入する場合

このスキルを使用しない場合

  • プルリクエストを実際に作成、またはプッシュする依頼の場合
  • ベースブランチより先行するコミットがない場合
  • ユーザーが PR の説明ではなく、コミットメッセージのみを求めている場合

このスキルは読み取り専用です。状態を変更するコマンドは絶対に実行しないでください：gh pr create、gh pr edit、git push、その他の書き込み操作。

コンテキスト

ユーザーは、現在のブランチでの変更内容に基づいた、そのまま使える PR タイトルと本文を求めています。生の差分出力ではなく、意図と影響に注目してください。プロジェクト既存の PR スタイルに従ってください。

手順

ステップ 1：ベースブランチを特定する

$ARGUMENTS が指定されている場合は、それをベースブランチとして使用してください。

指定されていない場合は、次の順序で自動検出します。

  1. git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null を実行し、ブランチ名を取得します（例：origin/main → main）
  2. 失敗した場合は、main、master、develop のうち存在するものを確認します：git branch -r | grep -E 'origin/(main|master|develop)'
  3. 最初に見つかったものを使用します
ステップ 2：変更情報を収集する

次のコマンドを順番に実行します。

git log <base>..<HEAD> --oneline
git diff <base>...<HEAD> --stat
git diff <base>...<HEAD> --shortstat

--shortstat の出力（例：12 files changed, 340 insertions(+), 50 deletions(-)）を使用して、差分の規模を判断します。

  • 変更ファイルが 20 件以下、かつ追加と削除の合計が 500 以下の場合：git diff <base>...<HEAD> で差分全体を読みます
  • 変更ファイルが 20 件を超える、または追加と削除の合計が 500 を超える場合：差分全体は読みません。--stat の出力から、ディレクトリ／モジュールごとに変更が最も多いファイルを特定し、代表的なファイルのみ読みます
ステップ 3：PR テンプレートを探す

このステップは必須です。省略したり、ファイルが存在しないと決めつけたりしないでください。

ファイル読み取りツールを使用して、以下のすべてのパスを並行して読み取ってください。

  • .github/PULL_REQUEST_TEMPLATE.md
  • .github/pull_request_template.md
  • docs/pull_request_template.md
  • PULL_REQUEST_TEMPLATE.md

.github/PULL_REQUEST_TEMPLATE/ ディレクトリが存在するかどうかも確認してください。存在する場合は、ファイル一覧を取得し、最初のファイルを読み取ります。

正常に内容を取得できた最初のパスを使用してください。

テンプレートファイルを正常に読み取れた場合：

  • PR 本文には、その構成をそのまま使用してください
  • すべてのセクション、見出し、HTML コメント（``）を元の位置のまま維持してください
  • 適切な箇所に内容を記入してください。差分から判断できないセクション（例：スクリーンショット、関連する Issue）は、元のプレースホルダーまたは HTML コメントをそのまま残してください。削除したり要約したりしないでください
  • セクションを並べ替えたり、統合したり、省略したりしないでください

すべてのパスで失敗した場合（ファイルが見つからない場合）： 次のデフォルト構成を使用してください。

## Summary


## Changes


## Test Plan
ステップ 4：PR タイトルのスタイルを特定する

次を実行します。

gh pr list --state merged --limit 10 --json title 2>/dev/null

gh が結果を返した場合は、タイトルのパターン（例：feat: ...、[PROJ-123] ...、Fix: ...）を分析します。

gh が何らかの理由で失敗した場合（インストールされていない、認証エラー、GitHub リポジトリではないなど）は、次の方法に切り替えます。

git log --oneline -20

コミットメッセージから主なパターンを見つけます。

明確なパターンが見つからない場合は、Conventional Commits 形式（type: description）を使用します。

ステップ 5：PR の内容を作成する

タイトル：

  • ステップ 4 で検出したスタイルが明確で一貫している場合：タイトルを 1 つ作成します
  • スタイルが曖昧または混在している場合：タイトル候補を 2～3 件作成し、明確にラベル付けします

PR 本文：

  • ステップ 3 のテンプレート構成を使用します
  • ステップ 2 の変更分析に基づいて各セクションを記入します
  • 変更されたファイルだけでなく、変更した理由に焦点を当てます
  • 差分に以下が含まれる場合は、明示的に記載します：
    • 破壊的変更（API／インターフェースの変更、フィールドの削除）
    • 追加された新しい依存関係
    • アーキテクチャまたは構造の変更
  • 本文に生の差分やファイル一覧を貼り付けないでください
  • 記入できないセクション（例：スクリーンショット、デモ、関連する Issue）は、テンプレート内の元の HTML コメントまたはプレースホルダーを残します。セクションを削除しないでください

出力形式

次の順序で出力してください：

タイトル

<single best title>

(曖昧な場合は、Alt 1、Alt 2 のラベルを付けて候補を列挙します)

PR 本文

<filled-in PR body — exact template structure preserved>

ブランチ：<base> ← <current> · コミット数：N · 変更ファイル数：N

コメント

Markdown 対応