research-ops

name	research-ops
description	ECC のためのエビデンスファーストな現状リサーチワークフロー。ユーザーが最新の事実、比較、エンリッチメント、または現在の公開エビデンスと提供されたローカルコンテキストから構築された推奨事項を必要とする場合に使用します。
origin	ECC

Research Ops

ユーザーが現状を調査する、オプションを比較する、人や会社をエンリッチする、繰り返しの調査をモニター付きワークフローに変えることを依頼した場合にこれを使用します。

これは repo のリサーチスタックのオペレーターラッパーです。deep-research、exa-search、market-research の代替ではなく、いつどのように一緒に使うかを教えるものです。

スキルスタック

関連する場合、以下の ECC ネイティブスキルをワークフローに取り込みます:

• 素早い最新 Web 探索には exa-search
• 引用付きの複数ソース統合には deep-research
• 最終結果が推奨事項やランク付けされた決定であるべき場合は market-research
• タスクが人/会社のターゲティングであって一般的なリサーチでない場合は lead-intelligence
• 結果を後で永続的なコンテキストに保存すべき場合は knowledge-ops

使用タイミング

• ユーザーが "リサーチ"、"調べて"、"比較"、"誰と話すべき"、"最新は何" と言った場合
• 答えが現在の公開情報に依存する場合
• ユーザーが既にエビデンスを提供しており、新しい推奨事項に反映してほしい場合
• タスクが十分に繰り返されており、ワンオフのルックアップではなくモニターになるべき場合

ガードレール

• 新しい検索が安い場合、古い記憶から現状の質問に答えない
• 次を分離する:
  • ソース付きの事実
  • ユーザー提供のエビデンス
  • 推論
  • 推奨事項
• 答えが既にローカルコードやドキュメントにある場合、重量級のリサーチパスを立ち上げない

ワークフロー

1. ユーザーが既に与えたものから始める

提供された資料を以下に正規化する:

• 既にエビデンスのある事実
• 検証が必要なもの
• オープンな質問

ユーザーが既にモデルの一部を構築している場合、ゼロから分析を再開しない。

2. 依頼を分類する

検索前に適切なレーンを選ぶ:

• 素早い事実回答
• 比較または決定メモ
• リード/エンリッチメントパス
• 継続的なモニタリング候補

3. 最も軽量な有用なエビデンスパスから始める

• 素早い探索には exa-search
• 統合や複数ソースが重要な場合は deep-research にエスカレート
• 結果が推奨事項で終わるべき場合は market-research
• 本当の依頼がターゲットランキングやウォームパスの探索の場合は lead-intelligence にハンドオフ

4. エビデンスの境界を明示して報告する

重要な主張について、以下のいずれかを明示する:

• ソース付きの事実
• ユーザー提供のコンテキスト
• 推論
• 推奨事項

鮮度依存の回答には具体的な日付を含める。

5. タスクを手動のままにすべきか判断する

ユーザーが同じリサーチ質問を繰り返し行う可能性が高い場合は明示的にそう伝え、同じ手動検索を永遠に繰り返すのではなく、モニタリングまたはワークフロー層を推奨する。

出力フォーマット

QUESTION TYPE
- 事実 / 比較 / エンリッチメント / モニタリング

EVIDENCE
- ソース付きの事実
- ユーザー提供のコンテキスト

INFERENCE
- エビデンスから導かれること

RECOMMENDATION
- 答えまたは次の一手
- これがモニターになるべきか

落とし穴

• ラベル付けせずに推論をソース付きの事実に混ぜない
• ユーザー提供のエビデンスを無視しない
• ローカル repo コンテキストで答えられる質問に重量級のリサーチレーンを使わない
• 鮮度依存の答えを日付なしで与えない

検証

• 重要な主張がエビデンスタイプでラベル付けされている
• 鮮度依存の出力に日付が含まれている
• 最終的な推奨事項が実際に使用したリサーチモードと一致している