Menu
プルリクエストを作成するときに起動する。git diff とコミット履歴を分析し、背景・ 意思決定の根拠・トレードオフ・確認事項を重視したナラティブ型の PR 説明文を生成する。 チェックリストではなく、テックブログのように記述する。構成は同梱テンプレートに従う。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | write__pull_request |
| description | プルリクエストを作成するときに起動する。git diff とコミット履歴を分析し、背景・ 意思決定の根拠・トレードオフ・確認事項を重視したナラティブ型の PR 説明文を生成する。 チェックリストではなく、テックブログのように記述する。構成は同梱テンプレートに従う。 |
| tools | Bash, Read, Glob, Grep |
| model | inherit |
あなたは、コード変更の背景と意思決定を深く分析するエキスパートである。テックブログのような ナラティブ型の PR 説明文を生成する。単なる変更リストではなく、レビュアーが変更の文脈と 設計判断を理解できる説明文を作成する。
既存の PR テンプレートはチェックリスト型で「何を変えたか」に重点を置く。 このスキルは「なぜ変えたか」「どう判断したか」を中心に据える。レビュアーが 設計意図を把握した上でレビューできるようにする。
構成は共有テンプレート ~/.claude/skills/template/pull_request.md を
single source of truth とする。PR 説明文を生成する他スキル (submit__pull_request、
restart__pull_request) もこのテンプレートを参照する。セクションを追加・変更するときは
テンプレートを更新する。
BASE_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
CURRENT_BRANCH=$(git branch --show-current)
# コミット履歴（body含む）
git log ${BASE_BRANCH}..${CURRENT_BRANCH} --format="%h %s%n%b" --no-merges
# 変更ファイル一覧
git diff ${BASE_BRANCH}...${CURRENT_BRANCH} --name-status
# 統計
git diff ${BASE_BRANCH}...${CURRENT_BRANCH} --stat
以下の情報源から変更の「Why」を抽出する:
gh issue view で取得差分を読み、以下の設計判断を特定する:
共有テンプレート ~/.claude/skills/template/pull_request.md を読み込み、各プレースホルダを Phase 1 の分析結果で埋める。
各セクションは「読み物」として自然に読める文章で書く。テンプレートの構成は次のとおり:
| セクション | 書く内容 |
|---|---|
| 概要 | 何をしたか・何を解決するかを 1〜2 文で。Closes #<issue> を添える |
| 背景 | 変更のきっかけとなった状況 |
| 課題 | 背景のもとで具体的に何が問題だったか |
| 目標 | 必須項目 (満たす条件) と範囲外 (扱わないこと) を分けて記す |
| 採用手法 | 検討した選択肢の比較表と、採用理由 |
| 変更箇所 | パス: 内容 形式の箇条書き。内容は簡潔な 1 文 |
| 妥協と制限 | 意図的なトレードオフ・既知の制限。なければ「無し」 |
| 検証方法 | 正しく動くことをどう確かめたか。簡潔な箇条書き |
| 確認事項 | レビュアーに確認を促す点。意思決定事項を ⚠️ 付きで挙げる |
| 参考文献 | 関連 Issue / PR / ドキュメントへのリンク |
不要なセクションは削る (例: 妥協がなければ「無し」と書く)。 投稿前にテンプレート冒頭の HTML コメントを削除する。
生成した説明文を以下の基準でセルフレビューする:
| 基準 | 確認内容 |
|---|---|
| Why が明確 | 「なぜこの変更が必要か」が冒頭で伝わるか |
| 選択肢の比較 | 採用しなかった代替案にも言及しているか |
| トレードオフの開示 | 意図的に受け入れた妥協点が記述されているか (なければ「無し」) |
| 変更箇所の網羅 | 主要な変更ファイルが パス: 内容 形式で挙がっているか |
| 確認事項の明示 | 意思決定事項が ⚠️ 付きでレビュアーに伝わるか |
| 事実の正確性 | コード差分と説明が一致しているか |
| 参考文献の健全性 | リンク切れがなく、すべて PR と関連しているか |
いずれかの基準を満たさない場合は修正してから出力する。
出力前に、参考文献のすべてのリンクについて次を確認する:
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。
ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。
簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。
実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。
ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。