research

調査

根拠を引用して、呼び出し元が範囲を限定した質問に回答します。質問に応じて、通常の調査、主張の検証、主張された状態の監査、意思決定の経緯、リポジトリの追跡、パターンの証拠を選びます。これらは任意のモードであり、順番に実行するものではありません。簡潔な回答であれば、レポートファイルは不要です。 質問が変更の具体化に関するものであれば、Plan が統一された探索と再開を担います。既存の意図に沿って、この引用付き回答を返し、聞き取りを最初からやり直したり、呼び出し元の選択を引き受けたりしないでください。

証拠のルール

• 同じ系譜は一度だけ数えます。 ある上流ソースを複製、移植、反復引用したものは、いくつのファイルやレポートに記載されていても、単一の事例です。事例を独立したものとして数える前に出所を確認し、新しい検索で既読のソースしか見つからなくなったら、調査を終了してください。
• 不変条件と偶発的な要素を切り分けます。 挙動における役割に沿って事例を照合し、必ず満たすべきこと、正当に異なり得ること、偶発的な構文を明示します。不変条件を満たさない事例は、該当する事例ではありません。
• 繰り返し見られるだけではゲートを設ける根拠になりません。 ブロッキングチェックには、パターンの欠如に起因するインシデント、欠陥、測定された損害など、違反によるコストが実証されている必要があります。必要なコミットメントが最も少なく、役に立つ形を推奨してください。対応なし、参考資料またはチェックリスト項目、テンプレート、ヘルパーの順に検討し、ゲートは最後に検討します。
• 証拠が乏しければ、仮説のまま扱います。 独立した事例が3件未満、またはパスしたホールドアウトがなければ、そのパターンは仮説のままです。何を証拠とすれば確認または反証できるかを述べてください。
• 観察、推論、矛盾、不明点を分けてください。重要な主張にはすべて証拠を引用します。文書やレポートに由来する主張には、その主張を明示する箇所を引用してください。話題に触れているだけの箇所を根拠にしてはならず、そうでなければ未裏付けであると明記します。決定的な主張が単一のソースに基づく場合は、その旨を述べてください。複数のソースが一致しても、出所が共通である事実は変わりません。
• 呼び出しが示すのは、呼び出し先の挙動ではありません。 コードが retry、validate、またはサービスを呼び出していることから分かるのは、呼び出しが行われることだけです。呼び出し先が何を保証するか（再試行、アトミック性、冪等性、順序性、永続性）を前提に主張する前に、その実装またはテスト、あるいは外部サービスの公開仕様を確認してください。確認できない場合、後から但し書きを加えるのではなく、主張自体の中で保証が不明であると明記してください。
• 何も見つからなかった検索が不在の証拠になるのは、検索条件に合致し得た場合だけです。 何かが存在しない、または使われていないと述べる前に、検索の終了ステータスとエラー出力、結果が切り詰められていないか、無視ルールや既定のフィルターで関連パス（無視対象、非表示、ベンダー提供、生成済みファイル）が除外されていないか、古いインデックスではなく意図した ref またはツリーを検索したかを確認してください。簡単にできる場合は、存在が分かっている語句も同じ検索で見つかることを確認します。失敗した検索や対象範囲を誤った検索は、「見つからなかった」ではなく、原因を添えた不明点として扱います。「未使用」または「これを呼び出すものはない」という主張については、テキスト検索では再エクスポート、エイリアス、リフレクション、文字列キーによるディスパッチ、依存性注入、生成コード、外部の利用者を見落とすこともあります。ホストに参照認識機能を備えたツールがある場合は、それを優先し、これらのうち何を確認できていないかを明示してください。

調査

1. 質問と、それがどの判断に役立つのかを明示します。合意済みの範囲を再利用し、質問に答えるために必要な証拠を特定します。検索の途中で目的を広げないでください。依頼者が指定した対象、範囲、情報源を使います。隣接する対象について回答するのではなく、範囲が空である場合、対象が欠けている場合、指定された情報源に到達できない場合は、その旨を報告します。依頼者が代替を認めている場合は、その代替を明示します。
2. 関連する最小限の情報源を調べ、検索結果を実際の情報源と照合します。変化する外部の事実（バージョン、ベンダーの挙動、標準）には、ホストのウェブツールが利用可能で許可されている場合はそれを使って、最新の一次情報源を確認する必要があります。それ以外の場合は、主張を不明とし、確認に必要な情報源を明示します。クエリがホストの外部に送信される前に、ホスト名、IP アドレス、ファイルパス、クエリの断片、アカウントまたは顧客の識別情報、内部名を取り除き、ライブラリとバージョンを添えて一般的なエラー分類で検索します。安全な形式にできない場合は検索を見送り、その旨を伝えます。サードパーティのライブラリ、ツール、サービスがこの環境でどう動作するかについては、このリポジトリが解決するバージョン（ロックファイル、インストール済みバイナリのバージョン、またはベンダー提供のコピー）と、そのバージョンのソース、テスト、リリースノートに基づいて回答します。最新のドキュメント、ウェブ上の回答、記憶は手掛かりにすぎないため、別のバージョンについて説明している場合はその旨を伝えます。外部 API、SDK、認証スコープ、サービスを推奨する前に、そのバージョンに関する非推奨化、提供終了、破壊的変更の告知を確認し、該当する告知を示すか、状況を未確認と伝えます。
3. まず回答を示し、次に証拠と残る不足を示します。質問の各部分には、調査した範囲を明らかにしたうえで回答するか、明示的に不明とします。重大な結論を確定する前に、最も有力な反証を一度探します。説明を求められた場合は、依頼者の知識レベルに合わせて平易な言葉で書き、どの理由が文書化されたものか、どれが推論か、どれが不明かを示します。

コードに関する主張には、確認したコミットと file:line を引用します。未コミットの内容については、HEAD と変更ファイルの状態を示し、作業ツリー上のバイト列を HEAD から再現できるとは主張しません。情報源の識別情報と鮮度を明確にします。検索結果、CASS、MS、過去の報告は手掛かりであり、権威ある情報源でも必須の手順でもありません。原則として現在のエージェントを使います。追加の閲覧者やランタイムには、依頼者の選択または既存の認可が必要です。

複数の報告が提示された場合は、それぞれの情報源 ID、判明している場合は作成者／ランタイム、リビジョン／日付を保持します。各主張を、元の証拠を保ったまま、一致、矛盾、不明として比較します。決定的な主張は情報源で検証し、ひとつに統合した結果を返します。再帰的な統合処理は実行しません。

主張の検証

草稿、報告、回答が正しいか確認するには、情報源が肯定または否定できる単一の主張に分解します。作業が完了した、出荷された、または接続されたという主張は、claimed-state audit の対象です。意見や予測は検証対象ではないため、その旨を伝えます。まず、誤解を招く影響が最も大きいもの、つまり数値、引用、帰属、最上級表現、結論の根拠となる主張を確認します。学習時の記憶は手掛かりにすぎず、情報源ではありません。

• 読み直すのではなく、独立して導き直します。 データ（クエリ、スクリプト、リポジトリ内の件数）から導かれた主張は、別のクエリ、異なるキーやグループ化、または基になるファイルそのものを使って、別の経路で確認します。生成元を再実行すると同じ誤りが繰り返され、報告書に記載された数値はその報告書の証拠にはなりません。
• 関連があることは、執筆者であることを意味しません。「X が Y を書いた、決定した、または引き起こした」という主張には、その関係を正確に示す記述または記録が必要です。同じコミット、会議、文書に登場することはより弱い証拠であり、そのように報告します。
• 各主張を、引用と使用した調査経路を添えて、裏付けあり、反証あり、裏付けなし、または検証不能として返します。修正は提案です。検証対象文書の編集は Doc の範囲です。

主張された状態の監査

作業が完了、リリース済み、修正済み、動作中、または接続済みであるという主張（エージェントの完了報告、チケットの要約、変更履歴の記述、ステータス投稿など）について、期待される状態と確認可能な証拠を項目ごとに照合します。ここで挙げる失敗パターンは、差分が変更した箇所だけを監査することです。主張された項目が証拠に見当たらない場合、それは報告から除外するのではなく、欠落として扱います。

明示された主張の確認、宣言された目標の測定、またはネイティブなステータスの報告を求められた場合は、追加の質問をせずにこの監査を選択します。主張も確定した目的もない単なる「準備できていますか？」という質問は曖昧です。助言または受け入れの共通ルールに従い、一度だけ質問してください。この監査は受け入れではなく、Validateによる新鮮な、作成者とは別の判断の代わりにはなりません。受け入れが求められている場合は引き継ぎ、新たなレビュー担当者がいないことを欠落として報告してください。

1. 正確な主張とその出典を読み、まだ着手されていない作業も含め、それぞれの項目に分割します。
2. 各項目にそれぞれ判定を付けます。確認済み（証拠を引用）、欠落（不足している、または主張と矛盾するものを引用）、または検証不能（判定に必要な証拠を明記）です。証拠が示す範囲でのみ評価してください。出力のない実行報告、既定値や別のコンポーネントに委ねられた動作、主張された結果を検証しないコード実行テストは、確認済みではなく検証不能です。テストできない主張を断定で解決してはいけません。
3. 実行中のエントリーポイントから到達可能であること。 本番環境から呼び出される実行中のエントリーポイント（ルート、コマンド、ジョブ、ハンドラー、エクスポートされた API など）から到達できないコードは、そのコード自体のテスト結果にかかわらず、接続済みではありません。動作が実装されているという主張については、その背後のコードも調べ、見せかけの実装がないか確認してください。対象には、定数やハードコードされた結果、TODO や未実装の分岐、サンプルデータ、テストコード外のテストダブルが含まれます。該当箇所はそれぞれ呼び出し元まで追跡してから分類してください。本番経路が到達するプレースホルダーは欠落として扱います。テストでのみ使われるテストダブルや、どこからも呼び出されないコードは該当しません。
4. 配信済みとは、現在のリモート状態で到達可能であることです。 指定されたコミットまたはプルリクエストで作業がプッシュ済み、マージ済み、リリース済み、または修正済みであるという主張は、ローカルの参照、プッシュ出力、保存されたステータスではなく、到達可能性によって判断します。対象のヘッドに内容が現在も存在し、主張どおりに動作するかは、上記の方法で確認します。プッシュ済みとは、指定されたリモートブランチ、またはフォークを含むプルリクエストの現在のヘッドリポジトリ内のヘッドから到達可能であることを指します。マージ済みとは、主張で指定されたターゲットブランチ、指定がなければデフォルトブランチのヘッドから到達可能であるか、そのブランチをベースとするプルリクエストがマージ済みであることを指します。別のベースブランチへのマージでは確認できません。リリース済みとは、リポジトリのリリースポリシーで定められた対象（タグ、公開リリース、デプロイメントなど）に存在することを指し、その情報源から確認します。スクワッシュまたはリベースによって祖先関係が失われている場合は、同等のコミットだと推測せず、ターゲットと内容を比較してください。指定された SHA またはプルリクエスト番号は、コマンドに渡す前に形式を確認してください。
5. 計画の場合は、提案されたスコープを元の目標と照合します。権限のない追加はスコープの拡大であり、報告によって承認することはできません。測定を繰り返す場合は同じ質問と基準を再利用します。質問が変わった場合は、別の比較を開始します。
6. 確認済みと未確認のスコープを含む台帳を返します。ネイティブなトラッカー、Git、ランタイム、決定的なチェック、意味的判断に関する事実は、区別して記載します。

Claim: <the claim as stated, and where it came from>
| # | Stated item | Disposition | Evidence, or what would settle it |
|---|---|---|---|
| 1 | <item> | confirmed / gap / unverifiable | <file:line, command output, artifact> |
Checked: <what was inspected>. Not checked: <what was not>.

台帳は証拠を報告するものであり、すべての項目が確認済みの場合でも、総合的な PASS、FAIL、判定、準備状況の判断は含めません。その永続的な形式については、出力と境界を参照してください。

ヘルス、目標、ステータス

「このリポジトリは健全か」または「チェックに合格するか」と尋ねられた場合は、プロジェクト独自の読み取り専用チェック（手順書や CI 設定で宣言されているもの、またはビルドファイルで見つかったもの）を実行します。--check、ドライラン、検証用の形式があれば優先し、各チェックの出所を記録します。追跡対象ファイルへの書き込み、公開、デプロイを行う手順や、認証情報が必要な手順は、その理由を添えて未実行として記載します。各チェックは個別に実行し、失敗後も続行します。それぞれの結果を、出力を解析した結果ではなく終了ステータスに基づいて、合格、失敗、未実行（ツールを利用できない）、または未判定（出力を取得できなかった）として報告し、実行しなかった宣言済みチェックにも言及します。修正は行わず、失敗を隠すような単一スコアに結果をまとめないでください。

宣言された目標ソースに対する ao goals の実行方法は目標に、ao status によるエビデンスストアの読み取り方法と、スナップショットでは分からないことはステータスに記載されています。最近のアーティファクトのタイムスタンプが示すのはエビデンスの新しさであり、ワーカーが稼働中であることではありません。目標の追加、削除、優先順位付け、移行、修復を行ったり、測定上のギャップを割り当て済みの作業に変えたりしないでください。

導入に関する質問

「X を導入、置き換え、または使い続けるべきか」や「アドバイザリー Y は当社に関係するか」と尋ねられた場合、回答には両方の側面が必要です。こちら側では、現在のツールと、それが使われていることを示す引用可能な箇所、または検索して見つからなかったことと X の導入箇所、さらに同じ質問に関する以前の決定を示します。相手側では、回答の根拠となる外部事実ごとに、最新の一次情報源を示します。片方の側面が強くても、もう片方の欠落は補えません。その場合は「現時点では回答できません」と答え、調査すべき内容を列挙します。現在のツールを使い続けることや、何もしないことも現実的な選択肢です。情報源の選定、順位付け、適合性、使い続けるコスト、保守に関する事実は導入エビデンスに記載されています。

意思決定の経緯

「なぜこうなっているのか」や「このアイデアはどのように変化したのか」と尋ねられた場合は、1 つの決定またはアイデアを、コミット、ADR、イシュー、レビュー、過去のレポートを通じてたどり、日付と引用を付けた次の分類に整理します。初出、最も明確な記述、現在の形、撤回、矛盾（両立しない 2 つの主張）、放棄された案です。該当する項目がない分類には、何を検索したかを記載します。置き換えは矛盾ではありません。入り組んだ経緯を整然とした物語にまとめないでください。過去の理由を拘束力のあるものとして提示する前に、その原因が現在のツリーまたは記録でもなお当てはまるかを確認します。当てはまらない場合は、再検討の根拠として報告し、判断はその所有者または依頼者に委ねます。

リポジトリの追跡

リポジトリのモデル化または監査では、ドキュメント、ビルドマニフェスト、コマンドのヘルプで宣言されているエントリーポイントから開始し、実行可能なパスと照合して確認します。関連するフローをエントリー、ドメインロジック、統合、テストまでたどり、浅いディレクトリ一覧よりも、完了した追跡を優先します。追跡が中断した場合は、該当する正確なファイル名と行番号を報告し、不足しているものを説明します。永続化、認可、CLI、ビルド、テストなど、役に立つ観点を選びます。あらゆる観点を網羅的に調べる必要はありません。どの追跡でも（仕組みの説明を含め）、各ステップで何を読み取るか、または変更するかを示し、成功パスだけでなく、質問に関係するエラー分岐やエッジケースも残します。動作を裏付けるのはソースコードとテストです。ファイル名や会話中の主張は根拠になりません。

インライン調査では、明示的に制限を示したうえで、作業ツリーがダーティな状態のエビデンスを使うことがあります。選択された永続的な codebase-recon.v1 パックはコミットに紐づいています。

パターンのエビデンス

実装パターンが繰り返し現れる場合は、上記のエビデンスルールに照らして、その類似性が再利用可能なルールを示すものかを検証します。再現可能な検索、確認した検索結果、除外した項目を記録したうえで、次のように報告します。

exemplars: <file:line> per independent lineage; copies listed under their source
invariant: <what every exemplar shares and the behavior needs>
variation: <legitimate differences>; incidental: <syntax, names>
cost:      <demonstrated cost of violation, or "none found">
shape:     <no-action | reference-line | template | helper | gate> and why
outcome:   hypothesis | promote (three independent exemplars, passing holdout and back-application)

調査によってエビデンスを提示し、導入の判断は依頼者が明示的に行います。

出力と境界

<skill-dir> は、この SKILL.md を含むディレクトリです。Claude Code では「このスキルのベースディレクトリ」として表示され、Codex ではこのスキルの SKILL.md のパスが表示されます。AgentOps のソースチェックアウトでは skills/research です。コマンドを実行する前に、<skill-dir> をその絶対パスに置き換えてください。作業ディレクトリはユーザーのリポジトリのままにします。ホストにこのスキルのインストール場所が表示されていない場合は、読み込んだ SKILL.md のディレクトリを使用してください。特定できない場合は、パスを推測したり、現在のリポジトリにある同名のスクリプトを実行したりせず、同梱スクリプトが利用できないことを伝え、アーティファクトのフィールドを形式と照らし合わせて手作業で確認してください。

永続的な出力が要求されている場合、または選択したモードで必要な場合を除き、引用を付けた回答を直接返してください。レポートを保存する場合は、呼び出し元が指定した場所を使用し、指定がなければリポジトリに既存のリサーチ用または意思決定メモ用の保存場所と命名規則を使用してください。どちらもない場合は、回答を返して保存先を尋ねてください。ファイルを読み戻し、正確なパスを報告してください。各永続化モードでは、それぞれ固有の形式を使用します。

• 通常のレポート： findings.json では、topic、summary、findings（各項目は area、observation、evidence、任意の implications）、checked、not_checked、schema_version: 1 のみが許可されます。複数レポートの統合では、source_ledger と comparison（agreements、contradictions、unknowns）を追加します。
• 主張された状態の監査： reality-check-report.v1 形式の reality-check-report.json を使用します。この名前は廃止された Reality Check スキルから引き継がれたものです。claim、記載された項目ごとに 1 行の coverage（goal（項目）、disposition、および確認済みとギャップの場合に必須となる evidence を含む）、さらに category（confirmed、gap、incomplete-evidence、changed-assumption のいずれか）、statement、引用した evidence を含む findings を少なくとも 1 件含めます。すべての項目が検証不能な場合は、検索内容を引用した incomplete-evidence の所見を 1 件記録してください。verdict、readiness、PASS フィールドはありません。次のコマンドで検証してください。 bash "<skill-dir>/scripts/claim-audit/validate-output.sh" <report.json>.
• リポジトリのトレース： recon pack contract による codebase-recon.v1 を使用し、次のコマンドで検証します。 bash "<skill-dir>/scripts/codebase-recon/validate-output.sh" --repo-root <target> <recon.json>.
• パターンの根拠： pattern pack contract による pattern-mining.v1 を使用し、次のコマンドで検証します。 bash "<skill-dir>/scripts/pattern-mining/validate-output.sh" <pattern.json>.

許可されたソースと保存先のみを使用してください。制限対象または抽出されたエピソード資料については、Memory のアクセスおよび保存の境界に従ってください。Research は作業を選択せず、統合されたコンテキストストアを所有せず、ライフサイクルの状態を変更せず、意味上の判定を下しません。要求されたレポートとパックを除き、出力に伴う副作用は、文書化されたゴールスナップショットと、主張された状態の監査で要求されたレポート／仕様の書き込みのみです。許可された結果の実装、判断、完了は、ネイティブの呼び出し元が担います。