PR Description
ユーザーとのやり取りと本文は日本語とする。コード・技術用語は原語を使う。
入力
<出力先パス> [--base branch] [--template path] [--format 指示]
指定された出力先を使う。未指定で合理的な保存先を特定できない場合だけ確認する。
テンプレートとformatが併記された場合はテンプレートを優先する。
明示指定がなければ .github/pull_request_template.md を大文字・小文字を区別せず探索し、なければ references/default-template.md を使用する。
情報収集
baseは明示指定を優先し、未指定ならmain、masterの順で確認する。
比較対象を確定し、変更ファイル一覧、git diff <base>...HEAD、関連履歴を読む。
大きい差分はファイル単位で分割し、説明に関係する重要な変更を取りこぼさない。
変更内容の事実は最終差分を基準にする。 会話は背景・目的・設計判断を補うために使い、放棄した方針を最終実装として記載しない。 必要な理由、課題、解決方法、利用者への影響を整理する。 判断できない背景を捏造せず、重要な不足だけ確認する。
本文
- 指定テンプレートの見出しと順序を保持する。
- 理由、課題、解決、影響を意味の近い既存セクションへ記載し、同じ説明を繰り返さない。
- 利用者向け動作変更がない場合は、その事実と理由を簡潔に示す。
- 技術詳細は理解やレビューに必要な範囲とする。
- 実施した検証と計画だけの検証を区別する。
- 会話を知らない第三者が、何がなぜ変わるか理解できる文章にする。
- ローカルだけのタスク番号、TODOパス、作業メモ、ログを持ち込まない。
- 共有リポジトリの文書や実在するIssue・PRは必要なら参照する。
プレースホルダーがある場合は、summary、changes、details、test_plan、breaking_changes、related_issues、review_points、files_changedを意味に合わせて埋める。 プレースホルダーがなくても既存構造を尊重する。
タイトル
Conventional Commits形式、72文字以内で有意味な候補を1〜3案提示する。 最も適切な案を推奨とし、自明な変更に3案を水増ししない。 scope、言語、破壊的変更表記は実際の差分とプロジェクト慣習に合わせる。
出力と検証
本文・テンプレート・事実・公開可読性を確認し、不備を直してから保存する。 既存ファイルは読み、更新対象として許可されている場合だけ置換する。 本文ファイルへタイトル候補を混入させない。
ファイルパス、短い概要、タイトル候補を報告して完了する。 他スキルから呼ばれた場合は中間成果として返し、ユーザーの終了確認を要求しない。
エラー
diffやテンプレートを取得できない場合は原因と影響を示す。 取得済みの情報だけで作れる場合は根拠の範囲を明示する。 指定テンプレートを無断で別形式へ置き換えない。