requirements-definition
Requirements Definition
Write a PRD with a fixed section structure, strict traceability rules, and ASD-STE100 Simplified Technical English style. This skill is the second stage of the SDLC document pipeline: discovery → requirements-definition → solution-design. It consumes the exploration brief from discovery and produces the PRD that solution-design consumes.
Like discovery, this skill makes no code changes and no commits. It reads code only to make the Current Behavior section correct.
Input contract: the exploration brief
The primary input is an exploration brief (the output of the discovery skill). Resolve the input before you write anything:
1. A brief exists (attached, referenced, or present in the conversation). Read it fully, then validate it:
- Check the disposition. The disposition must be "proceed".
- Proceed: consume the brief through the handoff map below.
- Spike: tell the user that the brief asks for an experiment first. If the user continues, write the PRD, and put the untested assumption in Open Questions as an explicit risk.
- Park or dissolve: stop and ask. A PRD is opposite to the brief's own conclusion. The user must overrule the brief consciously. Record the overrule in the PRD header.
- Check the direction. A "proceed" disposition must name a chosen direction and a runner-up. If the direction is missing, ask one question to settle it. Do not guess.
2. No brief exists. Say that the PRD will be stronger after a discovery pass, and offer the discovery skill. If the user declines, or the conversation already contains the equivalent material (pains, options, a settled direction), extract that material into brief-shaped notes first. Then write the PRD from the notes. The PRD gets provenance in each case.