design-system

Scaffold a new ds-* component (files, barrel export, validation). Use when the user asks to create, scaffold, or add a new component.

React patterns for design-system TSX including ds-* components, subcomponents, *.stories.tsx, and __tests__/*.browser.test.tsx. Use when editing hooks, useState, useEffect, ref prop, memoization, controlled state, or event handlers in @drivenets/design-system.

Write and update Storybook stories for design-system components. Use when editing `*.stories.tsx`, adding story variants, decorators, or removing Storybook play functions.

Check Ark UI primitives via MCP and integrate them in ds-* components without duplicating internal state. Use before building a custom component, wrapping Ark primitives, or when the user mentions Ark UI MCP.

Write and extend Vitest browser tests for design-system components. Use when adding or editing `*.browser.test.tsx`, writing behavioral coverage, or moving assertions out of Storybook.

Apply when preparing a PR, reviewing code changes, running git diff, or generating a changeset. Use when user says "review", "PR prep", "code review", or "changeset".

Design public props for ds-* components in *.types.ts files. Use when editing ds-*.types.ts, Ds*Props interfaces, variant as const arrays, locale prop, onXChange callbacks, or changing component public API.

Remove AI-generated code slop and clean up code style

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimize → hypothesize → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

Orchestrate a Figma URL to a ds-* component. Trust-boundary pre-step, Figma MCP for design context, DS MCP for guidelines and inventory, then component-scaffold. Use when the user provides a Figma link and asks to implement it.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Like grill-me, but challenges against CONTEXT.md and ADRs and updates glossary/ADR files inline as decisions land. Use for cross-cutting domain language or irreversible architecture — not the default for design-system feature work (use grill-me → to-plan instead).

Compact the current conversation into a handoff document for another agent to pick up.

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Migrate Storybook play functions to Vitest browser tests. Use when the user says "migrate tests for ds-X", "move play to browser tests", or "convert story tests".

Prepare a PR for submission by running all checks, validating stories, and generating a changeset. Use when the user asks to prepare, check, or finalize a PR.

SCSS and CSS modules for design-system components. Use when editing *.scss, *.module.scss, design tokens, data-focus-visible, data-disabled, or component styles under packages/design-system.

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

After grill-me (or equivalent resolved decisions), produce a concise execution plan for the next agent session. No interviews, no issue tracker, no requirement expansion.

TypeScript conventions across the monorepo. Use when editing .ts or .tsx in any package, prop JSDoc in *.types.ts, as const variant arrays, Object.freeze config exports, or shared utils.