discover-requirementslisted

# Discover Requirements Use this skill after an idea has been shaped enough that the problem, target users, desired outcome, and broad MVP are understood, but the expected behavior is not yet precise enough to design or implement safely. Normally consume the output of `refine-idea`. If the input is still a raw or contradictory idea, use `refine-idea` first rather than inventing requirements for an unstable premise. ## Goal Produce a **Requirements Discovery Brief** that is complete enough for design/architecture work and later `idea-to-delivery` / `backlog-refinement` without forcing implementation agents to make product decisions. Requirements describe **what must be true and how the capability behaves**. Avoid prematurely prescribing code structure, libraries, database schemas, or deployment details unless an existing architecture constraint makes them mandatory. ## Discovery method Be conversational and risk-driven. Resolve the most consequential ambiguity first rather than asking every possible question. Use available conversation, repository, Architecture Doc, existing GitHub issues, and current system behavior before asking the user for information that can be discovered directly. Typical discovery order: 1. Confirm actors and scope. 2. Walk the primary happy-path scenario end to end. 3. Identify alternate paths and failure states. 4. Extract business rules and decision logic. 5. Define permissions, tenant boundaries, and visibility. 6. Define data captured, r