Technical Spec

This enforces actual discipline in technical writing by requiring alternatives, diagrams, and measurable success criteria for every design doc. It won't let you skip the hard parts like risk assessment or let you write "we'll use PostgreSQL" without explaining why you rejected MongoDB. Covers the full spectrum from quick ADRs to full RFCs with C4 diagrams, all with opinionated templates that push you toward living documents instead of write-once artifacts. The hard rules about including at least two alternatives and defining concrete metrics (not "make it faster" but "reduce P95 from 500ms to 200ms") are the real value here. Best for teams that keep making design decisions in Slack threads and wondering six months later why they chose what they chose.