— 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. 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