SKILL.md
Design Engineering
Design engineering is shared responsibility for the interface in production, not a relay race between finished mockups and ticketed implementation.
Defaults
- Prefer handshakes over handovers: involve implementation constraints early.
- Map design structure to code structure deliberately.
- Prototype to learn; ship with production rigor.
- Keep taste attached to materials knowledge (CSS, framework rendering, tokens, a11y).
- Optimise for reduced translation loss between intent and implementation.
Translation map
| Design concept | Code concept |
|---|---|
| Frame / auto layout | Stack, flex, grid |
| Component + variants | Component API + props/state |
| Local styles | Tokens + semantic classes |
| Prototype interactions | Real state, routes, and motion |
| Redlines | Defaults encoded in the component |
Prefer / Reject
| Prefer | Reject |
|---|---|
| Shared ownership of quality | "Design is done" / "Dev will polish" |
| Constraints in the exploration phase | Surprising feasibility after visual lock |
| Production concerns during prototyping | Treating vibe demos as launch-ready |
| Tokenised systems | One-off values that cannot survive themes |
Review checklist
- Did engineering constraints inform the design direction early?
- Does the component API match the variant model people design with?
- Are tokens used instead of disconnected raw values?
- Are accessibility and empty/error states designed, not deferred?
- Is the prototype honest about what still needs production work?
- Can design and engineering point to the same source of truth for behaviour?
Source essays
- Design for handshakes, not handovers
- A manifesto on design engineering
- Thinking in design code
- The design engineer