pr-process

name	pr-process
description	PRワークフロー全体（計画→実装開始→コミット→PR作成→レビュー）を自律的にオーケストレートする。git/GitHub の状態を見て今どこにいるかを判断し、次のステップを自動で実行する。「実装したい」「PRを出したい」「どこから始めればいい」「実装終わった」「続きをやって」など、開発フローの任意の場面で使う。/pr-plan・/pr-develop・/commit・/pr-create・/pr-review を個別に呼ぶ代わりにこれ一本で済む。

pr-process — PRワークフローオーケストレーター

git と GitHub の状態を読んで「今どのステージか」を判断し、適切なステップを自動で実行する。 人間の介入は最小限：スコープ決め（1回） と UIスクリーンショット（必要時のみ） だけ。

引数

$ARGUMENTS の内容で挙動が変わる：

• 目標・やりたいこと → state A（計画）から開始
• Issue番号（#42）→ state B（実装開始）から開始
• 空（再開） → git/GitHub の状態を見て現在のステージを自動検出

---

Step 1: 現在のステージを検出

git status --short
git branch --show-current
git log main...HEAD --oneline 2>/dev/null
gh issue list --assignee @me --state open --limit 5 2>/dev/null
gh pr view --json number,state,url 2>/dev/null

上記の出力から以下のステージを判定する：

ステージ	条件
A: 計画	引数に目標テキストがある、またはfeatureブランチも未コミット変更もない
B: 実装開始	Issue番号が引数にある、またはIssueはあるがfeatureブランチがない
C: コミット	featureブランチにいて未コミット変更がある
D: PR作成	featureブランチにコミットがあり、PRがない
E: レビュー	PRが存在している（作成直後）
F: CI・レビュー待ち	PRがあり、CI実行中またはレビュー待ち
G: コメント対応	Changes requested または未解決コメントがある

判定したステージを1行で宣言してから実行する（例：「ステージC: 未コミット変更を検出しました。コミットします。」）。

---

ステージA: 計画（介入1回）

ここだけ人間の判断が必要。それ以外は自動。

A-1: スコープを確認する（唯一の介入ポイント）

以下を聞く。一度に全部まとめて聞く（往復を減らす）：

以下を教えてください：

1. 課題：何が問題で、なぜ今やるか
2. やること：実装する内容（箇条書き）
3. やらないこと：今回は触れない範囲（「特になし」でも可）
4. 完了条件：何ができたら完了か

（目標テキスト "$ARGUMENTS" をベースに私が推測した案を提示するので、修正してください）

$ARGUMENTS から推測できる部分はあらかじめ埋めて提示し、ユーザーの修正コストを下げる。

A-2: Issue作成（自動）

確認内容をもとに以下を自動実行する：

gh issue create \
  --title "<type>: <subject>" \
  --body "## 課題\n...\n## 解決策・意図\n...\n## やること\n...\n## やらないこと\n...\n## 完了条件\n..."

A-3: ステージBへ自動移行

Issue作成後、確認なしにBへ進む。

---

ステージB: 実装開始（全自動）

B-1: featureブランチ作成

git checkout -b feature/#<issue番号>-<kebab-case-title>

B-2: スコープをサマリー表示して実装を委ねる

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Issue #<番号> の実装を開始します
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
やること:
  - <項目>

やらないこと:
  - <項目>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
実装してください。終わったら /pr-process で続きを自動実行します。

ここで処理を止める（実装は人間またはエージェントが行う）。

---

ステージC: コミット（全自動）

C-1: 差分を分析して意図をグルーピング

git diff と git diff --staged を読み、変更を意図単位でグルーピングする。

単一意図の場合 → C-2へ

複数意図が混在する場合 → 以下を表示してから自動実行：

複数の意図を検出しました。以下の順番で分割コミットします：
  1. <type>(<scope>): <subject> → <対象ファイル>
  2. <type>(<scope>): <subject> → <対象ファイル>
自動実行します...

C-2: 意図ごとにコミット（自動）

git add <該当ファイル>
git commit -m "<type>(<scope>): <subject>"
# 次の意図があれば繰り返す

C-3: ステージDへ自動移行

コミット完了後、確認なしにDへ進む。

---

ステージD: PR作成（全自動、UIスクショのみ確認）

D-1: コンテキスト収集

gh issue view <番号>           # Issueの内容（やること・やらないこと）
git log main...HEAD --oneline  # コミット一覧
git diff main...HEAD --stat    # 変更サマリー

D-2: UIスクリーンショットの確認（条件付き介入）

変更ファイルに UI 要素（Composable / ViewController / HTML / CSS 等）が含まれる場合のみ：

UIの変更が含まれています。
スクリーンショットを撮影してPR bodyに追記するか、
「スクショなし」と言えばそのままPRを作成します。

UI変更がない場合は確認なしにD-3へ進む。

D-3: PR body生成 → PR作成（自動）

Issueの「やらないこと」欄を必ず引用してPR bodyを生成する。

gh pr create \
  --title "<type>(<scope>): <subject>" \
  --body "## 課題\nCloses #<番号>\n...\n## やったこと\n...\n## やらなかったこと\n...\n## 証跡\n...\n## 参考\n#<Issue番号>" \
  --assignee "@me"

D-4: ステージEへ自動移行

PR作成後、確認なしにEへ進む。

---

ステージE: セルフレビュー（全自動）

E-1: PR情報取得

gh pr view <番号>
gh pr diff <番号>

E-2: 意図を1文で確認

PR descriptionから「このPRが達成しようとしていること」を1文で述べる。 1文で言えなければ「PR descriptionが不十分です」とコメントして終了。

E-3: 4層レビューを実行

以下の順番でレビューする：

1. テスト（存在・仕様表現・エッジケース）
2. 公開API / インターフェース（型・後方互換性・命名）
3. 実装ロジック（正確性・エラーハンドリング・スレッドセーフ性）
4. プロジェクト固有ルール（CLAUDE.mdを参照）

E-4: 結果を出力

## PR #<番号> セルフレビュー結果

意図: <1文>

### 指摘事項
<⛔/🔴/🟡/💬 + What/Why/How形式>

### 総合判断
<Approve推奨 / Request Changes推奨 / 議論推奨> — <根拠1行>

---

ステージF: CI・レビュー待ち（自動検出）

ステージEの完了後、または /pr-process を再実行したときにPRが存在している場合。

F-1: ステータス確認（pr-status ロジックを実行）

gh pr checks <番号>
gh pr view <番号> --json reviews,reviewThreads,statusCheckRollup,mergeable

F-2: 状態に応じて次ステージへ分岐

状態	アクション
CI実行中・レビュー待ち	「CIとレビューを待っています。完了したら /pr-process で再開してください。」と伝えて終了
CI失敗 または Changes requested	ステージGへ自動移行
Approved + CI通過	「マージできます。gh pr merge <番号> --squash を実行してください。」と伝えて終了
Conflicts あり	「コンフリクトがあります。git rebase main で解消してください。」と伝えて終了

---

ステージG: コメント対応（全自動、判断不能時のみ確認）

G-1: 対応事項の収集・分類・表示

未解決のレビュースレッドとCI失敗を収集し、以下に分類して表示する：

• コード修正が必要
• 返信のみ
• スキップ（nit・解決済み）
• 判断が必要（人間に確認）

G-2: コード修正（自動）

修正が必要な箇所をコードに反映し、意図別にコミットする（/commit ロジックを適用）。

git add <修正ファイル>
git commit -m "fix(<scope>): <コメントの要点>"
git push origin <branch>

G-3: コメントへの返信（自動）

各スレッドに事実ベースの返信を投稿する：

• 修正した → 「修正しました。〇〇に変更しました」
• 採用しない → 「〇〇の理由で現状のままにします」
• 質問への回答 → 「〇〇の理由でこの設計にしました」

G-4: ステージFへ戻る

対応完了後、ステータスを再確認してF-2の判断を繰り返す。

---

完了後の出力

全ステージ完了後に以下を出力：

✓ PR #<番号> の作成とセルフレビューが完了しました。
  <PR URL>

次のアクション:
  - レビュアーをアサイン: gh pr edit <番号> --add-reviewer <user>
  - CIとレビューが完了したら /pr-process で再開（自動でコメント対応まで実行します）

---

エラー・例外の扱い

• gh コマンドが使えない → 「gh auth login を実行してください」と伝えて終了
• mainブランチにいる → 自動でfeatureブランチを作成してCへ進む
• 未コミット変更がないのにCと判定 → Dへスキップ
• Issueが特定できない → Issue番号を1回だけ確認する