Requirements Analysis
Diagnose vague product intent and surface real problems, constraints, and validated needs before you commit to a build.
Overview
Requirements Analysis is a journey-wide agent skill that diagnoses requirements problems and guides discovery of real needs and constraints—usable whenever a solo builder needs to separate stated wants from underlying pr
Install
npx skills add https://github.com/jwynia/agent-skills --skill requirements-analysisWhat is this skill?
- State-based diagnostic flow (e.g. RA0 no problem statement) with symptoms, key questions, and interventions
- Treats requirements as hypotheses to validate against the actual problem, not a documentation dump
- Jobs-to-be-Done self-interview and problem archaeology to trace ideas back to specific frustration
- Guides discovery of real constraints and pushes back on premature solution thinking
- Assistive diagnostic mode aimed at solo developers on agile-style software projects
- State RA0 diagnostic track for no problem statement
- MIT-licensed requirements-analysis skill metadata version 1.0
Adoption & trust: 2.1k installs on skills.sh; 92 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a feature list or "I want to build X" idea but cannot tie it to who has what problem, real constraints, or evidence the solution fits.
Who is it for?
Solo founders and indie builders in early product conversations with themselves or a thin spec who need disciplined needs discovery before code.
Skip if: Teams that already have an approved problem statement, signed scope, and traceable acceptance criteria—skip to implementation planning instead.
When should I use this skill?
Diagnose requirements problems and guide discovery when intent is vague, solution-first, or not tied to a clear user problem and constraints.
What do I get? / Deliverables
You leave with a clearer problem statement, sharper discovery questions, and requirements framed as testable hypotheses ready for scoping or planning—not a premature implementation spec.
- Sharper problem statement and discovery questions
- Requirements reframed as testable hypotheses
- Identified constraints and anti–premature-solution guardrails
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
You copied a competitor’s feature set—use RA0-style questions to name who suffers without your twist and what frustration triggered the idea.
Interview yourself with Jobs-to-be-Done phrasing before spending a week on competitive spreadsheets alone.
Trim a bloated MVP list by checking each requirement against an articulated problem and constraints.
An agent-generated backlog lacks problem grounding—re-run discovery states before accepting tasks.
Feature requests pile up—separate stated wants from underlying operational pain before the next sprint.
How it compares
Use instead of dumping features into a PRD without validating that each requirement solves a real problem.
Common Questions / FAQ
Who is requirements-analysis for?
Solo and indie software builders who tend to start from solutions and want a structured way to discover problems, constraints, and validated needs before building.
When should I use requirements-analysis?
Use it in Idea when intent is vague or competitor-driven; in Validate when scoping a prototype or landing page; and in Build when a spec still cannot name the user problem—anytime requirements feel like guesses rather than tested hypotheses.
Is requirements-analysis safe to install?
It is assistive diagnostic guidance with no mandated shell or network access in the skill itself; review the Security Audits panel on this Prism page before installing any skill from the catalog.
SKILL.md
READMESKILL.md - Requirements Analysis
# Requirements Analysis: From Vague Intent to Validated Needs You diagnose requirements-level problems in software projects. Your role is to help solo developers distinguish stated wants from underlying problems, discover real constraints, and avoid premature solution thinking. ## Core Principle **Requirements are hypotheses about what will solve a problem. The goal is not to document requirements but to discover whether they address the actual problem.** ## The States ### State RA0: No Problem Statement **Symptoms:** - Starting with "I want to build X" (solution, not problem) - Can't articulate who has what problem - "Everyone needs this" reasoning - Feature list without problem grounding - Copying existing solutions without understanding why they exist **Key Questions:** - What happens if this doesn't exist? Who suffers? - What are people (or you) doing today instead? - What triggered you thinking about this now? - If you're the user, what specific frustration led here? **Interventions:** - Jobs-to-be-Done self-interview: "When I [situation], I want to [motivation], so I can [outcome]" - Problem archaeology: trace the origin of the idea back to a specific frustration - "Five users" test: name 5 specific people who would benefit (even if one is yourself) - Use Problem Statement Brief template --- ### State RA1: Solution-First Thinking **Symptoms:** - Requirements describe implementation ("needs a database", "should use React") - Can't explain requirements without referencing technology - Answering "what" with "how" - Feature envy (copying existing solutions) - Technology choice before problem clarity **Key Questions:** - If that technology didn't exist, what would you need? - What outcome does this feature produce? - Are you solving YOUR problem or copying someone else's solution? - What's the need behind the feature? **Interventions:** - Function extraction: rewrite each requirement starting with "The system must [verb]..." without technology words - "Remove the solution" exercise: describe the need without ANY implementation - Constraint vs. preference distinction: is this technology required, or just familiar? - Check if you're building what you know vs. what you need --- ### State RA2: Vague Needs **Symptoms:** - "Users should be able to..." without specifics - Requirements that can't be tested - Adjective requirements: "fast", "easy", "intuitive", "modern" - No acceptance criteria imaginable - Can't describe what "done" looks like **Key Questions:** - How would you know if this requirement is met? - What's the minimum that would satisfy this need? - What would a disappointing implementation look like vs. a great one? - Can you give a specific example scenario? **Interventions:** - Specificity ladder: who specifically? doing what specifically? when specifically? - Acceptance scenario writing: "Given X, when Y, then Z" - "Done looks like..." exercise: describe the smallest thing that would satisfy - Testability check: if you can't test it, you don't understand it yet - Use Need Hierarchy template --- ### State RA3: Hidden Constraints **Symptoms:** - Discovering blockers mid-implementation - "Oh, I forgot to mention..." - Assumptions treated as facts - No explicit constraint inventory - Surprise dependencies appearing late **Key Questions:** - What's definitely true about this context? (Real constraints) - What are you assuming is true? (Assumptions to validate) - What would kill this project if it turned out to be true? - What resources/skills/time do you actually have? - What external dependencies exist? **Interventions:** - Constraint inventory: list budget, time, skills, dependencies, integrations - Assumption mapping: validated vs.