kostja94/bricks

Bricks gives coding agents implementation-aware contracts for building interface components that belong in an existing product, codebase, and design system.

It helps an agent understand a component's responsibility, context, variants, content, interaction states, technical boundary, and verification requirements before writing code.

npx skills add kostja94/bricks --skill component-builder

Give the agent a bounded component task and the context needed to integrate it:

Use component-builder to build the footer for this bilingual SaaS site.

Read the existing routes, components, design tokens, framework, and responsive conventions first. Reuse project primitives, include the real product, resource, company, and legal destinations, and verify keyboard access on mobile and desktop.

See the complete Footer request example.

Agents are already capable of writing component code. The harder problem is deciding what the component is responsible for and making it fit the product around it.

A generated Footer may invent routes. A FAQ may hide answers from assistive technology. A Task Input may omit loading, cancellation, invalid input, or result recovery. An Agent Workspace may look convincing in a demo while having no workable boundary between conversation, tools, artifacts, and user control.

Bricks addresses that reasoning layer. It guides the agent toward a project-native implementation instead of shipping an isolated demo or importing a second design system by habit.

One component can have many valid designs. Bricks keeps Footer guidance in one reference and lets the target product determine its layout, typography, density, content, and implementation.

The catalog spans small primitives, content structures, conversion elements, and composed Agent interfaces:

Browse the machine-readable inventory in catalog/components.json. Component IDs remain stable while their references can grow as new contexts and constraints are learned.

The component-builder does not begin with a preferred library or visual treatment.

1. It inspects the page, nearby components, tokens, dependencies, data model, responsive conventions, and tests.
2. It identifies the canonical component concept, user task, surface, and ownership boundary.
3. It loads only the matching component reference and shared quality gates.
4. It selects a variant from real content and context.
5. It reuses the project's primitives and implements required states and interactions.
6. It verifies the component inside its actual page, not only in an isolated preview.

For components with complex domain behavior, such as editors, data grids, charts, calendars, or accessibility primitives, the agent should use a proven library when the project does not already provide one.

The same component identity changes meaning across surfaces and pages.

• A public marketing Footer organizes product, resource, company, and legal destinations.
• An authenticated application Footer may be absent or reduced to operational links.
• A documentation Sidebar needs hierarchy, active state, deep navigation, and narrow-screen behavior.
• A dashboard Sidebar must also account for permissions, workspaces, collapsed states, and task frequency.

Bricks records these contextual decisions without turning every combination into a new component name.

Pagina and Bricks operate at different levels:

Pagina defines the complete page contract
                    |
                    v
Pagina recommends required component concepts
                    |
                    v
Bricks guides project-native component construction
                    |
                    v
The target repository owns the final code and design system

Use Pagina when the task is a complete page with page-level content, sections, routes, and multiple components. Use Bricks when the task is one named component or a bounded composition pattern. Pagina remains usable without Bricks when the target project already has every component it needs.

Bricks builds new interface components and bounded composition patterns. It does not plan a whole product, define a complete website, or own purely editorial copy.

The current Skill does not maintain a separate audit or reconstruction workflow. It also does not claim performance, accessibility, compliance, or conversion outcomes that were not actually verified in the target project.

skills/component-builder/
  SKILL.md                              component construction entry point
  references/
    workflow.md                         shared construction workflow
    quality-gates.md                    component acceptance criteria
    pagina.md                           page-versus-component boundary
    components/                         one reference per component concept
catalog/components.json                 machine-readable inventory
schemas/component-reference.schema.json
scripts/validate.mjs                    deterministic checks
examples/                               realistic invocation examples

References describe semantic responsibility, contexts, variants, constraints, and verification. They may include implementation suggestions where useful, but they do not prescribe a single stack or visual result.

npm test

Validation checks the component catalog, reference paths, schema expectations, page-context relationships, and the component-builder Skill.

MIT