requirements-spec

To generate a SPEC.md with acceptance criteria and use cases, you provide a confirmed PROJECT.md to the requirements-spec process, which converts it into a structured contract defining 3–10 use cases, feature acceptance criteria, non-functional requirements, and external dependencies.

The best way to structure non-functional requirements and external dependencies before architecture design is to consolidate them into a single SPEC.md artifact, ensuring they are directly traceable to the success metrics defined in your PROJECT.md.

To ensure traceability between project success metrics and feature acceptance criteria, you enforce a documented artifact contract where every use case and non-functional requirement in the SPEC.md aligns with the Target Audience and Success Metrics established in the PROJECT.md.

Yes, you need a confirmed PROJECT.md before planning architecture and defining software specifications, because the requirements-spec process enforces this prerequisite to align use cases and non-functional requirements with your project's foundational goals.

Yes, you can use a provided SPEC.md.template and reference guidance to standardize use cases and NFRs across multiple teams, which enforces a uniform artifact contract before design and enables reliable handoffs to architecture planning.

When architecture planning begins and you need to define 3 to 10 use cases for development, you run requirements-spec against your confirmed PROJECT.md to produce a structured SPEC.md that covers use cases, acceptance criteria, NFRs, and dependencies.