solution-design
Solution Design
Write a design specification with contracts before components, explicit behavior flows, ADRs for every open decision, and a bidirectional traceability map. Style is ASD-STE100 Simplified Technical English. This skill is the third stage of the SDLC document pipeline: discovery → requirements-definition → solution-design. It consumes the PRD and produces the spec that a future test-definition stage consumes.
Like the upstream skills, this skill makes no code changes and no commits. It reads code only to describe constraints that the design must obey (existing interfaces, formats, tools). The design spec describes the system to build. It does not build the system.
Input contract: the PRD
The primary input is a PRD (the output of the requirements-definition skill). Resolve the input before you write anything:
1. A PRD exists (attached, referenced, or present in the conversation). Read it fully, then collect four things:
- All FR and NFR IDs. These become the Scope list (Section 1) and the left column of the Traceability table (Section 9). Every ID must appear in both.
- All Open Questions. Each one becomes an ADR (Section 8). An Open Question with no ADR blocks the spec.
- Appendix A (rejected options), if present. ADRs cite "PRD Appendix A, option (x)" instead of a new debate on a dead branch. If a rejected option becomes relevant again, say so explicitly in the ADR and give the new fact that changed the picture. Do not resurrect a rejected option in silence.
- The acceptance criteria. The Test column of Section 9 must be compatible with them: a design that cannot pass the PRD's ACs is wrong, not the ACs.
Then validate: if the PRD has FRs marked with hunch provenance, list them in Section 1 as design risks. The design must not make a hunch load-bearing without a note.