Requirements Analyzer
Goal
Check clarity, scope, feasibility, and risk before implementation.
Turn vague asks into testable requirements.
Rules
- Match depth to change size.
- Keep requirements specific and testable.
- Separate user need from solution.
- Mark assumptions.
- Identify out-of-scope items.
- Split work over
400 LOC.
- Prefer
50-200 LOC per PR.
Discovery
- Who is the user?
- What goal should be reached?
- Why now?
- What triggers the behavior?
- What happens before and after?
- What means success?
- What means failure?
- What is out of scope?
- What must not change?
- What assumptions exist?
- What needs product answer?
Flow
- Identify user, goal, and trigger.
- Define success and failure.
- List requirements as testable statements.
- Check edge cases.
- Check technical impact.
- Identify risks and unknowns.
- Split scope if needed.
Checks
- Edge cases: empty, null, boundary, invalid, concurrent, expected error.
- Tech impact: data source, transform, state, destination, patterns, new paths.
- Non-functional needs: accessibility, performance, security, reliability, i18n.
- Risks: technical, scope, schedule, quality.
- Scope creep: "while we're at it", "nice to have", blurry boundaries.
Output
## Who
- [user persona]
## What
- [change summary]
## Why
- [problem solved]
## Requirements
- Given [precondition], when [action], then [outcome].
## Definition Of Done
- [ ] [testable item]
## Risks
- [risk, likelihood, impact, mitigation]
1---2name: requirements-analyzer3description: Analyze feature requirements for clarity, scope, risk, assumptions, and testability before implementation. Use when specs are vague, acceptance criteria are missing, edge cases are unclear, or work needs splitting; avoid for writing full user stories or estimating effort only.4---56# Requirements Analyzer78## Goal910Check clarity, scope, feasibility, and risk before implementation.11Turn vague asks into testable requirements.1213## Rules1415- Match depth to change size.16- Keep requirements specific and testable.17- Separate user need from solution.18- Mark assumptions.19- Identify out-of-scope items.20- Split work over `400 LOC`.21- Prefer `50-200 LOC` per PR.2223## Discovery2425- Who is the user?26- What goal should be reached?27- Why now?28- What triggers the behavior?29- What happens before and after?30- What means success?31- What means failure?32- What is out of scope?33- What must not change?34- What assumptions exist?35- What needs product answer?3637## Flow38391. Identify user, goal, and trigger.402. Define success and failure.413. List requirements as testable statements.424. Check edge cases.435. Check technical impact.446. Identify risks and unknowns.457. Split scope if needed.4647## Checks4849- Edge cases: empty, null, boundary, invalid, concurrent, expected error.50- Tech impact: data source, transform, state, destination, patterns, new paths.51- Non-functional needs: accessibility, performance, security, reliability, i18n.52- Risks: technical, scope, schedule, quality.53- Scope creep: "while we're at it", "nice to have", blurry boundaries.5455## Output5657```md58## Who59- [user persona]6061## What62- [change summary]6364## Why65- [problem solved]6667## Requirements68- Given [precondition], when [action], then [outcome].6970## Definition Of Done71- [ ] [testable item]7273## Risks74- [risk, likelihood, impact, mitigation]75```
flpbalada