📈 GH Trending Explorer 🎲 Surprise me

← all repos

kostja94 / bricks

git clone https://github.com/kostja94/bricks.git

Component layer for AI agents: implementation-aware contracts for building project-native interface components.

+0
stars, 24h · #31,296
+~0
stars, 7 days · #31,771
+199
stars, 30 days · #2,648
191
★ total
0
forks · 0 open issues

Star history (as recorded here)

2026-10-20 · 199 ★ 2026-10-22 · 191 ★
LanguageJavaScript
LicenseMIT
Created2026-09-25 (27d ago)
Last push27d ago
Watchers0
OwnerUser

GitHub topics

Links

README excerpt
# 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
 [code] 
Give the agent a bounded component task and the context needed to integrate it:
 [code] 
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
| Bricks provides | Bricks does not provide |
|-----------------|-------------------------|
| One maintained contract per component concept | A separate Skill for every visual style |
| Semantic responsibility and ownership boundaries | A fixed React, Vue, or CSS component package |
| Context-aware variants and expected states | A universal design system |
| Integration and verification guidance | A gallery of interchangeable mockups |
| Stable component IDs for Agent tooling | Permission to replace project conventions |
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:
| Group | Representative components |
|-------|---------------------------|
| Navigation and orientation | Navigation Menu, Footer, Breadcrumb, Sidebar, Table of Contents |
| Content and explanation | Article Content Layout, Author Bio, FAQ Section, How-to Section, Tabs, Accordion |
| Conversion and trust | CTA, Newsletter Signup, Comparison Table, Testimonials, Trust Signals |
| Layout and presentation | Card, Grid, List, Masonry, Carousel, Modal, Announcement Banner |
| Agent and tool interfaces | Task Input, Conversation, Chat Panel, Agent Workspace, CMS Editor Workspace |
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, dep