What problem does it solve? Teams often jump straight from a request like "build me a dashboard" into writing specs, without validating the underlying problem. This Skill turns a raw request into a structured discovery document covering the real problem, the affected user, a falsifiable hypothesis, a measurable success metric, scope, explicit exclusions, and risks—before any spec is written. ## Core Features & Use Cases - Problem reframing: Recovers the actual user pain hidden behind a solution-shaped request, asking one targeted question when the problem is ambiguous. - Structured discovery document: Produces problem, primary user, falsifiable hypothesis, success metric with baseline, scope, explicit exclusions, and technical/user/business risks. - Reuse check and human decision boundary: Prompts checking whether an existing solution covers 80% of the need, then stops so prioritization remains a human decision. - Use Case: A stakeholder asks for a new reporting dashboard. Run /discover to surface that the real problem is slow weekly reporting, define a hypothesis and a baseline metric, and hand an approved discovery to /spec. ## Quick Start Invoke /discover with a feature request such as "we need a notifications center" to get a structured discovery document with problem, hypothesis, metric, scope, and risks.
