Discovery

When to use

• User proposes a feature or product idea and no workspace or plan exists
• User asks whether something is worth building, or to challenge a feature
• User asks what already exists: competitors, alternatives, build versus buy
• User asks for an opportunity brief, a PR-FAQ, or a market scan

Overview

Discovery decides whether and what to build. Planning decides how. The job is killing risk before engineering commits, so a day spent deciding not to build is a win, never a failure. The output is a one-page opportunity brief ending in a verdict: build, buy, test first, or drop. On build, the plan skill takes over.

Reference: market-scan.md. Read it at workflow step 3.

Workflow

1. Reframe as an outcome. Rewrite the request as the user or business outcome it serves, measurable in one sentence. A feature with no stated outcome is the first red flag: ask one question, or in a delegated context derive the outcome from the brief and record it as an assumption.
2. Challenge the four big risks (Cagan, Inspired): value (will anyone use it), usability (can they figure it out), feasibility (can we build it in the time we have), viability (does it work for the business: cost, legal, support). One sentence per risk, each marked low, open, or blocking, with its evidence.
3. Scan the market. Browse what already solves the job: competitors, adjacent products, open source, internal tools, and doing nothing. Search the job in the end user's words before any solution-shaped query, or adjacent players stay invisible. Compare by how well each completes the user's job, never by feature checklist. Query shapes, table format, and sources live in market-scan.md.
4. Map opportunities before solutions (Torres, opportunity solution tree). One outcome per tree: outcome, then unmet needs, then candidate solutions, then assumption tests. Hold at least three candidates before choosing, and "integrate an existing product" from step 3 is always one of them.
5. Test the riskiest assumption cheaply. Name the single assumption that kills the idea fastest. Name the cheapest test: a query over existing data, a prototype, five user conversations. Never a build.
6. Write the brief to docs/discovery/<name>.md and stop for the verdict. In a delegated context, decide, record the reason, and continue.

The opportunity brief

One page. Every claim cites a source: a user quote, a metric, a ticket, or a URL.

Section	Holds
Outcome	The measurable user or business outcome, one sentence
Evidence	Demand signals, each with its source
Market	Full player list (rejected ones included), scan verdict, and the comparison table from step 3
Risks	The four risks, each low, open, or blocking, with why
Verdict	Build, buy, test first, or drop, with the reason
Kill criteria	The evidence that would reverse the verdict

Not: "Competitor X has dashboards, we need dashboards." Yes: "Users export to Excel weekly to answer one question (tickets #312, #340); X answers it in-product."

Boundaries

This skill decides whether and what, never how. On a build verdict it hands the brief to the plan triage; tasks, ADRs, and code start there. Weighing conflicting reviews or field reports belongs to bias-analysis. Claims about the existing codebase follow evidence-based-analysis.