skills/canvas-styling-conventions/SKILL.md
Style Canvas components with Tailwind CSS 4 theme tokens and approved utility patterns. Use when (1) Creating a new component, (2) Adding colors or styling to components, (3) Working with Tailwind theme tokens, (4) Adding or updating design tokens in global.css, (5) Creating color/style props, (6) Any change where component props are added/removed/renamed/retyped and can affect rendered styles. Covers @theme variables, CVA variants, and cn() utility.
npx skillsauth add drupal-canvas/skills canvas-styling-conventionsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
| Technology | Purpose |
| ------------------------------------ | ------------------ |
| Tailwind CSS 4.1+ | Styling |
| class-variance-authority (CVA) | Component variants |
| clsx + tailwind-merge via cn() | Class name merging |
Only use these dependencies for styling. Do not add third-party CSS libraries or create new styling utilities.
primary-*, gray-*) defined in global.css.Use cn() to merge Tailwind classes. It combines clsx for conditional classes
with tailwind-merge to resolve conflicting utilities. Import from either
source:
import { cn } from '@/lib/utils';
// or
import { cn } from 'drupal-canvas';
Example usage:
const Button = ({ variant, className, children }) => (
<button
className={cn(
'rounded px-4 py-2',
variant === 'primary' && 'bg-primary-600 text-white',
variant === 'secondary' && 'bg-gray-200 text-gray-800',
className,
)}
>
{children}
</button>
);
Every component should accept a className prop to allow style overrides. Pass
it to cn() as the last argument so consumer classes take precedence.
const Card = ({ colorScheme, className, children }) => (
<div className={cn(cardVariants({ colorScheme }), className)}>{children}</div>
);
className is an implementation/composition prop, not an editor prop. Do not
add className to component.yml, do not mark it as required, and do not
surface it in Canvas metadata.
Canvas projects use Tailwind CSS 4's @theme directive to define design tokens
in global.css. Variables defined inside @theme { } automatically become
available as Tailwind utility classes.
Always check global.css for available design tokens. The @theme block is
the source of truth for colors, fonts, breakpoints, and other design tokens.
When you define a CSS variable in @theme, Tailwind 4 automatically generates
corresponding utility classes based on the variable's namespace prefix:
| CSS Variable in @theme | Generated Utility Classes |
| --------------------------- | ---------------------------------------------------------- |
| --color-primary-600: #xxx | bg-primary-600, text-primary-600, border-primary-600 |
| --color-gray-100: #xxx | bg-gray-100, text-gray-100, border-gray-100 |
| --font-sans: ... | font-sans |
| --breakpoint-md: 48rem | md: responsive prefix |
The pattern is: --{namespace}-{name} becomes {utility}-{name}.
Given this definition in global.css:
@theme {
--color-primary-600: #1899cb;
--color-primary-700: #1487b4;
}
You can use these colors with any color-accepting utility:
// Correct
<button className="bg-primary-600 hover:bg-primary-700 text-white">
Click me
</button>
// Wrong
<button className="bg-[#1899cb] text-white hover:bg-[#1487b4]">Click me</button>
Arbitrary values (e.g., bg-[#xxx]) are acceptable for rare, one-off cases
where adding a theme variable would be overkill. However, if a color appears in
multiple places or represents a brand/design system value, add it to @theme
instead.
Theme variables can reference other variables to create semantic aliases:
@theme {
--color-primary-700: #1487b4;
--color-primary-dark: var(--color-primary-700);
}
Both bg-primary-700 and bg-primary-dark will work. Use semantic aliases when
they better express intent (e.g., primary-dark for a darker brand variant).
When a design requires a color, font, or other value not yet defined in the
theme, add it to the @theme block in global.css rather than hardcoding the
value in a component.
When to add new theme variables:
--color-accent)When to update existing theme variables:
Example - adding a new color:
@theme {
/* Existing tokens */
--color-primary-600: #1899cb;
/* New token for a success state */
--color-success: #22c55e;
--color-success-dark: #16a34a;
}
After adding, you can immediately use bg-success, text-success-dark, etc.
Keep the theme organized. Group related tokens together with comments
explaining their purpose. Follow the existing naming conventions in global.css
(e.g., numbered shades like primary-100 through primary-900, semantic names
like primary-dark).
Never create props that allow users to pass color codes (hex values, RGB,
HSL, or any raw color strings). Instead, define a small set of human-readable
variants using CVA that map to the design tokens in global.css.
Always check global.css for available design tokens. The tokens defined
there (such as primary-*, gray-*, etc.) are the source of truth for color
values.
Wrong - allowing raw color values:
# Wrong
props:
properties:
backgroundColor:
title: Background Color
type: string
examples:
- '#3b82f6'
// Wrong
const Card = ({ backgroundColor }) => (
<div style={{ backgroundColor }}>{/* ... */}</div>
);
Correct - using CVA variants with design tokens:
# Correct
props:
properties:
colorScheme:
title: Color Scheme
type: string
enum:
- default
- primary
- muted
- dark
meta:enum:
default: Default (White)
primary: Primary (Blue)
muted: Muted (Light Gray)
dark: Dark
examples:
- default
// Correct
import { cva } from 'class-variance-authority';
const cardVariants = cva('rounded-lg p-6', {
variants: {
colorScheme: {
default: 'bg-white text-black',
primary: 'bg-primary-600 text-white',
muted: 'bg-gray-100 text-gray-700',
dark: 'bg-gray-900 text-white',
},
},
defaultVariants: {
colorScheme: 'default',
},
});
const Card = ({ colorScheme, children }) => (
<div className={cardVariants({ colorScheme })}>{children}</div>
);
This approach ensures:
global.css tokenstesting
Use for any task touching site chrome — header, footer, sidebar, or global navigation that repeats across pages — and for any region-spec work (create, modify, review, validate region JSON, or the project-level layout component). Also load when a task creates or edits multiple pages that share chrome, or asks for a "site" or "navigation between pages"; shared chrome belongs in regions, never inlined into page JSON.
content-media
Create and modify content templates that map Drupal content entities to Canvas component layouts. Use when asked to (1) Create a new content template, (2) Modify an existing content template, (3) Add or change entity field mappings in a template, (4) Compose components in a content template via slots. Content templates live in the configured `contentTemplatesDir` (default `content-templates/`) and define how Drupal entity types, bundles, and view modes render as Canvas component trees.
tools
Plans and builds Drupal Canvas navigation UI (main nav, footer links, sidebar nav, mobile drawers, breadcrumbs) using design decomposition for structure and props/slots, then JSON:API menu or page-context patterns from canvas-data-fetching. Use when the user asks for navigation, header or footer links, menus, menu_items, mobile nav, or breadcrumb trails. Run after canvas-design-decomposition for layout and API sketches; follow canvas-data-fetching for SWR, JsonApiClient, sortMenu, and menu fallbacks.
development
Plans structure for a component library with props/slots and right-sized component granularity. Run before building or adding Canvas components (new `src/components/` folders, component.yml, React), or for plan-only / breakdown-only work, whenever UI must map to a coherent tree. Mandatory for every new Figma frame or greenfield screen—repository drafts do not replace phases A–G.