ousiass/bug-fix

bug-fix

前提条件

• Claude Code 環境
• git, gh CLI

引数

• Issue 番号 (例: /bug-fix #42): GitHub Issue からバグ報告を取得
• Issue URL (例: /bug-fix https://github.com/owner/repo/issues/42): 同上
• テキスト (例: /bug-fix ログイン時に500エラー): テキストをバグ報告として扱う
• 引数なし: ユーザーにバグの症状をヒアリング

フェーズ1: バグ報告の整理とブランチ作成

1. 引数からバグ報告を取得する
   • Issue: gh issue view で本文・コメント・ラベルを読み取る
   • テキスト: バグ報告として扱う
   • 引数なし: ユーザーにヒアリング
2. 以下の情報を整理する（不足分はユーザーに確認）
   • 症状: 何が起きているか
   • 期待される動作: 本来どうあるべきか
   • 再現手順: どうすれば再現できるか
   • 発生環境: ブラウザ、OS、環境（本番/ステージング/ローカル）
   • 発生頻度: 常に / 時々 / 特定条件で
3. 現在のブランチをベースブランチとして記録する（PR のマージ先）
   • git branch --show-current を実行し、結果をユーザーに「ベースブランチ: <ブランチ名>」と明示的に表示する
   • このブランチ名をフェーズ4のPR作成時まで保持する
4. 作業ブランチを作成する
   • Issue 指定: fix/#<Issue番号> （例: fix/#42）
   • テキスト / 引数なし: fix/<バグの要約> （例: fix/login-500-error）
5. TaskCreate でタスクを管理する

フェーズ2: 原因調査

1. 再現確認 — バグ報告の再現手順に従い再現を確認。再現不可ならユーザーに追加情報を求める
2. 影響範囲の特定 — Explore エージェントや Grep/Glob で関連コードを調査。関連テストも確認
3. 原因の特定 — 根本原因を特定し、コードの流れで裏付ける。原因と修正方針をユーザーに報告し合意を得る

フェーズ3: 修正サイクル

3-1: 回帰テストの作成

• 修正の前にバグを再現するテストを作成し、失敗を確認する

3-2: 修正

• 最小限の変更でバグを修正する

3-3: 検証

• 回帰テスト + 既存テストがすべて通ることを確認する

3-4: Review

• review エージェントで修正内容をレビューする

3-5: 改善サイクル

• レビュー指摘あり → 修正 → 再レビュー → 指摘なしまで繰り返す

3-6: Format & Lint

• プロジェクト設定に従い変更ファイルに format/lint を実行。設定なしならスキップ

3-7: Commit

• コミットメッセージは CLAUDE.md の規約に従う

フェーズ4: プルリクエスト

1. gh pr create --base <ベースブランチ> でPRを作成
   • ベースブランチはフェーズ1で記録した開始時のブランチを指定する。main や master にフォールバックしないこと。
   • 不明な場合は git log --oneline --graph HEAD...main 等で分岐元を確認する
   • Issue 指定時: タイトルに Issue 番号を含め、PR作成後に gh pr edit <PR番号> --add-issue <Issue URL> でリンクする（Closes は使わない）
   • PR本文: バグの症状・原因・修正サマリー + 手動チェックリスト（templates/pr-checklist.md を参照）
2. 修正サマリーをユーザーに報告する

ルール

• 推測で修正しない。原因を特定してから修正に着手する
• 修正の前に必ず回帰テストを書く（テスト失敗 → 修正 → テスト成功）
• 修正は最小限。バグに無関係なリファクタリングを混ぜない
• 原因と修正方針は必ずユーザーに報告し合意を得る
• 🔴🟠 のレビュー指摘は必ず修正。🟡🟢 は明確なメリットがある場合のみ
• TaskCreate/TaskUpdate で進捗を管理する