ousiass bug-fix
前提条件
- Claude Code 環境
git,ghCLI
引数
- Issue 番号 (例:
/bug-fix #42): GitHub Issue からバグ報告を取得 - Issue URL (例:
/bug-fix https://github.com/owner/repo/issues/42): 同上 - テキスト (例:
/bug-fix ログイン時に500エラー): テキストをバグ報告として扱う - 引数なし: ユーザーにバグの症状をヒアリング
フェーズ1: バグ報告の整理とブランチ作成
- 引数からバグ報告を取得する
- Issue:
gh issue viewで本文・コメント・ラベルを読み取る - テキスト: バグ報告として扱う
- 引数なし: ユーザーにヒアリング
- Issue:
- 以下の情報を整理する（不足分はユーザーに確認）
- 症状: 何が起きているか
- 期待される動作: 本来どうあるべきか
- 再現手順: どうすれば再現できるか
- 発生環境: ブラウザ、OS、環境（本番/ステージング/ローカル）
- 発生頻度: 常に / 時々 / 特定条件で
- 現在のブランチをベースブランチとして記録する（PR のマージ先）
git branch --show-currentを実行し、結果をユーザーに「ベースブランチ: <ブランチ名>」と明示的に表示する- このブランチ名をフェーズ4のPR作成時まで保持する
- 作業ブランチを作成する
- Issue 指定:
fix/#<Issue番号>（例:fix/#42） - テキスト / 引数なし:
fix/<バグの要約>（例:fix/login-500-error）
- Issue 指定:
- TaskCreate でタスクを管理する
フェーズ2: 原因調査
- 再現確認 — バグ報告の再現手順に従い再現を確認。再現不可ならユーザーに追加情報を求める
- 影響範囲の特定 —
ExploreエージェントやGrep/Globで関連コードを調査。関連テストも確認 - 原因の特定 — 根本原因を特定し、コードの流れで裏付ける。原因と修正方針をユーザーに報告し合意を得る
フェーズ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: プルリクエスト
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を参照）
- ベースブランチはフェーズ1で記録した開始時のブランチを指定する。
- 修正サマリーをユーザーに報告する
ルール
- 推測で修正しない。原因を特定してから修正に着手する
- 修正の前に必ず回帰テストを書く（テスト失敗 → 修正 → テスト成功）
- 修正は最小限。バグに無関係なリファクタリングを混ぜない
- 原因と修正方針は必ずユーザーに報告し合意を得る
- 🔴🟠 のレビュー指摘は必ず修正。🟡🟢 は明確なメリットがある場合のみ
- TaskCreate/TaskUpdate で進捗を管理する