git-workflow

Git ワークフロー

PR ライフサイクルの自動化です。PR を作成 → CI とレビューを監視 → 修正 → 対応 → プッシュ → すべて成功するまで繰り返します。

bun gh-tool コマンドの全リファレンスについては、bun gh-tool --help または bun gh-tool pr --help を実行してください。このスキルで説明するのはワークフローであり、ツールの機能一覧ではありません。

プッシュ、ブランチ作成、ブランチ同期の手順については、references/push-branch-sync.md を参照してください。

PR ワークフロー

トリガー：ユーザーが「pr」、「pull request」、「create PR」、「CI failed」、「address review comments」、「merge when green」など、同様の内容を伝えた場合です。

PR のライフサイクル全体を、ひと続きの積極的なループとして実行します。「コメントを修正する」独立したステップはありません。すべてがひとつのワークフローです。

フェーズ 1：PR の作成または更新

まず、PR がすでに存在するか確認します。

bun gh-tool pr status

PR が存在しない場合 — ブランチの作成、コミット、プッシュ、PR のオープンをひと続きで行います。

git checkout -b <branch> && git add -A && git commit -m "<msg>" && git push -u origin HEAD && bun gh-tool pr create --base <base> --title "<title>" --body "<body>"

PR がすでに存在する場合 — コミット、プッシュを行い、メタデータを更新します。

git add -A && git commit -m "<msg>" && git push origin HEAD
bun gh-tool pr edit --pr <pr_number> --title "<title>" --body "<body>"

• すでにフィーチャーブランチにいる場合は、git checkout -b を省略します。
• ベースブランチ：ユーザーが指定した引数（デフォルト：test）。
• ブランチ名：変更内容に応じて feat/、fix/、chore/ を使用します。

ローカルレビューのゲート

重要度が低くない変更について、最初のコミット／プッシュを行う前に、code-review スキルで差分をレビューし、Critical および Major の指摘をすべて解決してください。これは PR 前に必須のゲートであり、任意の仕上げではありません。bun run check で確認できるのは、記述したパスが通ることだけで、ロジックが正しいことではありません（カバレッジの不足が実際のバグを見逃すことがあります。たとえば、項目ごとのループで出力のラベルを誤っていても、単一項目のテストには通ります）。省略できるのは、些細な変更や機械的な差分の場合のみです。その場合は、省略したことを明記してください。

最初のレビューとして、フェーズ 2 の GitHub レビューループ／監視に頼らないでください。ここで見つかったバグならローカルで編集できます。同じバグが CI で見つかると、（プッシュ、待機、レビューボット、修正、再実行）という一連の作業が発生します。レビュー担当者の視点で差分を読み、Critical／Major の指摘が残っていなければ、このゲートは完了です。

PR 本文の形式

## Summary
<1-2 sentences>

## Changes
- <bullet list>

コミットメッセージの基準

すべてのコミットで、実際の変更内容を説明する適切な Conventional Commits 形式を必ず使用してください。「レビューのフィードバックに対応」や「CI を修正」のようなメタ的な説明は使用しないでください。

形式：<type>(<scope>): <what actually changed>

• type：fix、feat、refactor、perf、style、chore など
• scope：影響を受けるモジュール／領域（例：auth、db、ui、api）
• message：コミットする理由ではなく、具体的な変更内容を説明します

良い例：

• fix(auth): add null check for session token before redirect
• refactor(api): extract validation logic into shared middleware
• fix(db): correct JOIN condition in user query

悪い例（絶対に使用しないでください）：

• fix: address review feedback
• fix: resolve CI check failures
• chore: fix issues

ひとつのコミットで異なるスコープにまたがる複数のレビューコメントに対応する場合は、まとめてひとつにせず、スコープごとにコミットを分けてください。

フェーズ 2：積極的な監視ループ

PR の作成／更新後、すぐに積極的な監視ループに入ってください。中断したり、ユーザーからの入力を待ったりしないでください。

ユーザーに次のように伝えます：「PR を作成／更新しました。積極的な監視ループに入ります。CI とレビューを監視中です。（終了するには「stop」と言ってください）」

---

ループ開始

ステップ 1：スナップショットを取得し、次に行うことを決定する

ループの契約 — 提案ではなく、必須の動作です：

• PR の作成または更新後は、ループ終了までこのループから抜けないでください。
• 修正とプッシュを行うたびに、直ちにステップ 1に戻ってください。
• 返信または解決の処理を行うたびに、直ちにステップ 1に戻ってください。
• CI がまだ実行中であれば、ループは完了していません。
• 確認できる未対応のレビュー フィードバックが残っていれば、ループは完了していません。
• いずれかの項目が問題なしになったからといって、1 回の処理だけで終了しないでください。
• ユーザーが stop と入力した場合、または最大反復回数の上限に達した場合を除き、続行するかどうかをユーザーに尋ねないでください。

ステップ 1 は必ずスナップショットの取得から始めてください：

bun gh-tool pr review-triage --pr <pr_number>

このコマンドは、info、unresolvedThreads、visibleOpenThreads、summary、checks を 1 回の呼び出しで返します。分岐の判断には、これだけを信頼できる情報源として使用してください。

スナップショットを取得したら、直ちに次のように分岐してください：

• チェックが失敗 → ステップ 2 へ
• チェックが成功し、確認できる未対応フィードバックがある → ステップ 3 へ
• チェックが成功し、確認できる未対応フィードバックがない → ループ終了へ
• チェックが実行中で、確認できる未対応フィードバックがある → ステップ 3 へ（CI の実行中にフィードバックに対応）
• チェックが実行中で、フィードバックがない → CI の完了を待機：

bun gh-tool pr checks --pr <pr_number> --watch

--watch の完了後は、最新のスナップショットを取得するため、ステップ 1に戻ってください。

bun gh-tool を使った独自の sleep ポーリングループを作成しないでください。 対応する作業が残っている場合はそれに対応し、明示的にステップ 1に戻ってください。CI 以外に残作業がない場合は、--watch を使用してください。

ステップ 2：CI の失敗に対応する

1. まず、失敗の原因が不安定なものか、実際の問題かを判断します。

   • 失敗が一時的なもの（タイムアウト、インフラストラクチャまたはネットワークの問題、無関係なサービスなど）に見える場合は、再実行してステップ 1 に戻ってください：

     bun gh-tool pr rerun-checks --pr <pr_number>
     

     → ループ開始に戻る

   • 失敗が実際の問題に見える場合は、以下を続けてください。

2. 失敗したチェックの詳細を取得します：

   bun gh-tool pr checks-failed --pr <pr_number>
   

3. 出力にワークフローの実行とジョブ名が含まれている場合は、ログを取得します：

   bun gh-tool workflow job-logs --run <run_id> --job "<job_name>" --failed-steps-only
   

4. エラーを分析し、ローカルで修正してください。質問せず、そのまま修正してください。

5. 検証を実行します：

   bun run check
   

6. コミットしてプッシュします：

   git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD
   

7. → ループ開始に戻る

ステップ 3：レビューを確認し、フィードバックを振り分ける

ステップ 1 のスナップショットには、スレッドと概要がすでに含まれています。詳細を確認してください：

3.1 まだ対応が必要なインラインレビュー スレッド：

--visible-open-only を使用してください。未解決のスレッドに加えて、返信がまだない解決済みのスレッドも含まれます：

bun gh-tool pr threads --pr <pr_number> --visible-open-only

3.2 AI レビュアーの課題コメント（Claude bot、Sentry Seer など）：

bun gh-tool pr issue-comments --pr <pr_number> --author claude --body-contains "Claude Code Review"
bun gh-tool pr issue-comments --pr <pr_number> --author sentry-io --body-contains "Sentry"

AI レビュアーは、重大度（Critical、Major、Minor）、ファイルパス、行番号を含む指摘を、一般的な PR コメントとして投稿します。各コメント本文を解析して、対応可能な項目を抽出してください。

3.3 判断：

• 確認できる未対応スレッドがなく、対応可能な AI コメントもない場合 → PR に問題はありません。→ ループ終了へ
• フィードバックが 1 つでも見つかった場合 → ステップ 4 へ進む

Step 4: すべてのコメントにすぐ対応する

コードを変更する前に、対応が必要なコメント／指摘ごとにToDo項目を1つ作成します（利用可能であればToDoリストツールを使い、そうでなければ会話内で番号付きのチェックリストを明示的に管理します）。

• コメント／指摘1件につき、追跡項目を1つ作成します。
• 情報源と問題を特定できる、短いラベルを付けます。
• そのコメントに対応している間だけ、in_progressにします。
• コード変更と返信／解決の両方が完了してから、completedにします。

コメント／指摘ごとに、次の手順を行います。

1. 指定された行のファイルを読む。

2. 提案内容を理解する — どのような変更が求められているかを確認します。

3. 評価して対応する：

   • 自動適用する（確認不要）：誤字、スタイルの修正、型の不足、インポートの整理、明白なバグ、パフォーマンスの改善、CLAUDE.mdの規約に沿ったセキュリティ修正。
   • 判断して適用する：明確さを高めるリファクタリング、エラーハンドリング、命名の改善に関する提案。
   • まずユーザーに確認する：機能の削除、公開APIシグネチャの変更、既存のパターンとの矛盾、不明確な提案。

4. すぐに修正する — 変更内容と理由を記録します。

Step 5: コメントに返信してスレッドを解決する

重要：すべてのスレッドに、解決前に必ず返信してください。

インラインスレッドの場合 — 返信して、同時に解決します。

bun gh-tool pr reply-and-resolve --pr <pr_number> --comment-id <comment_id> --thread-id <thread_id> --body "<response>"

一般的なPRコメントの場合 — 返信を投稿します。

bun gh-tool pr comment --pr <pr_number> --body "<response>"

返信の形式：

• 修正した場合：「対応しました — [変更内容の簡単な説明]」
• 該当しない場合：「該当しません — [該当しない理由の簡単な説明]」
• 肯定的なフィードバックの場合：「フィードバックありがとうございます！」などの謝意
• 相談が必要な場合：「質問： [明確化を求める質問]」

返信時に保留中のレビューに関する検証エラーが発生した場合： まず bun gh-tool pr submit-review --pr <pr_number> で保留中のレビューを送信してから、再試行します。却下する必要がある場合は、先にGitHubで却下してください。

質問をしたスレッドは解決しないでください。

Step 6: 検証してプッシュする

bun run check

新たに発生した問題を修正します。その後、コミットしてプッシュします。

git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD

→ LOOP STARTに戻る

---

LOOP EXIT

ここに到達したら（すべてのチェックに合格し、未対応のフィードバックが見当たらない場合）：

最終的な成功メッセージを表示する前に、コメント解決の概要リストを出力します。

番号付きリストを使用し、対応したコメント／指摘ごとに1項目を記載します。次の固定形式に従ってください。

1. Source: inline thread | general PR comment | AI review
   Identifier: <thread_id / comment_id / reviewer label>
   Problem: <short summary of the concern>
   Resolution: <what changed, or why it was not applicable>
   Changed files: <file A>, <file B> | none
   Replied: yes | no | n/a
   Resolved: yes | no | n/a
   Link: <comment or PR URL if available>

コメントが見つからなかった場合は、空の構成を出力する代わりに、その旨を明示します。

ユーザーに次のように伝えます：「すべてのCIチェックに合格しました。すべてのレビューコメントに対応しました。PRはレビュー可能な状態です！」

ループの終了条件

次の場合、監視ループを終了します。

• すべてのチェックに合格し、未対応のフィードバックがない場合 — 通常の終了。
• ユーザーが「stop」と言うか、終了を求めた場合。
• 最大20回に到達した場合 — 続行するかユーザーに確認します。