Introduction

What it is

The boilerplate skill carries the components every product needs, and only their behavior: their parts, their Base UI wiring, how they scroll, stack and animate. Your agent reads your project first (its theme, its tokens, the components you already have) and writes each component in your style. I made it for my own client work at frontend.supply, where every project needs these and none can afford to get them wrong.

Getting started

Install the boilerplate skill in your project's folder. It works in Claude Code, Codex, Cursor, OpenCode and the other agents that read skills, and it's committed with your code, so everyone on the project has it:

npx skills add frontendsupply/skills --skill boilerplate

Add -g to install it for every project on your machine instead. Then ask for what you need, in your own words. The skill picks the components, reads the project's style, writes them in it and uses them where you asked:

Add a confirmation dialog before deleting a project.

If the project already has one, ask for a rebuild: the skill keeps its look, its names and every place that uses it working.

Rebuild our select on the boilerplate, without breaking anything that uses it.

When it's done, the component is ordinary code in your project. The skill leaves a note in the project's CLAUDE.md naming the files and their look map, so the next component matches and later edits keep the behavior, with or without the skill. To get new components and fixes, run npx skills update, then /boilerplate update. Every component is built on Base UI and merges its classes with cn, in every project: the skill installs both if they're missing, even next to Radix or a cn of your own, which stay for the rest of your code. They need React and Tailwind CSS v4; on v3, the skill offers Tailwind's upgrade first.

Commands

Everything the skill does, it also does from a plain request; the commands are there when you want to be exact. Names can be one component, several, or all.

/boilerplate

Where the project stands: its stack, which components it has and where they came from, and what to do next. Changes nothing.

/boilerplate add dialog

Adds a component from scratch, styled like the rest of the project. If the project already has one, it rebuilds that one instead.

/boilerplate refactor menu

Rebuilds a component the project already has (shadcn/ui, Radix, a library or its own) and updates every call site in the same change.

/boilerplate review

Audits the project's components: what a rebuild would gain and cost, and the command to run. Changes nothing.

/boilerplate update

Brings components installed earlier up to date, keeping the project's look and any changes it made on purpose.

/boilerplate check

Proves the installed components kept their behavior (below).

Behavior and look

Every class in a component is marked as one or the other. Behavior is what the component needs to work: layout, overflow, positioning, size limits, motion and state hooks. It is copied exactly. Look is color, border, radius, shadow, type and spacing. It is rewritten to match your project.

const itemClassName = cn(
  // behavior
  'flex w-full cursor-default items-center text-left whitespace-nowrap outline-hidden select-none',
  // look
  'h-8 gap-2 rounded-xs px-2 data-highlighted:bg-soft',
);

Where a look value feeds the behavior (a radius a clip-path has to follow, a padding a submenu has to land on), the skill names it, and it changes in one place.

The check

Every component ships with a list of its behavior classes, slots and exports, made from the same file. After writing a component, the skill runs its check against your copy: every behavior class and every slot must still be there, and none of the skill's own color names may be left unfitted. Anything missing is put back, or, when you asked for the change, named in the report. You can run it yourself at any time with /boilerplate check.

Composition

A component is a set of small parts, never a data-driven API or a row of feature flags. Base UI parts take arender prop natively; our own parts get the same prop through Base UI's useRender, so every part composes the same way, and components never import each other.

<Collapsible.Root render={<SidebarGroup />}>              {/* Base UI → ours */}
  <SidebarGroupLabel render={<Collapsible.Trigger />}>…   {/* ours → Base UI */}
  <SidebarMenuButton render={<a href="/inbox" />}>…        {/* ours → element */}

Every part sets a data-slot, takes a className merged last, and styles its states from data attributes such as data-highlighted or data-popup-open.