create-pr-description

name	create-pr-description
description	指定されたissueを元に、簡潔で構造化されたPR説明文を作成する
argument-hint	[issue-number]
allowed-tools	Bash, Read, mcp__acp__Read, Grep
disable-model-invocation	false

PR説明文作成スキル

指定されたissueを元に、簡潔で構造化されたPR説明文を作成します。

スタイル要件

• 簡潔性: 冗長な説明は避け、要点のみを端的に表現
• 文体: エンジニア向けの実務的な表現を使用
• 明確性: 一文一義で、事実とデータに基づいて記述
• 敬称: 不要な敬称や過度な丁寧語は使わない

手順

1. issue情報の取得

   • 引数で指定されたissue番号を取得
   • gh issue view [番号] --json title,body,commentsでissue情報を一括取得
   • issue本文とコメントを分析

2. ブランチとコミット情報の取得

   • git statusで現在のブランチを確認
   • git log main...HEADまたはgit diff main...HEADで変更内容を把握
   • 実装の全体像を理解

3. PR説明文の構成

   以下のセクション構造で作成してください:

   ref

   • 関連issueのリンク（#[番号]形式）

   背景

   • 問題の事実のみを記述
   • 調査結果を箇条書きで簡潔に
   • 調査の網羅性が伝わるように（例: フラウド調査も実施済み、など）

   目的

   • この変更で達成したいこと（What）
   • 「〜を実現する」「〜を改善する」など端的に
   • 具体的な実装内容は「やったこと」セクションへ

   やったこと

   • 実装した内容を箇条書きで端的に
   • 変更の詳細はファイルのdiffを見ればわかるので言及しすぎない

   確認したこと、考えたこと

   • 実装の検討プロセス
   • 影響範囲の調査結果（例: パーティション追加作業への影響）
   • 動作確認の詳細
   • issueコメントへのリンクで詳細を参照（実際に存在するURLのみ）

   根拠（データがある場合）

   • 数値や閾値の選定理由
   • データ分析結果
   • 算出ロジックを簡潔に説明
   • 詳細資料へのリンク

   レビューしてほしいポイント

   • レビュアーに判断を仰ぐ具体的な観点
   • 疑問形で端的に

4. 出力

   • 作成したPR説明文をmarkdownのコードブロック（markdown）で囲んで出力
   • ユーザーがコピーしてPR作成時に使用できる形式

避けるべき表現

• ❌ 「〜することができます」→ ⭕ 「〜する」
• ❌ 「〜を考慮し、」→ ⭕ 「〜のため、」または削除
• ❌ 「〜によって〜することで〜を実現する」→ ⭕ 「〜を実現する」
• ❌ 「具体的には:」の後に冗長な説明 → ⭕ 必要最小限の情報のみ

出力フォーマット例

## ref

#123

## 背景

- [問題の事実]
- [調査結果]

## 目的

[達成したいこと]

## やったこと

- [実装内容1]
- [実装内容2]

## 確認したこと、考えたこと

- [検討プロセス]
- [影響範囲の調査]
- 詳細: https://github.com/org/repo/issues/123#issuecomment-xxxxx

## レビューしてほしいポイント

- [具体的な観点]

注意事項

• issue情報はgh issue viewコマンドで一括取得する（Task toolは使わない）
• issueコメントのURLは実際に存在するもののみリンクする
• 根拠セクションはデータがある場合のみ含める
• 簡潔性を最優先し、冗長な説明は避ける