component-builder

Bricks: Component Layer for AI Agents

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.

Install

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.

Why Bricks Exists

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.

What Bricks Is

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.

Component Coverage

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.

From Request to Integrated Component

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.

Context Matters

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.

Working With Pagina

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.

Boundaries

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.

Repository Model

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.

Development

npm test

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

License

MIT