Bug Fix Wt

bug-fix-wt

bug-fix の worktree 隔離版。メインの作業ツリーを汚さずにバグ修正を行う。

前提条件

• Claude Code 環境
• git, gh CLI

引数

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

フェーズ1: バグ報告の整理と worktree 作成

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. git worktree を作成する（手順は references/worktree-setup.md を参照）
6. TaskCreate でタスクを管理する

フェーズ2: 原因調査

重要: フェーズ2以降のすべての操作は worktree ディレクトリ内で行う。

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

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

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

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

3-2: 修正

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

3-3: 検証

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

3-4: Review

• review エージェントで修正内容をレビューする
• プロンプトに worktree パスを含める

3-5: 改善サイクル

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

3-6: Format & Lint

• worktree ディレクトリ内で format/lint を実行。設定なしならスキップ

3-7: Commit

• worktree ディレクトリ内で git add / git commit を実行
• コミットメッセージは CLAUDE.md の規約に従う

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

1. worktree ディレクトリ内で git push -u origin <作業ブランチ> を実行
2. 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 を参照）
3. 修正サマリーと worktree パス をユーザーに報告する

報告例:

## 完了
- PR: <URL>
- Worktree: <パス>（確認後 `git worktree remove <パス>` で削除可能）

ルール

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