| name | Requirements Discovery |
| description | SYSTEMATICALLY UNCOVER hidden constraints, define success metrics, and prevent scope creep before writing code. Intercept vague prompts and run the five discovery questions. Do NOT write code until requirements are documented. Trigger: user says "build me", "can we add", "design a system for", or any high-level project/feature request.
|
| category | foundation |
| version | 3.0.0 |
| last_updated | 2026-06-28T00:00:00.000Z |
| stacks | ["All"] |
| triggers | [{"pattern":"build (a|me|an|the)","action":"INTERCEPT, run discovery before code"},{"pattern":"can we add (a|an|a new)","action":"INTERCEPT, run discovery before code"},{"pattern":"(design|architect|create) (a|the|an) (system|app|platform)","action":"INTERCEPT, run discovery before code"},{"pattern":"visitor asks for vague feature","action":"INTERCEPT, run discovery before code"}] |
| related_skills | ["professional-project-intake","database-schema-design","saas-app-structure"] |
Requirements Discovery Framework
IDENTIFY: When to Activate
Activate this skill when ALL of:
- User submits a high-level, vague, or incomplete prompt
- Prompt describes a new application, system, or complex feature
- No detailed specification exists in the conversation
Do NOT activate when:
- Request is a bug fix (use error handling skills)
- Request is a specific UI tweak (use component skills)
- User already provided detailed acceptance criteria
DECIDE: Response Selection
IF user prompt is vague AND describes new project/feature →
RUN five discovery questions (EXECUTE Step 1)
UNTIL happy path, audience, data, scale, failure modes are answered
THEN write architecture plan (EXECUTE Step 2)
THEN proceed to implementation
IF user prompt is vague AND describes existing system change →
SCAN existing code first (professional-project-intake)
THEN run only Steps 1-2 of discovery questions
THEN write change plan
THEN proceed
IF user prompt is detailed AND specific →
SKIP this skill
Proceed directly to implementation skills
EXECUTE: Instructions
Step 1: Answer the Five Discovery Questions
Answer every question you can from existing context. For remaining unknowns, ask the user, max 3 questions per batch.
Q1, HAPPY PATH: Define the single most important user action in one sentence.
Template: "A(n) [ACTOR] can [ACTION] resulting in [OUTCOME]."
Example: "An admin can view a list of orders and filter by status."
If you CANNOT state the happy path in one sentence → STOP. Ask user to clarify scope before proceeding.
Q2, AUDIENCE: Identify who uses this.
IF internal team (3-50 people) → Simple UI, performance less critical, no polish needed
IF public consumers (thousands+) → Polish, accessibility, responsive design, performance required
IF developers (API consumers) → Docs, versioning, rate limiting, consistent error formats
IF both internal AND external → Different UIs per role (see saas-app-structure/SKILL.md)
Q3, DATA: Map data flow.
INPUTS: [ ] User input [ ] File uploads [ ] API payloads [ ] Webhooks
STORAGE: [ ] User accounts [ ] Orders [ ] Content [ ] Analytics [ ] Audit logs
OUTPUTS: [ ] API responses [ ] Emails [ ] Exports [ ] Reports [ ] Real-time events
COMPLIANCE: [ ] PII [ ] GDPR [ ] HIPAA [ ] PCI-DSS [ ] SOC2
Q4, SCALE: Determine architecture complexity.
USERS 1-10 → SQLite, single server, no caching → PROTOTYPE
USERS 10-1K → PostgreSQL, basic auth, simple deployment → SMALL PRODUCTION
USERS 1K-100K → Caching, background jobs, CDN → MEDIUM
USERS 100K+ → Load balancing, sharding, message queues → LARGE
