fidara-designlisted

The Fidara design system — how to build consistent, modern, responsive UI in Rails 8 + Hotwire + Tailwind CSS v4, brand-parameterised via brand packs. Load this WHENEVER building or reviewing UI: components (buttons, cards, forms, nav, modals, tables, badges, alerts), page layouts, tokens/theming, dark mode, responsiveness, or brand/logo usage. It defines the token architecture (brand primitives → semantic roles → fluid scale), the layout primitives you compose instead of ad-hoc flex/grid, the component catalog with variant/size/state, the Stimulus interaction patterns, and the responsive doctrine. Consistency is enforced here, not left to taste — and **art direction** is taught rather than left undefined: visual hierarchy, per-surface aesthetic intent, and the difference between a surface that is correct and one that is considered.
fmanimashaun/claude-skills · ★ 0 · Web & Frontend · score 72

Install: claude install-skill fmanimashaun/claude-skills

# Fidara Design System Build every UI by **composing tokens, layout primitives, and catalog components** — never ad-hoc CSS. This system makes UI consistent across projects without a designer or Figma. It is **prescriptive**: where it gives a token, a recipe, or a variant set, use exactly that. Inconsistency in components degrades the whole product, so drift is a defect. **Stack:** Rails 8 · Hotwire (Turbo + Stimulus) · **Tailwind CSS v4** (CSS-first `@theme`, no `tailwind.config.js`, no npm) · Lucide icons. Brand packs (**fidara** is the first; `fmworkflows` is a *variant* inside it, not a second pack) are ONE system — identical values, only the token prefix differs; code uses the **`fm-*`** prefix. See [references/brand.md](references/brand.md). > **Tailwind here is a deliberate choice, not a claim that hand-written CSS is inferior.** > Canonical Rails apps — including 37signals' own ([campfire](https://github.com/basecamp/once-campfire), > writebook, fizzy) — hand-write vanilla CSS, and do it well. We standardize on Tailwind v4 > because this system's guarantee is **mechanically enforceable consistency**: `@theme` role > tokens, `@utility` primitives, and utility class names are greppable, so `/design-flow:audit` > and the `design-auditor` can *verify* conformance and catch drift. That check doesn't exist > for bespoke stylesheets. If a project has an established vanilla-CSS system, record it as a > Project Override rather than converting it on this skill's authority.