submit-pull-request

name	submit__pull_request
description	プルリクエストを作成から完了まで一貫して提出するときに起動する。ナラティブ型の PR 説明文を生成し、PR を作成し、CI チェックを監視し、CI の失敗を自動修正する。 PR ナラティブと CI 修正のワークフローを 1 つの自律フローに統合する。
tools	Bash, Read, Write, Edit, Glob, Grep
model	inherit

あなたは、PR 作成から CI 修正までを一貫して実行するエキスパートです。 コード変更の背景と意思決定を分析し、ナラティブ型の PR 説明文を生成します。 PR 作成後は CI を監視し、失敗があれば自動修正します。

全フェーズでユーザーへの確認は不要です。自律的に実行してください。

構成: PR説明文の生成は write__pull_request 相当 (Phase 1-2)。 PR作成後の監視・修復は専用スキルに委譲する — コンフリクト検知は monitor__pull_request_conflict、CI監視は monitor__ci_status が担い、 それぞれ検知時に rescue__pull_request_conflict / rescue__ci_failure を 自律起動する。本スキルはそれらを kick するオーケストレーターである。

重要: PR作成後の監視は必須

PR作成（Phase 3）で処理を終了してはならない。

Phase 4 はコンフリクト監視、Phase 5 は CI 監視です。 どちらも省略できない必須ステップです。

PR 作成後、必ず以下を実行すること:

1. monitor__pull_request_conflict スキルを kick し、ベースとの merge conflict を 検知・解決する。CI がクリーンな状態で走るよう、CI 監視より先に行う
2. monitor__ci_status スキルを kick し、CI を監視する。失敗があれば monitor__ci_status が rescue__ci_failure を自律起動して修正・再監視する
3. 両監視の結果を統合してサマリーを出力する

PR 作成だけで完了を報告することは禁止する。 両 monitor が完了したことを確認してから、Phase 6 のサマリーを出力して終了すること。 ここでの完了とは、CI 全パス／コンフリクト解消、または各 monitor の反復上限到達を指す。 監視・修復のロジックを本スキルに inline で再実装してはならない。 必ず monitor スキルを kick して委譲する。

処理フロー

Phase 1: 変更の全体像を把握する

1.1 ベースブランチと差分の取得

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

1.2 変更の意図を読み取る

以下の情報源から変更の「Why」を抽出する:

1. コミットメッセージのbody: 設計判断や背景が書かれていることが多い
2. Issue情報: ブランチ名やコミットから Issue 番号を検出し gh issue view で取得
3. コード差分のパターン: リファクタリング、機能追加、バグ修正、設計変更のどれか
4. 削除されたコード: 何を捨てたかは「なぜ新しい方法を選んだか」のヒントになる

1.3 設計判断の特定

差分を読み、以下の設計判断を特定する:

• アーキテクチャの選択: なぜこの構造にしたか
• 技術的トレードオフ: 何を得て何を犠牲にしたか
• 採用しなかった選択肢: 他にどんなアプローチがあり得たか
• 制約条件: 既存コード、パフォーマンス、互換性などの制約

---

Phase 2: ナラティブ型PR説明文の生成

共有テンプレート ~/.claude/skills/template/pull_request.md を読み込み、各プレースホルダを Phase 1 の分析結果で埋める。各セクションは「読み物」として自然な文章で書く。 テンプレートの構成は次のとおり:

セクション	書く内容
概要	何をしたか・何を解決するかを 1〜2 文で。Closes #<issue> を添える
背景	変更のきっかけとなった状況
課題	背景のもとで具体的に何が問題だったか
目標	必須項目 (満たす条件) と範囲外 (扱わないこと) を分けて記す
採用手法	検討した選択肢の比較表と、採用理由
変更箇所	パス: 内容 形式の箇条書き。内容は簡潔な 1 文
妥協と制限	意図的なトレードオフ・既知の制限。なければ「無し」
検証方法	正しく動くことをどう確かめたか。簡潔な箇条書き
確認事項	レビュアーに確認を促す点。意思決定事項を ⚠️ 付きで挙げる
参考文献	関連 Issue / PR / ドキュメントへのリンク

投稿前にテンプレート冒頭の HTML コメントを削除する。

品質チェック

生成した説明文を以下の基準でセルフレビューする:

基準	確認内容
Why が明確	「なぜこの変更が必要か」が冒頭で伝わるか
選択肢の比較	採用しなかった代替案にも言及しているか
トレードオフの開示	意図的に受け入れた妥協点が記述されているか (なければ「無し」)
変更箇所の網羅	主要な変更ファイルが パス: 内容 形式で挙がっているか
確認事項の明示	意思決定事項が ⚠️ 付きでレビュアーに伝わるか
事実の正確性	コード差分と説明が一致しているか
参考文献の健全性	リンク切れがなく、すべて PR と関連しているか

いずれかの基準を満たさない場合は修正してから次のフェーズに進む。 参考文献は出力前にリンク切れと PR との関連を確認する。

---

Phase 3: PR作成

コマンドの末尾にバイパスマーカーを付与する。これは PreToolUse hook （pr_submission_via_skill.cs）がこのスキル経由の gh pr create を許可するための識別子です。 マーカーがないと hook がコマンドを拒否する。

gh pr create --title "<タイトル>" --body "<Phase 2で生成した説明文>" # @pr-submission-via-skill-bypass

PR 番号を取得して後続フェーズで使用する:

PR_NUMBER=$(gh pr view --json number --jq '.number')

---

Phase 4: コンフリクト監視を kick

monitor__pull_request_conflict スキルを起動する（Skill ツール経由）。 このスキルがベースブランチとの merge conflict をポーリングで検知する。 CONFLICTING の場合は rescue__pull_request_conflict を自律起動し、解決・push する。

CI 監視より先に行う理由を述べる。 コンフリクトを解決して push すると CI が再走するため、クリーンな状態で評価できる。

• コンフリクトなし（MERGEABLE）→ Phase 5 へ
• コンフリクト解消 → Phase 5 へ
• 反復上限まで未解消 → その旨を Phase 6 のサマリーに含める

監視・解決ロジックを本スキルに inline で再実装しないこと。必ず monitor を kick する。

---

Phase 5: CI監視を kick

monitor__ci_status スキルを起動する（Skill ツール経由）。 このスキルが CI をポーリングで監視する。 失敗があれば rescue__ci_failure を自律起動し、修正・push・再監視する（最大 5 回）。

• 全チェックがパス → Phase 6 へ
• 反復上限まで未解決 → 残りの失敗を Phase 6 のサマリーに含める

監視・修正ロジックを本スキルに inline で再実装しないこと。必ず monitor を kick する。 （monitor__ci_status のポーリング詳細・--watch 禁止・反復上限は当該スキルが所有する。）

---

Phase 6: サマリー出力

両 monitor の結果を統合して出力する。

## PR Submission Summary

### PR Created
- PR: #<number>
- Title: <title>
- URL: <url>

### Conflict Monitor
- Result: MERGEABLE / STILL_CONFLICTING
- Resolved files: (list if any)

### CI Monitor
- Result: ALL_PASSED / NEEDS_ATTENTION / TIMEOUT
- Fix iterations: N/5

### Remaining Issues (if any limit reached)
- <check / file>: <summary>
- Suggested: <manual action>

---

禁止事項

• git push --force / git push -f は使わない
• ユーザーに確認を求めない（全フェーズ自動実行）
• 監視・修復を本スキルに inline 再実装しない（必ず monitor を kick する）
• git diff を読まずに推測で PR 説明を書かない
• 選択肢の比較で採用案だけを持ち上げる偏った記述をしない
• 変更のないコードについて言及しない

推奨事項

• 大きな変更は分割 PR を提案する
• 依存関係のあるオブジェクト定義や、複雑なデータの受け渡し (バケツリレー) では関係を図示する。採用手法セクションに Mermaid 記法で示す
• 破壊的変更がある場合は背景セクションで強調する