name: debugging-helper description: Cursor Debug Mode風のAIデバッグワークフロー。仮説生成→ログ挿入→実行→分析→修正の自律的デバッグサイクル。bug、fix、エラー、動かない時に使用。

デバッグ支援スキル（Cursor Debug Mode風）

Cursor IDEのDebug Modeと同様の仕組みで、AIが自律的にバグを特定・修正するワークフローです。

このスキルを使用するタイミング

バグを報告されたとき
原因不明のエラーが発生したとき
レースコンディション、タイミング問題
パフォーマンス問題、メモリリーク
リグレッション（以前動いていたものが動かなくなった）

🔄 デバッグサイクル（5ステップ）

CursorのDebug Modeと同様に、以下のサイクルを繰り返します：

┌─────────────────────────────────────────────────┐
│  1. 仮説生成（Hypothesis Generation）           │
│     ↓                                           │
│  2. ログ挿入（Strategic Logging）               │
│     ↓                                           │
│  3. 再現実行（Bug Reproduction）                │
│     ↓                                           │
│  4. ログ分析（Runtime Analysis）                │
│     ↓                                           │
│  5. 修正適用（Targeted Fix）                    │
│     ↓                                           │
│  [検証] → 問題解決？ → Yes: 完了               │
│                      → No: ステップ1に戻る     │
└─────────────────────────────────────────────────┘

📋 ステップ詳細

ステップ1: 仮説生成（Hypothesis Generation）

バグの根本原因について複数の仮説を立てます。

実行内容:

エラーメッセージ・症状を分析
関連コードを読み込み
最も可能性の高い原因を3つ程度リストアップ

出力形式:

## 仮説リスト

### 仮説1（優先度: 高）
- 原因: 非同期処理の競合により状態が不整合
- 根拠: エラーが断続的に発生、タイミング依存
- 確認方法: ログで実行順序を確認

### 仮説2（優先度: 中）
- 原因: nullチェック漏れ
- 根拠: "Cannot read property of undefined" エラー
- 確認方法: 該当変数の値をログ出力

### 仮説3（優先度: 低）
- 原因: キャッシュの古いデータ
- 根拠: リロードで直ることがある
- 確認方法: キャッシュ状態をログ出力

ステップ2: ログ挿入（Strategic Logging）

仮説を検証するためのログを戦略的に挿入します。

ログ設計原則:

// 🎯 効果的なログ
console.log('[DEBUG][ComponentName] 状態:', {
  timestamp: new Date().toISOString(),
  functionName: 'handleClick',
  input: { userId, action },
  currentState: state,
});

// ❌ 効果のないログ
console.log(data);  // 何のデータかわからない

挿入位置の選定:

async function processData(input) {
  console.log('[DEBUG][processData] 開始:', { input });  // 入口
  
  try {
    const result = await fetchData(input);
    console.log('[DEBUG][processData] fetch完了:', { result });  // 中間
    
    const transformed = transform(result);
    console.log('[DEBUG][processData] 変換完了:', { transformed });  // 中間
    
    return transformed;
  } catch (error) {
    console.error('[DEBUG][processData] エラー:', { error, input });  // エラー
    throw error;
  } finally {
    console.log('[DEBUG][processData] 終了');  // 出口
  }
}

ステップ3: 再現実行（Bug Reproduction）

バグを再現し、ログを収集します。

再現手順の確認:

## 再現手順
1. ログイン状態でホーム画面を開く
2. タイマーを開始する
3. 5秒以内に設定画面に遷移する
4. → エラーが発生する

ブラウザでの実行:

開発サーバーを起動
ブラウザでアプリを開く
再現手順を実行
コンソールログを収集

ステップ4: ログ分析（Runtime Analysis）

収集したログから実行フローを分析します。

分析ポイント:

## ログ分析結果

### 実行順序
1. [10:00:00.100] handleClick 開始
2. [10:00:00.150] fetchData 開始
3. [10:00:00.200] ← ここで画面遷移発生
4. [10:00:00.500] fetchData 完了（コンポーネントはアンマウント済み）
5. [10:00:00.510] setState 呼び出し → エラー！

### 発見した問題
- fetchData完了前にコンポーネントがアンマウントされている
- アンマウント後にsetStateが呼ばれている
- 仮説1（非同期処理の競合）が正しかった

ステップ5: 修正適用（Targeted Fix）

分析結果に基づいて的確な修正を適用します。

修正例:

// Before（問題あり）
useEffect(() => {
  fetchData().then(data => {
    setData(data);  // アンマウント後も呼ばれる
  });
}, []);

// After（修正済み）
useEffect(() => {
  let isMounted = true;
  
  fetchData().then(data => {
    if (isMounted) {
      setData(data);  // マウント中のみ実行
    }
  });
  
  return () => {
    isMounted = false;  // クリーンアップ
  };
}, []);

🧹 デバッグ完了後のクリーンアップ

修正が確認できたら、デバッグ用ログを削除します。

# デバッグログを検索
grep -r "\[DEBUG\]" src/

# または特定のパターンを削除
# console.log('[DEBUG] で始まる行を削除

📊 問題タイプ別アプローチ

問題タイプ	主な仮説	ログ挿入位置
レースコンディション	実行順序の競合	各非同期処理の開始/終了
タイミング問題	イベント順序の不整合	イベントハンドラー
メモリリーク	クリーンアップ漏れ	マウント/アンマウント
状態不整合	更新タイミングのズレ	状態更新箇所
リグレッション	最近の変更による影響	変更されたコード周辺

🤖 AI アシスタント指示

このスキルが有効な場合、以下のサイクルを自律的に実行：

実行フロー

問題の理解
- ユーザーからバグの症状を聞く
- エラーメッセージがあれば収集
仮説生成
- 最低3つの仮説を立てる
- 優先度を付ける
ログ挿入
- 仮説を検証するログをコードに追加
- [DEBUG] プレフィックスを使用
再現依頼
- ユーザーにバグを再現してもらう
- ログ出力の共有を依頼
分析と修正
- ログを分析して原因を特定
- 最小限の修正を適用
検証
- 修正後に再度テストを依頼
- 問題が解決したか確認
クリーンアップ
- デバッグ用ログを削除
- 必要に応じてテストを追加

重要なルール

必ず守ること:

仮説を立ててからログを挿入する
ログは構造化して意味のある情報を出力
修正は最小限に抑える
修正後は必ず検証する

避けること:

推測だけで修正しない
無関係な箇所を変更しない
デバッグログを本番に残さない

debugging-helper

SKILL.md