research-ops
以證據優先的方式研究最新資訊，並區分事實、推論與建議
中文翻譯
--- name: research-ops description: ECC 的證據優先、針對現況的研究工作流程。使用者要新鮮的事實、比較、資料補充，或根據最新公開證據和提供的本地情境做出建議時使用。 metadata: origin: ECC --- # Research Ops 使用者要你研究目前的某件事、比較選項、補充人物或公司的資料，或把重複的查詢變成受監控的工作流程時，使用這個 skill。 這是 repo 研究工具堆疊外面的操作層包裝。它不是 `deep-research`、`exa-search` 或 `market-research` 的替代品，而是告訴你什麼時候、怎麼把它們搭配起來用。 ## Skill 堆疊 相關時，把這些 ECC 原生的 skill 拉進工作流程： - `exa-search`：快速探索目前的網路內容 - `deep-research`：多來源綜合，附引用 - `market-research`：最終結果應該是建議或排序後的決策時 - `lead-intelligence`：任務是鎖定人物／公司，而不是一般研究時 - `knowledge-ops`：結果之後要存進持久的情境時 ## 何時使用 - 使用者說「research」、「look up」、「compare」、「who should I talk to」或「what's the latest」 - 答案取決於目前的公開資訊 - 使用者已經提供證據，想把它納入新的建議 - 這個任務可能會一再發生，值得變成監控，而不是一次性的查詢 ## 防護欄 - 重新搜尋成本很低的時候，不要憑過期的記憶回答現況問題 - 要區分： - 有來源的事實 - 使用者提供的證據 - 推論 - 建議 - 如果答案已經在本地程式碼或文件裡，就不要啟動重量級的研究流程 ## 工作流程 ### 1. 從使用者已經給你的東西開始 把提供的任何材料整理成： - 已有證據的事實 - 需要驗證的 - 未解的問題 如果使用者已經建好部分模型，不要從零重新分析。 ### 2. 分類這個請求 搜尋之前先選對路線： - 快速的事實性回答 - 比較或決策備忘錄 - 潛在客戶／資料補充 - 值得持續監控的候選 ### 3. 先走最輕量而有用的證據路徑 - 快速探索用 `exa-search` - 需要綜合或多個來源時，升級到 `deep-research` - 結果應該以建議收尾時，用 `market-research` - 真正的需求是目標排序或找暖路徑時，交給 `lead-intelligence` ### 4. 報告時明確劃出證據界線 重要的主張，要說明它們是： - 有來源的事實 - 使用者提供的情境 - 推論 - 建議 對時效敏感的回答，要包含具體日期。 ### 5. 決定這個任務是否該繼續手動 如果使用者很可能會一再問同樣的研究問題，就明確講出來，並建議用監控或工作流程層，不要永遠重複同樣的手動搜尋。 ## 輸出格式 ```text 問題類型 (QUESTION TYPE) - 事實 / 比較 / 資料補充 / 監控 證據 (EVIDENCE) - 有來源的事實 - 使用者提供的情境 推論 (INFERENCE) - 從證據推得的結論 建議 (RECOMMENDATION) - 答案或下一步 - 這是否該變成監控 ``` ## 陷阱 - 不要把推論混進有來源的事實裡而不標示 - 不要忽略使用者提供的證據 - 本地 repo 情境就能回答的問題，不要用重量級的研究路線 - 對時效敏感的回答不要不附日期 ## 驗證 - 重要的主張都有標示證據類型 - 對時效敏感的輸出包含日期 - 最終建議符合實際用的研究模式
英文原文
--- name: research-ops description: Evidence-first current-state research workflow for ECC. Use when the user wants fresh facts, comparisons, enrichment, or a recommendation built from current public evidence and any supplied local context. metadata: origin: ECC --- # Research Ops Use this when the user asks to research something current, compare options, enrich people or companies, or turn repeated lookups into a monitored workflow. This is the operator wrapper around the repo's research stack. It is not a replacement for `deep-research`, `exa-search`, or `market-research`; it tells you when and how to use them together. ## Skill Stack Pull these ECC-native skills into the workflow when relevant: - `exa-search` for fast current-web discovery - `deep-research` for multi-source synthesis with citations - `market-research` when the end result should be a recommendation or ranked decision - `lead-intelligence` when the task is people/company targeting instead of generic research - `knowledge-ops` when the result should be stored in durable context afterward ## When to Use - user says "research", "look up", "compare", "who should I talk to", or "what's the latest" - the answer depends on current public information - the user already supplied evidence and wants it factored into a fresh recommendation - the task may be recurring enough that it should become a monitor instead of a one-off lookup ## Guardrails - do not answer current questions from stale memory when fresh search is cheap - separate: - sourced fact - user-provided evidence - inference - recommendation - do not spin up a heavyweight research pass if the answer is already in local code or docs ## Workflow ### 1. Start from what the user already gave you Normalize any supplied material into: - already-evidenced facts - needs verification - open questions Do not restart the analysis from zero if the user already built part of the model. ### 2. Classify the ask Choose the right lane before searching: - quick factual answer - comparison or decision memo - lead/enrichment pass - recurring monitoring candidate ### 3. Take the lightest useful evidence path first - use `exa-search` for fast discovery - escalate to `deep-research` when synthesis or multiple sources matter - use `market-research` when the outcome should end in a recommendation - hand off to `lead-intelligence` when the real ask is target ranking or warm-path discovery ### 4. Report with explicit evidence boundaries For important claims, say whether they are: - sourced facts - user-supplied context - inference - recommendation Freshness-sensitive answers should include concrete dates. ### 5. Decide whether the task should stay manual If the user is likely to ask the same research question repeatedly, say so explicitly and recommend a monitoring or workflow layer instead of repeating the same manual search forever. ## Output Format ```text QUESTION TYPE - factual / comparison / enrichment / monitoring EVIDENCE - sourced facts - user-provided context INFERENCE - what follows from the evidence RECOMMENDATION - answer or next move - whether this should become a monitor ``` ## Pitfalls - do not mix inference into sourced facts without labeling it - do not ignore user-provided evidence - do not use a heavy research lane for a question local repo context can answer - do not give freshness-sensitive answers without dates ## Verification - important claims are labeled by evidence type - freshness-sensitive outputs include dates - the final recommendation matches the actual research mode used