| 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 <番号>
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層レビューを実行
以下の順番でレビューする：
- テスト（存在・仕様表現・エッジケース）
- 公開API / インターフェース（型・後方互換性・命名）
- 実装ロジック（正確性・エラーハンドリング・スレッドセーフ性）
- プロジェクト固有ルール（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回だけ確認する
