octocode-research

Octocode のリサーチ

主張より証拠を優先します。根拠となる箇所を見つけ、正確なバイト列を読み、主張を立証してから、回答または修正を行います。

FRAME → CLASSIFY → MODEL → SEARCH → READ EXACT → PROVE → DECIDE/PATCH → VERIFY

これが全体の流れであり、順番にこなすチェックリストではありません。主張に応じて規模を調整します。小さな検索なら手軽に読み、率直な確信度を示します。一方、削除、マージの判定、根本原因の特定なら、すべての段階を踏みます。すでに答えがわかっている段階は省略してかまいません。ただし、どの段階を省略したかは伝えてください。

ルール

1. 冒頭に1行で、対象コーパス、実際の状態と望ましい状態、タスクの種類、モード、使用した情報源と省略した情報源を示します。
2. 証拠から、サポートされている契約に違反したことがわかる場合に限り、バグと呼びます。
3. 根本原因を示すには、メカニズム、トリガー、違反した契約、乖離が始まる境界、そして排除した別の可能性が必要です。
4. すでに把握している中で最も強力な手掛かりを使います。重要な主張については、「構造」「ストリーム」「接続」のうち2つを確認します。
5. スニペットは手掛かりです。結果が空でも、「そこには存在しない」のではなく、「この調査経路では確認できない」ことを意味します。どちらなのかを明示します。
6. claim → evidence → confidence → next check を追跡します。正確な根拠箇所を示し、実際に行った確認だけを引用します。
7. 広範な契約、削除や名前変更、根拠が乏しい場合、または無関係な検索対象が3つ目に増える場合は、事前に確認します。証明を終えてから修正します。

次の場合は終了します。根拠に基づいて、設定した質問に答えられ、別の可能性も排除できた場合。結論を変えうる手軽な次の手順がない場合。予算に達した場合（既定では決定的な反復を3～5回、または約15分）。直近の反復で状態が変わらなかった場合。再試行しても根拠が乏しい場合、またはライセンス、製品、アーキテクチャの判断をユーザーに委ねるべき場合。ゲートによって進行が止まった場合（広範な契約、削除や名前変更、未信頼コードのクローンまたは実行、未承認の成果物書き込み）。あるいは、スキルの編集結果が変わらない、または悪化した場合。その場合は references/improve-loop.md を使って元に戻します。確信をかさ増しするのではなく、残っている不足を報告してください。

ワークフロー

まず references/algorithm.md（ルーティング、証拠の評価基準）と references/problem-framing.md（これはバグ、機能、改善、それとも未確定なのか？）を確認します。次に、調査対象に応じて1つのルートを選びます。ルートごとの詳細、タスク規模ごとの読み込み予算、またはルート間の引き継ぎ記録が必要な場合は、references/workflows.md を読み込みます。

状況	ルート
このリポジトリ、チェックアウト、インストール済みの依存関係	references/workflow-local.md
外部リポジトリ、npm パッケージ、上流プロジェクト	references/workflow-external.md
リポジトリ間の接続、ローカルの手掛かりから上流へ、または AST／LSP による証明が必要なリモートコード	references/workflow-combination.md
エコシステムの比較 — 複数の候補リポジトリやパッケージ	references/github-landscape.md
何かが失敗し、原因を調べる必要がある	references/workflow-debug.md
コーディングの流れを計画する、実装する、移行する、動作を修正する	references/workflow-change.md
動作を変えずに、構造や名前を変更する	references/workflow-refactor.md
変更後の検証、PR またはローカル差分のレビュー	references/workflow-pr-review.md
呼び出し元、インポート、参照、到達可能性などの接続を追跡する	references/code-research.md

いずれのルートでも、証明の深さについては references/code-research.md を参照してください。コード、パッケージ、ドキュメント、履歴を対象にした一般的なリサーチ（マップ／検証／調査／計画）については、references/research-flow.md を参照してください。

レビューは3つのパートで進めます。まず references/workflow-pr-review.md で対象、ガイドライン、リスクの規模を確認します。次に references/workflow-pr-review-analysis.md で、分析の深さ、処理フローの証明、指摘の形式を確認します。最後に references/workflow-pr-review-report.md で、検証を条件とする推奨事項と、任意の文書作成を扱います。

必要性がある場合に限り、次を参照してください。references/loop-mode.md（証拠が何度も変わる場合）、references/long-research.md（長期的に使える意思決定の要約）、references/researcher-mindset.md（予算、分岐、調査計画）。

現在の手順で必要になった時点で、リファレンスを読み込みます。すべてを読み込むのは失敗につながります。

ツール

利用できる場合は、Octocode の MCP ツールを優先してください。それ以外の場合は npx octocode tools <name> を使用してください。ツールは同じ 15 個で、スキーマも同じであり、機能の損失はありません。

npx octocode context --minimal                         # what's available
npx octocode tools <name> --scheme --json --compact    # read fields — never guess
npx octocode tools <name> --queries '<json>' --compact # run it

1 回の呼び出しで最大 5 件のクエリをまとめて実行できます。正確な読み取りの前に、ツリーや検出など、コストの低い方法で状況を把握してください。返された next.* とカーソルを使い、再導出しないでください。

トランスポート、ツールの選択、認証、ゲート（ENABLE_LOCAL、ENABLE_CLONE、ENABLE_RELEASES）、マテリアライズ、診断、終了コードが不明な場合は、references/octocode.md を読んでください。

出力

Finding · Evidence · Confidence · Next。判断には、結論、リスク、正確なアンカー、検証、そして最小限の安全な修正を追加してください。確信度を水増しせず、情報の不足を報告してください。

関連項目

octocode-brainstorming（構築する価値はあるか？） · octocode-rfc-generator（設計契約） · octocode-graph-eval（目標→KPI） · octocode-documentation（ドキュメントの成果物） · octocode-skills（スキルフォルダー） · octocode-subagent（並列展開） · octocode-roast（批評のトーン）。

このスキルを変更した場合は、node scripts/check-description.mjs（説明の契約。フラグについては --help を参照）を実行し、references/improve-loop.md に従って採用または差し戻しを判断してください。