一键导入
persistent-exploration
調査が行き詰まったとき、再現できないと判断しそうなとき、「不可能」と結論づける前に使用する。Sentry/ログ起因の調査、再現困難なバグの深掘りに適用する。サブエージェント調査委譲時のprompt注入テンプレート、突破口チェックリストを含む。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
調査が行き詰まったとき、再現できないと判断しそうなとき、「不可能」と結論づける前に使用する。Sentry/ログ起因の調査、再現困難なバグの深掘りに適用する。サブエージェント調査委譲時のprompt注入テンプレート、突破口チェックリストを含む。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | persistent-exploration |
| description | 調査が行き詰まったとき、再現できないと判断しそうなとき、「不可能」と結論づける前に使用する。Sentry/ログ起因の調査、再現困難なバグの深掘りに適用する。サブエージェント調査委譲時のprompt注入テンプレート、突破口チェックリストを含む。 |
サブエージェントに調査タスクを委譲する際、以下をプロンプトに含める:
## 行動制約
- 「不可能」「再現できない」と結論づける前に、最低3つの代替アプローチを試すこと
- Sentry/ログでイベントが発生している場合、発生ルートは必ず存在する。「不可能」は許容しない
- 試したアプローチと結果を構造化して報告すること(探索木形式)
- 未探索のアプローチが残っている場合、それを明示すること
「不可能」と結論づける前に、以下を全てチェックする:
「UIから操作不可能」「再現できない」と判定した場合に試すべきアプローチ:
page.request、curl、session_api.sh でフロントエンドをバイパスbrowser_evaluate でコンポーネントデータを直接変更試したアプローチと結果を構造化し、未探索のブランチが残っている限り続行する。報告時にこの形式を使う:
<調査対象>
├── アプローチ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
親子 Claude Code セッション間の委譲操作を行う。delegate(子を起動してキック)、send(既存ペインへ1行/キックオフ送信・誤送信防止つき)、list(宛先確認)、report(子→親の申し送り)を自然言語の意図から判断して実行する。tmux 環境前提。
oe-* オーケストレーションツール群(engine 本体 / 親子委譲 / SO ゲート / 選択・観測)と駆動層規律の統合概観。複数エージェント委譲・設計SO/実装SO・read-only 観測・engine 1 サイクルを使うとき、ツール群の全体像をリポジトリ走査でなく一貫した形で把握したいときに使用する。
エラー/バグ調査で、入力→出力のコードパスに未読区間がある限り外部要因(インフラ差異等)の仮説に進まない。外部要因に飛ぼうとするとき、原因が再現しないと判断しそうなときに使用する。仮説を tmp/hypothesis-NNN.md に外部化し、コードパスの read-state を可視化する。
プランをKickoff Document形式に変換する。セカンドオピニオン投入・リポジトリアーカイブ・ピアレビュー共有時に使用する。命名規約・frontmatter・セクション構造をKickoff形式に整える。
設計判断を確定する前に、ゼロベースで未探索の代替案を最低1回引き出し、その証跡を確定前に残してから確定する。複数の選択肢を A/B 等で確定しかけたとき、ADR / Decision / kickoff の設計判断(DJ-N)を確定・記録するときに使用する。so-compare 選択肢拡張・探索木の外部化を含む。
so-compare.shでセカンドオピニオン(Codex/Claude/Cursor)を取得し、結果を比較する。ピアレビュー、修正方針の検証、設計判断の反証に使用する。**弱 SO**(1周可・partial=disclose・0はなし)。プロンプト設計原則、結果読み込み手順、合意判定基準を含む。