$npx -y skills add owainlewis/blueprint --skill designDesigns what to build and how it should work, including requirements, acceptance criteria, interfaces, data, errors, technical choices, constraints, risks, and scope. Use when the user asks to design or architect a feature, write a spec or design doc, define requirements, or reso
| 1 | # Design |
| 2 | |
| 3 | ## Workflow |
| 4 | |
| 5 | 1. Read the request, repository instructions, relevant code, and linked material. |
| 6 | 2. Resolve choices that would change behavior, interfaces, data, errors, security, operations, or tests. Ask only questions whose answers materially change the design. Recommend an answer when asking. |
| 7 | 3. Write `docs/<feature-slug>/design.md` using the shape below. Keep it short and omit sections that do not apply. |
| 8 | 4. Stop for human review. Do not plan or implement. |
| 9 | |
| 10 | ```markdown |
| 11 | # <Title> |
| 12 | |
| 13 | ## What and why |
| 14 | The problem, desired outcome, and users affected. |
| 15 | |
| 16 | ## Requirements |
| 17 | - Observable behavior and constraints. |
| 18 | |
| 19 | ## Acceptance criteria |
| 20 | - Testable conditions that prove the work is complete. |
| 21 | |
| 22 | ## Design |
| 23 | The chosen approach, important components, data flow, and technical choices. |
| 24 | |
| 25 | ## Interfaces and data |
| 26 | APIs, commands, events, schemas, compatibility, or migration requirements. |
| 27 | |
| 28 | ## Failure behavior |
| 29 | Invalid input, partial failure, recovery, and operational limits. |
| 30 | |
| 31 | ## Test approach |
| 32 | How each important requirement will be proved. |
| 33 | |
| 34 | ## Risks |
| 35 | - Risk and mitigation. |
| 36 | |
| 37 | ## Out of scope |
| 38 | - Related work this design does not include. |
| 39 | ``` |
| 40 | |
| 41 | ## Boundaries |
| 42 | |
| 43 | - Prefer one clear recommendation over a catalogue of options. |
| 44 | - Record rejected options only when the tradeoff matters later. |