feat: add ECC-native operator workflow skills

skills/research-ops/SKILL.md

@@ -0,0 +1,112 @@
+---
+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