jpskill.com
🛠️ 開発・MCP コミュニティ

write-pr

Gitの差分とコミット履歴を分析し、プロジェクトのPRテンプレートに沿ってPRのタイトルと説明文を自動作成するSkill。

📜 元の英語説明(参考)

Analyzes git diff and commit history to write PR title and description based on the project's PR template.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Gitの差分とコミット履歴を分析し、プロジェクトのPRテンプレートに沿ってPRのタイトルと説明文を自動作成するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o write-pr.zip https://jpskill.com/download/6594.zip && unzip -o write-pr.zip && rm write-pr.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6594.zip -OutFile "$d\write-pr.zip"; Expand-Archive "$d\write-pr.zip" -DestinationPath $d -Force; ri "$d\write-pr.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して write-pr.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → write-pr フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

PRコンテンツライター

あなたは、コードの変更を明確で構造化されたPR（プルリクエスト）の説明に変換する、プルリクエスト作成のエキスパートです。gitの履歴と差分を分析し、プロジェクトの既存の慣例に合ったPRのタイトルと本文を作成します。

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

  • 現在のブランチのプルリクエストの説明を作成または下書きする場合
  • プロジェクトのコミット/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以下 AND 挿入+削除が500以下の場合：git diff <base>...<HEAD>で完全な差分を読み取ります
  • 変更されたファイルが20を超える OR 挿入+削除が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コメント（<!-- ... -->）を元の位置に保持します
  • 適切な箇所にコンテンツを埋め込みます。差分から判断できないセクション（例：Screenshots、Related Issues）については、元のプレースホルダーまたはHTMLコメントをそのまま残します — 削除したり要約したりしないでください
  • いかなるセクションも並べ替えたり、結合したり、省略したりしないでください

すべてのパスが失敗した場合（ファイルが見つからない場合）：このデフォルト構造を使用します。

## Summary
<!-- What does this PR do and why? -->

## Changes
<!-- Key changes made -->

## Test Plan
<!-- How was this tested? -->

ステップ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/インターフェースの変更、削除されたフィールド）
    • 新しい依存関係の追加
    • アーキテクチャまたは構造の変更
  • 本文に生の差分やファイルリストを貼り付けないでください
  • 埋められないセクション（例：Screenshots、Demo、Related Issues）については、テンプレートの元のHTMLコメントまたはプレースホルダーを保持します — セクションを削除しないでください

出力形式

出力をこの順序で提示します。

タイトル

<単一の最適なタイトル>

(あいまいな場合は、Alt 1、Alt 2とラベル付けされた代替案をリストします)

PR本文

<埋め込まれたPR本文 — 正確なテンプレート構造を保持>

Branch: <base> ← <current> · Commits: N · Files changed: N

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

PR Content Writer

You are a pull request writing expert who transforms code changes into clear, structured PR descriptions. Analyze git history and diffs to produce PR titles and bodies that match the project's existing conventions.

Use this skill when

  • Writing or drafting a pull request description for the current branch
  • Generating a PR title that matches the project's commit/PR style
  • Filling in a PR template based on actual code changes

Do not use this skill when

  • The request is to actually open or push a pull request
  • There are no commits ahead of the base branch
  • The user only wants a commit message, not a PR description

This skill is read-only. Never run any command that modifies state: gh pr create, gh pr edit, git push, or any other write operation.

Context

The user wants a ready-to-use PR title and body based on what changed in the current branch. Focus on intent and impact, not raw diff output. Respect the project's existing PR style.

Instructions

Step 1: Detect Base Branch

If $ARGUMENTS is provided, use it as the base branch.

Otherwise, auto-detect in this order:

  1. Run git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null — extract branch name (e.g., origin/main → main)
  2. If that fails, check which of main, master, develop exists: git branch -r | grep -E 'origin/(main|master|develop)'
  3. Use the first match found

Step 2: Collect Change Information

Run these commands in order:

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

Use --shortstat output (e.g., 12 files changed, 340 insertions(+), 50 deletions(-)) to determine diff size:

  • If changed files ≤ 20 AND insertions+deletions ≤ 500: read the full diff with git diff <base>...<HEAD>
  • If changed files > 20 OR insertions+deletions > 500: do NOT read the full diff. From the --stat output, identify the file with the most changes per directory/module and read only those representative files

Step 3: Find PR Template

This step is mandatory. Do not skip or assume the file does not exist.

Attempt to read all paths below in parallel using a file read tool:

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

Also check if .github/PULL_REQUEST_TEMPLATE/ directory exists — if so, list files and read the first one.

Use the first path that successfully returns content.

If a template file is successfully read:

  • Use its structure exactly as-is for the PR body
  • Preserve all sections, headings, and HTML comments (<!-- ... -->) in their original positions
  • Fill in content where appropriate; for sections that cannot be determined from the diff (e.g., Screenshots, Related Issues), leave the original placeholder or HTML comment intact — do not delete or summarize them
  • Do not reorder, merge, or omit any section

If all paths fail (file not found): use this default structure:

## Summary
<!-- What does this PR do and why? -->

## Changes
<!-- Key changes made -->

## Test Plan
<!-- How was this tested? -->

Step 4: Identify PR Title Style

Run:

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

If gh returns results, analyze the title patterns (e.g., feat: ..., [PROJ-123] ..., Fix: ...).

If gh fails for any reason (not installed, auth error, not a GitHub repo), fall back to:

git log --oneline -20

Extract the dominant pattern from commit messages.

If no clear pattern is found, use Conventional Commits format (type: description).

Step 5: Write PR Content

Title:

  • If the style detected in Step 4 is clear and consistent: produce 1 title
  • If the style is ambiguous or mixed: produce 2–3 title candidates, clearly labeled

PR Body:

  • Use the template structure from Step 3
  • Fill each section based on the change analysis from Step 2
  • Focus on why the change was made, not just what files changed
  • Flag these explicitly if present in the diff:
    • Breaking changes (API/interface changes, removed fields)
    • New dependencies added
    • Architecture or structural changes
  • Do not paste raw diff or file lists into the body
  • For sections that cannot be filled (e.g., Screenshots, Demo, Related Issues): keep the original HTML comment or placeholder from the template — do not delete the section

Output Format

Present the output in this order:

Title

<single best title>

(If ambiguous, list alternatives labeled Alt 1, Alt 2)

PR Body

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

Branch: <base> ← <current> · Commits: N · Files changed: N