requirements-engineering
Requirements Engineering
Transform user needs and business goals into precise, testable requirements.
Context
Requirements engineering bridges discovery and design. It takes the "what users need" from discovery and turns it into "what the system must do" for architecture. Poor requirements are the #1 cause of project failure -- not because requirements are missing, but because they're ambiguous, contradictory, or incomplete.
This skill may start from more than one upstream shape:
- a discovery evidence set such as market research, personas, and feasibility findings
- a routed entry-stack handoff such as
problem-frameanddesign-direction - an
intake-briefthat records constraints, open questions, and the intended next step
Do not force every route through the same upstream artifact bundle. Start from the approved upstream direction that actually exists, then preserve its constraints faithfully.
Inputs
- design-direction -- Preferred directional input when problem-framing has already compared options and selected a path. Treat this as the strongest signal for what release or iteration direction should be converted into requirements.
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6