Bug Fix

バグ修正完全ワークフロー

バグ発見から修正完了までの完全なライフサイクルを自動化します。

全体フロー

Phase規約: workflow-phase-convention skill を参照

サーキットブレーカー

自動検出トリガー

Sisyphusが会話からバグ報告を自動検出します。

検出パターン

# 明示的Issue/PR番号（優先度: 高）
issue_match = re.search(r'Issue #(\d+).*(修正|fix|直)', user_message)
pr_match = re.search(r'PR #(\d+).*(レビュー|指摘|修正)', user_message)

# 具体的不具合（優先度: 中）- LLM判定で誤検知回避
patterns = [r'(.+)が反映されない', r'(.+)が動作しない', r'(.+)がエラーになる']

# 一般キーワード（優先度: 低）- ユーザー確認必須
keywords = ["バグ", "bug", "不具合", "動かない", "エラー"]

誤検知回避

Phase 1: Issue確認/作成

既存Issue確認

# ユーザーが明示的にIssue番号を指定した場合
gh issue view {issue_id} --json state,title

# 類似Issueを検索
gh issue list --state open --label bug --limit 20 --json number,title

Issue作成提案

既存Issueがない場合、ユーザーに作成を提案:

## バグ報告 - Issue作成提案

- **タイトル**: `fix: {summary}`
- **ラベル**: `bug`
- **説明**: 現象、期待動作、再現手順

**このIssueを作成して修正を開始しますか？**
- `作成`: Issue作成 → 修正開始
- `既存利用 #XX`: 既存Issue #XX を使用
- `キャンセル`: 中断

Phase 1.5: 環境選択

詳細: worktree-workflow skill

Phase 2: 実装（実装フェーズ呼出）

バグ修正は実装フェーズを内部で呼び出して実行。 違いは以下のBugfix Ruleのみ:

Bugfix Rule（実装ガイドライン）

リファクタリング判定基準

Regression Test免除条件

Phase 2.5: ユーザー承認ゲート

共通仕様: approval-gate skill を参照

## 承認リクエスト: バグ修正PR作成

**Issue**: #{issue_id}
**修正内容**: {fix_summary}
**変更行数**: {changed_lines}行（{changed_files}ファイル）

### レビュー結果
- スコア: {score}/10
- Regression Test: 追加済み

---
**選択肢**:

1. 続行 → PR作成へ進む
2. 中断 → 修正を中断
3. 修正 → 指摘箇所を修正

> 番号を選択してください（1-3）:

Phase 3: PR作成

バグ修正専用PRテンプレート:

## 概要
Closes #{issue_id}

## Root Cause Analysis（根本原因分析）

### 原因
{root_cause_description}

### 修正内容
{fix_description}
**修正行数**: {changed_lines}行（{changed_files}ファイル）

### 影響範囲
{impact_scope}
**デグレードリスク**: 低/中/高

## Regression Test
- `test_fix_issue_{issue_id}_*`: バグ再現テスト
- 修正前: ❌ 失敗 / 修正後: ✅ 成功

## Bugfix Rule遵守チェック
- [x] 最小変更の原則（リファクタリングなし）
- [x] Regression Test追加
- [x] 原因記録
- [x] 影響範囲確認（全テスト通過）

CI監視 & マージ & クリーンアップ

詳細: ci-workflow skill, pr-merge-workflow skill

レビュー指摘対応（PRコメント対応）

def handle_pr_review_feedback(pr_number: int):
    # 1. 既存環境の再利用確認
    # (worktreeがあるなら移動、なければ作成)
    
    # 2. 修正実施 → push
    bash(
        command="git add . && git commit -m 'fix: レビュー指摘対応' && git push"
    )
    
    # 3. CI再監視
    post_pr_workflow(pr_number)

エスカレーション条件

品質レビュー3回失敗時

## ⚠️ 品質レビュー基準未達（3回失敗）

### レビュー履歴
| 回数 | スコア | 主な指摘 |
|------|--------|----------|
| 1 | 7/10 | ... |
| 2 | 8/10 | ... |
| 3 | 8/10 | ... |

### Draft PR作成済み
- **PR**: #{pr_number}

**次のステップを選択してください**:

1. 続行 → さらに修正を試行（最大2回）
2. 手動対応 → Draft PRを手動でレビュー・修正
3. 中断 → Issue再検討

> 番号を選択してください（1-3）:

ユースケース例

例1: 会話から自動検出

User: "--timeout 30 オプションが反映されていないようです"

Sisyphus:
1. バグ報告を検出
2. Issue作成提案 → ユーザー承認
3. 実装フェーズ呼出（Bugfix Rule適用）
4. PR作成 → CI → マージ → クリーンナップ

例2: 明示的なIssue番号指定

User: "Issue #64 を修正してください"

Sisyphus:
1. Issue #64 を取得
2. fix/issue-64-* ブランチ作成
3. 実装フェーズ呼出

例3: PRレビュー指摘対応

User: "PR #42 のレビュー指摘に対応してください"

Sisyphus:
1. PR #42 から Issue/環境を特定
2. 既存環境を再開
3. 修正実施 → push → CI再監視

関連ドキュメント

まとめ

ユーザーは「バグがある」と報告するだけで、残りは全自動で完了します。