What problem does it solve? Writing a software requirements specification that stays synchronized with executable acceptance criteria is error-prone: requirements drift from test scenarios, non-functional requirements lack measurable targets, and traceability between requirements and tests breaks down. This Skill produces the SRS and its Gherkin feature files together, gated as one unit, so the prose specification and the executable half never diverge. ## Core Features & Use Cases - Dual-artifact generation: Produces SRS.md (functional FR, non-functional NFR, and AI AIR requirements with data and interface contracts) plus one .feature file per use case, linked through a §8 index. - Input gating: Validates the source PRD before writing — blocking on missing use cases, acceptance bullets, or unanswered blocking questions, and routing gaps back to the PO/BA owner. - Traceability enforcement: Every scenario carries @feat/@uc/@req/@oracle tags, and every requirement must be referenced by at least one scenario, checked by gate G2. - Use Case: A Tech Lead runs /srs FEAT-042 against an approved PRD and receives a complete SRS with measurable NFRs, AI quality metrics, and per-use-case Gherkin feature files ready for test generation. ## Quick Start Run /srs with a feature ID, for example: generate the SRS and acceptance criteria for FEAT-042 from its PRD.
