
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.
Design Canvas-ready React components with slots and decomposition-first patterns. Use when (1) Designing a component's prop/slot structure, (2) A component is growing too large, (3) Deciding between props vs slots, (4) Refactoring monolithic components, (5) Modeling repeatable list/grid content, (6) Reusing, composing, or wrapping existing workspace components. Ensures Canvas compatibility.
Start here for any React component task to enforce the canonical Canvas component contract. Use for create, modify, refactor, review, migrate, or validate work. Establishes the canonical Canvas component contract, assuming repository components are Canvas targets, and guides either (1) transforming existing components to meet Canvas requirements or (2) creating new Canvas-ready components.
Define valid component.yml metadata for Canvas components, including props, slots, and enums. Use when (1) Creating a new component, (2) Adding or modifying props, (3) Troubleshooting "not a valid choice" or prop type errors, (4) Mapping enums to CVA variants.
Push validated Canvas component changes to Drupal Canvas and recover from common push failures. Use only when the user explicitly requests a push/publish/sync action. Handles dependency-related push failures that require retry.
Start here for any Canvas page-spec task. Use for create, modify, refactor, review, migrate, or validate work on page JSON files that sync with Canvas and render in Workbench. Establishes the canonical Canvas page-spec contract, including placement, structure, format constraints, and validation.
Use when work must be verified in local Canvas Workbench, or when the user asks to run, open, check, or author component mocks or page previews in Workbench. Verifies that Canvas Workbench is available through the project's package runner, starts the local Workbench dev server, and keeps Workbench verification as part of the implementation workflow.
Use utility components to render formatted text and media correctly. Use when (1) Rendering HTML text content from props, (2) Displaying images, (3) Working with formatted text or media. Covers FormattedText and Image utilities.
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.
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.
Fetch and render Drupal content in Canvas components with JSON:API and SWR patterns. Use when building content lists, integrating with SWR, querying related entities, or constructing/changing any JSON:API request — every generated request must be executed and verified to return the expected results before rendering logic is written against it. Covers JsonApiClient, DrupalJsonApiParams, relationship handling, filter patterns, and request verification.
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.
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.