| name | persistent-exploration |
| description | 調査が行き詰まったとき、再現できないと判断しそうなとき、「不可能」と結論づける前に使用する。Sentry/ログ起因の調査、再現困難なバグの深掘りに適用する。サブエージェント調査委譲時のprompt注入テンプレート、突破口チェックリストを含む。 |
Persistent Exploration — 探索行動原則
いつ使うか
- Sentry/ログでイベントが発生しているが再現方法が不明なとき
- 「UIから操作不可能」「再現できない」と判断しそうなとき
- サブエージェントに調査タスクを委譲するとき
行動制約テンプレート
サブエージェントに調査タスクを委譲する際、以下をプロンプトに含める:
## 行動制約
- 「不可能」「再現できない」と結論づける前に、最低3つの代替アプローチを試すこと
- Sentry/ログでイベントが発生している場合、発生ルートは必ず存在する。「不可能」は許容しない
- 試したアプローチと結果を構造化して報告すること（探索木形式）
- 未探索のアプローチが残っている場合、それを明示すること
「不可能」判定の前提条件
「不可能」と結論づける前に、以下を全てチェックする:
- データ的証拠: Sentry/ログでイベントが発生しているか → 発生しているなら「不可能」ではない
- 代替アプローチ: 最低3つの別アプローチを試したか
- セカンドオピニオン: SO で「本当に不可能か？」を検証したか
- 前提の再検証: 「不可能」の根拠となっている前提自体が正しいか確認したか
突破口チェックリスト
「UIから操作不可能」「再現できない」と判定した場合に試すべきアプローチ:
- API 直接呼び出し:
page.request、curl、session_api.sh でフロントエンドをバイパス
- フレームワークランタイムデータ操作:
browser_evaluate でコンポーネントデータを直接変更
- ネットワークリクエストのインターセプト・リプレイ: Playwright Route 傍受で条件を変更
- 別のユーザー権限・別のアカウント: 権限差異による挙動の違いを確認
- DB の状態確認: バックフィル漏れ、マイグレーション履歴（データの歴史的経緯）
- バックエンドのバリデーション/ガード確認: フロントエンドガードのみでバックエンドはスルーのケース
- 過去のマイグレーション履歴: データの歴史的経緯がバグの原因になっていないか
探索木フォーマット
試したアプローチと結果を構造化し、未探索のブランチが残っている限り続行する。報告時にこの形式を使う:
<調査対象>
├── アプローチA → 結果 ❌
│ ├── 派生A-1 → 結果 ❌
│ ├── 派生A-2 → 条件付き可能 ⚠️（要確認事項）
│ └── 派生A-3 → 結果 ❌
├── アプローチB
│ ├── 手段B-1 → 失敗 ❌
│ ├── 手段B-2 → 成功 ✅
│ └── 手段B-3 → 未試行
├── アプローチC → 失敗 ❌
└── アプローチD → 未試行
凡例: ✅ 成功 / ❌ 失敗 / ⚠️ 条件付き / 未試行
使用例
サブエージェントへの委譲時:
Sentry で mb_convert_encoding(null) のエラーが発生しています。
対象ファイル: app/Services/Csv/CsvExportService.php
以下を調査してください:
- getValueForCsv() の null が渡されるパスを特定
- 再現手順を確立（UIまたはAPI経由）
## 行動制約
[上記テンプレートを貼り付け]
調査にあたっては persistent-exploration スキルの突破口チェックリストを参照してください:
Read ~/.cursor/skills/persistent-exploration/SKILL.md
