oornnery Design
Use skill when main question = how system presents to clients/users.
When to Load Each Reference
| Situation | Read |
|---|---|
| routes, contracts, errors, pagination | references/api.md |
| tokens, components, states, accessibility | references/ui.md |
| frontend-specific aggregation and reshaping | references/bff.md |
| both surface types matter | read dominant one first, then other |
Workflow
- decide whether problem is API-facing, UI-facing, or both
- define contract before impl details
- keep naming, states, failure behavior explicit
- add BFF only if frontend needs aggregation/reshaping
- prefer stable patterns over clever shortcuts
- update
DESIGN.mdwhen API, UI, BFF, or product/design decisions need to persist - keep surface consistent across related endpoints/components
Shared Rules
- design happy path + failure path together
- keep APIs/components predictable before flexible
- add complexity only when real use case demands
- durable design decisions belong in
DESIGN.md; short active notes belong in.spec/state.md