Contributing

Proposing a change

1. 1
   Open a discussion

   Propose the change and the reasoning behind it before any work starts.
2. 2
   Get it approved

   One other designer or engineer signs off on the approach before anything gets built.
3. 3
   Design in Figma, when it earns it

   For a new component or a real visual change. Most changes go straight to code — see the naming convention below for when Figma applies.
4. 4
   Build against the checklist

   Every item below, not just the obvious ones.
5. 5
   Open a PR

   Title as feat(component): ... or fix(component): ..., linked to the Figma spec if there is one.
6. 6
   Update the changelog

   Add an entry before merging, not after.

Component checklist

Figma naming convention

Format: Module - Screen Name - State. Only add a product-name prefix when a screen is shared across multiple products' Figma files — within a single product's own file, the product name is redundant context. When a screen has both an empty and a populated version, both get designed and named with exactly - Empty / - Filled — not "Blank" or "Populated."

Changelog

When there are updates to the design system, they will reflect here.