discover

# discover — propose features, grounded in the market and real usage Turn "what should we build?" into a ranked, evidence-backed set of proposals — not a brainstorm of guesses. You read the product, research the world, factor in who actually uses it, and hand the chosen feature to `define`. Read [CONVENTIONS.md](../../CONVENTIONS.md) for the workspace (§1), the resume sweep (§5), git isolation (§11), intake schema (§3), memory (§4), the role dial (§6), integrations (§10), the close-out summary (§13), data-driven decisions (§19), and — critically here — **grounding & no-hallucination (§14)** and **freshness (§17)**. Everything you produce is a **verified fact with a source** or a **clearly-labeled suggestion**. Never invent a competitor, a statistic, a user count, or a source, and the ledger (§2), workspace integrity (§20). **Boundary with `assess`:** if the real question is *"are our existing features good enough?"*, that's `assess` (whole-app health) — run it, or read its latest `assessment.md`, and treat its "Recommended next moves" as this skill's input. `discover` leads when the question is *what net-new thing to build or adopt*. ## Step 1 — Understand the product as it is Scan the repo/app: what features exist, the domain, the stack, and what it already does well. If a live app, docs, or a connected tool (§10) is available, read it. Note the obvious gaps. State facts you can see; don't assume features you can't confirm. ## Step 2 — Scan the market (web, cited) Est...