phoenix-design
Design system conventions for the Phoenix frontend — layout, dialogs, error display, BEM CSS class naming, and CSS design tokens. Use when building UI, naming CSS classes, creating or consuming tokens, handling errors, or designing dialog interactions in js/app/src/.
68
83%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Phoenix Design System
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
What Are You Doing?
Read the relevant reference(s) based on the task:
| Task | Reference |
|---|---|
| Layout stability, scroll behavior, interaction patterns | references/layout.md |
| Alert and form dialog usage, footer button styling, content writing | references/dialogs.md |
| Error scoping, inline alerts, input validation | references/error-display.md |
| Naming CSS classes | references/bem.md |
| Creating or consuming CSS design tokens | references/tokens.md |
| Picking an icon for a noun (project, trace, span, file, etc.) | references/icons.md |
| Displaying counts in tabs, headings, or filter buttons | references/counters.md |
Choosing or adding an EmptyStateGraphic variant (the per-region/topic empty-state graphics) | references/empty-states.md |
- Repository
- Arize-ai/phoenix
- Commit
e127482
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.