> rails-design-system
Ruby on Rails design system guidelines for building consistent, maintainable UI with minimal abstraction. This skill should be used when creating or refactoring Rails views, partials, components, form builders, helpers, Stimulus controllers, Turbo Frames, Turbo Streams, or design tokens. Triggers on tasks involving ERB partials, Turbo navigation, Turbo Streams, ViewComponent, Phlex, Tailwind design tokens, custom form builders, view helpers, Stimulus behaviors, Import Maps, Lookbook previews, or
curl "https://skillshub.wtf/pproenca/dot-skills/rails-design-system?format=md"Community Ruby on Rails Design System Best Practices
Comprehensive design system guide for Ruby on Rails applications, maintained by Community. Contains 51 rules across 9 categories, prioritized by impact to guide automated refactoring and code generation. Covers the full Rails frontend stack: Turbo (Drive, Frames, Streams), Stimulus, ERB partials, design tokens, form builders, and view helpers. Complements rails-dev (controllers, models, queries) and tailwind (CSS patterns) by covering the systematic UI component architecture layer.
When to Apply
Reference these guidelines when:
- Deciding whether to extract a partial, component, or helper
- Defining design tokens with Tailwind CSS
@theme - Creating or refactoring ERB partials with explicit locals
- Decomposing pages into Turbo Frames for targeted updates
- Using Turbo Streams for multi-element CRUD updates
- Coordinating Turbo navigation with Stimulus controllers
- Building ViewComponent or Phlex components for complex UI
- Implementing a custom FormBuilder for consistent forms
- Writing view helpers for badges, icons, and conditional classes
- Adding Stimulus controllers for interactive behaviors
- Managing JavaScript dependencies with Import Maps
- Auditing the codebase for UI duplication and naming drift
Rule Categories by Priority
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | Design Decisions | CRITICAL | decide- |
| 2 | Design Tokens | CRITICAL | token- |
| 3 | Turbo Integration | HIGH | turbo- |
| 4 | Partial Patterns | HIGH | partial- |
| 5 | Component Architecture | HIGH | comp- |
| 6 | Form System | MEDIUM-HIGH | form- |
| 7 | Helper Patterns | MEDIUM | helper- |
| 8 | Stimulus Behaviors | MEDIUM | stim- |
| 9 | Consistency & Organization | LOW-MEDIUM | org- |
Quick Reference
1. Design Decisions (CRITICAL)
decide-three-uses-rule- Extract only after a pattern appears in 3+ placesdecide-partial-vs-component- Choose partials for simple reuse, components for complex logicdecide-helper-vs-partial- Use helpers for tiny HTML fragments, partials for layout blocksdecide-prove-then-extract- Prove patterns in production before abstractingdecide-avoid-wrapper-components- Avoid thin wrappers that add indirection without valuedecide-design-system-scope- Scope the design system to what the app actually needs
2. Design Tokens (CRITICAL)
token-tailwind-theme- Define tokens with Tailwind CSS @theme directivetoken-semantic-color-names- Name colors by purpose, not appearancetoken-spacing-scale- Use a constrained spacing scale for consistent layouttoken-typography-scale- Define a typography scale for headings, body, and UI texttoken-component-tokens- Create component-level tokens for repeated patternstoken-share-tokens-with-ruby- Share token values between CSS and Ruby when needed
3. Turbo Integration (HIGH)
turbo-drive-defaults- Let Turbo Drive handle navigation by defaultturbo-frame-decompose- Decompose pages into Turbo Frames for targeted updatesturbo-frame-naming- Name Turbo Frames with dom_id conventionsturbo-frame-vs-stream- Choose Turbo Frames vs Turbo Streams by scope of changeturbo-stream-crud- Use Turbo Streams for multi-element page updatesturbo-stimulus-coordination- Coordinate Turbo and Stimulus without conflicts
4. Partial Patterns (HIGH)
partial-explicit-locals- Always pass locals explicitly to partialspartial-presenter-objects- Use presenter objects to encapsulate view logicpartial-naming-conventions- Name partials by what they render, prefixed with underscorepartial-yield-blocks- Use yield blocks for flexible partial layoutspartial-collection-with-spacer- Use collection rendering with spacer templatespartial-shared-directory- Place cross-controller partials in app/views/shared
5. Component Architecture (HIGH)
comp-when-to-use- Use components when partials outgrow simple renderingcomp-explicit-args- Define explicit typed arguments for every componentcomp-slots-for-markup- Use slots for caller-provided markup blockscomp-test-rendered-output- Test components by asserting on rendered HTML
6. Form System (MEDIUM-HIGH)
form-custom-builder- Create a custom FormBuilder for consistent form renderingform-set-default-builder- Set the custom builder as the application defaultform-error-display- Display field errors inline with consistent markupform-accessible-labels- Generate accessible labels and ARIA attributes automaticallyform-group-wrapper- Wrap label + input + error in a consistent group elementform-button-consistency- Standardize submit buttons through the form builder
7. Helper Patterns (MEDIUM)
helper-tag-helpers- Use tag helpers for small generated HTML fragmentshelper-conditional-classes- Use class_names for conditional CSS classeshelper-icon-helper- Create an icon helper for consistent icon renderinghelper-badge-pattern- Build a badge helper for status indicatorshelper-scope-to-domain- Scope helpers to specific domains, not generic utilities
8. Stimulus Behaviors (MEDIUM)
stim-general-purpose- Write general-purpose controllers, not one-off scriptsstim-data-attribute-config- Configure behavior through data attributes, not JavaScriptstim-small-controllers- Keep controllers small and single-responsibilitystim-composable-controllers- Compose multiple controllers on one elementstim-use-outlets- Use outlets for cross-controller communicationstim-leverage-library- Use stimulus-components before writing custom controllers
9. Consistency & Organization (LOW-MEDIUM)
org-naming-conventions- Follow consistent naming across partials, components, and helpersorg-file-structure- Organize design system files in predictable locationsorg-deduplication-audit- Periodically audit views for duplicated patternsorg-import-maps- Use Import Maps for zero-build JavaScript deliveryorg-preview-with-lookbook- Preview components with Lookbook in developmentorg-document-design-decisions- Document design system decisions in ADRs
How to Use
Read individual reference files for detailed explanations and code examples:
- Section definitions - Category structure and impact levels
- Rule template - Template for adding new rules
Reference Files
| File | Description |
|---|---|
| references/_sections.md | Category definitions and ordering |
| assets/templates/_template.md | Template for new rules |
| metadata.json | Version and reference information |
> related_skills --same-repo
> valid-skill
A valid test skill with proper formatting. This skill should pass all validations and serves as a reference for the expected format.
> too-long-skill
This skill has more than 500 lines which should fail validation.
> missing-references
This skill references rules that do not have corresponding files in the references directory.
> missing-description
missing-description skill from pproenca/dot-skills