Partner-level requirements discovery and clarification. This skill routes to the requirements-consultant agent for structured analysis.
When to Use
- Requirements are vague or one-liner descriptions
- Starting a new feature, epic, or project
- Unclear scope, hidden assumptions, or missing acceptance criteria
- Need to break an epic into implementable user stories
- Feasibility analysis required (build vs. buy vs. partner)
- Stakeholder needs conflict or are undefined
Discovery Protocol
The agent follows a structured six-phase protocol:
Phase 1: Why — Business Objective
- What business outcome does this serve?
- How will success be measured?
- Who are the stakeholders and their priorities?
Phase 2: What — Feature Scope
- User personas and their goals
- Core use cases (must-have) vs. enhancements (nice-to-have)
- System boundaries — what is IN scope and OUT of scope
Phase 3: Hidden Requirements
- Edge cases and error states
- Accessibility and i18n considerations
- Performance and scalability expectations
- Security and compliance requirements
- Data migration or backward compatibility needs
Phase 4: Assumptions
- Technology constraints within the stack (Rails, React Native, Vite SPA, Next.js)
- Third-party dependencies and API availability
- Data availability and quality assumptions
- Timeline and resource assumptions
Phase 5: Architecture Proposal
- Tech stack alignment and component selection
- Service boundaries and data flow
- Integration points with existing systems
- Spike stories for unknowns
Phase 6: Delivery Plan
- Phased user stories: MVP → Enhancements → Polish
- Complexity ratings (S/M/L/XL) per story
- Risk and dependency map
- Sprint-ready acceptance criteria
Output Artifacts
- User Stories —
As a [persona], I want [action] so that [benefit] - Acceptance Criteria — Given/When/Then format per story
- Complexity Ratings — S (1-2 pts), M (3-5 pts), L (8 pts), XL (13+ pts, consider splitting)
- Risk Register — Risk, likelihood, impact, mitigation
- Spike Stories — Timeboxed research tasks for unknowns
- Dependency Map — Blocking and blocked-by relationships
Quality Checklist
- Every user story has acceptance criteria
- No story exceeds 13 points — split XL stories
- Spike stories identified for all technical unknowns
- Edge cases explicitly addressed (not deferred)
- Non-functional requirements captured (performance, security, a11y, i18n)
- Dependencies between stories mapped
- MVP scope is clearly separated from enhancements
Keywords
requirements, user stories, acceptance criteria, scope, feasibility, epic breakdown, PRD, BRD, stakeholder, discovery, spike, estimation, MVP