A repeatable structure for every design doc
Engineering teams move faster when every technical spec looks the same. A reviewer should always know where to find the problem statement, the API design, and the risky edge cases. This builder produces a consistent Markdown document so your team spends its energy on the design itself, not on document formatting.
How it works
The builder maps each input to a named section and assembles them in the canonical order used by most engineering design docs: Problem Statement, Proposed Solution, System Components, API Design, Data Model, Edge Cases, and Open Questions. Multi-line inputs such as components, edge cases, and open questions are rendered as bulleted lists so they stay scannable, while prose fields like the problem statement remain paragraphs. Empty sections are dropped entirely, so the output scales naturally with the size of the change.
The result is plain Markdown with ## headings, which pastes cleanly into GitHub, Notion, Confluence, or any wiki without reformatting.
Tips and example
- Write the problem statement before the solution. If you cannot state the problem in three sentences, the design is not ready.
- Enter components, edge cases, and open questions one per line so they render as bullet points.
- Be specific in the edge-cases section: empty inputs, concurrency, partial failures, and large payloads are the cases that break systems in production.
- Keep open questions honest. A spec with no open questions for a non-trivial change usually means the hard parts have not been examined yet.