Bricks skill
Skills that give an agent component contracts: it builds, inventories, audits and cleans interface components to fit your product.
- 194 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- The skills edit and delete project component files, and cleanup removes unused files.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/bricksDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The skills edit and delete project component files, and cleanup removes unused files.
This is third-party code. Review the repository files before installing.
What it does
Bricks explains to the agent what a component is responsible for, the context it lives in, its variants, states, content and implementation boundary, and only then lets it write code. There are four entry points by outcome: `component-builder` builds a missing component in its real page context, and `component-inventory` finds pages, components and inline UI and saves a component system document. `component-auditor` looks for semantic duplicates and drift, aligns one family at a time and carries out confirmed reconstruction, while `component-cleanup` removes verified unused components and abandoned generated UI. Component references sit in `skills/component-builder/references/components/`: Footer, FAQ, Card, Carousel, Chat Panel, Agent Workspace and more.
Who it is for. Frontend developers and design engineers who ask an agent to build a component inside an existing project and do not want a foreign design system.
Good fit when
- A bilingual SaaS site needs a footer with real routes for the product, resources and legal pages.
- Before a UI refactor pages and components are inventoried in `docs/component-system.md`.
- Duplicates in a component family must be found and merged into one.
- Abandoned components and generated leftovers are removed from the project with their exclusive tests and styles.
Not a fit when
- You need a ready React or Vue library rather than contracts and checks.
- A whole page with many sections: there is a separate reference for that.
- You want to replace the project existing design system with a familiar library.
Example request
Use component-builder to build the footer for this bilingual SaaS site: read the project routes, tokens and components and verify keyboard access on mobile and desktop.Limitations
Bricks ships no ready components and does not replace the project design system; it provides only contracts and checks. An unimported component is a removal candidate, not proof: dynamic entry points, public exports and base libraries must be checked. Inventory needs a project document, `docs/component-system.md` by default. Each skill installs separately: `npx skills add kostja94/bricks --skill component-inventory`.
How to disable. Delete the `component-builder`, `component-inventory`, `component-auditor` and `component-cleanup` folders from the agent skills directory. The `docs/component-system.md` document stays in the project.
FAQ
How do I install a skill?
With `npx skills add kostja94/bricks --skill component-builder`. For inventory, audit and cleanup substitute `component-inventory`, `component-auditor` or `component-cleanup`.
What does `component-inventory` do?
It finds real pages, components and inline UI and saves a component system document with page-to-component and component-to-page links, content sources and verification gaps.
How does Bricks differ from a component library?
It has no components. It gives one contract per concept: responsibility, variants, states and checks, while your project decides the implementation.
How should I phrase a task?
Limit the task to one component and give context: routes, tokens, framework and responsive rules. An example sits in `examples/footer-request.md`.
Is deleting unused code safe?
`component-cleanup` removes only verified unused components. A missing import is a candidate, and dynamic entries and public exports are checked separately.
Discussion
No questions or reviews yet.
Related
SkillsA skill based on the components.build specification: how to build composable, accessible and styleable UI components and publish them
45 skills for an agent working with WordPress Bricks through MCP: design system, templates, elements and dynamic data.
Skill for Bricks Builder: ready JSON for layouts, templates, query loops, ACF and popups, verified against the Bricks 2.3.6 theme
A UI design skill: art direction per product, a shared DESIGN.md, tokens, and layout and accessibility checks in a browser.
A skill for interfaces without the generic AI look: typography, color, motion, component states and a critique of the result.
The building-ui skill opens an editable UI mock: you change it directly, then the agent implements it with TDD.
README in short
The component catalog is defined in `catalog/components.json` with a reference schema. Groups cover navigation, content, conversion and composed agent interfaces, and `scripts/validate.mjs` checks consistency.
README badge
Original SKILL.md
--- name: component-builder description: Build new interface components and bounded composition patterns inside an existing project. Use for named components, interface blocks, and workspaces. Preserve the target project's design system and stack; for a complete new page with page-level structure and multiple sections, use Pagina page-builder instead. Do not use to audit or reconstruct an existing component, plan a whole product or website, or handle purely editorial copy requests. metadata: version: 0.2.0 --- # Component Builder Create new components that belong in the target product instead of producing isolated demo UI. ## Start With The Project Inspect the relevant page, nearby components, design tokens, dependencies, content model, responsive conventions, and tests before choosing an implementation. Reuse established primitives and icon libraries. Do not replace an existing design system merely because another library is familiar. Identify: - the requested component concept and user task; - the surface and interface type; - where the new component belongs and which existing primitives it may reuse; - the component's real content and states; - the target stack and existing ownership boundary. For a page composition, define the page's job and reuse child components from the catalog. Do not turn a page pattern into a second maintenance source for every component it contains. ## Load Only Relevant Guidance Read [references/workflow.md](references/workflow.md) for construction work. Read [references/foundational-controls.md](references/foundational-controls.md) when the request involves Button, Link, Input, Select, Form, or another foundational control and [references/quality-gates.md](references/quality-gates.md) before final verification. Read [references/pagina.md](references/pagina.md) when the request may be a complete page rather than a bounded component. Find the component ID in [../../catalog/components.json](../../catalog/components.json), then read only its referenced component file. If the requested concept is absent, use the shared workflow, state the inferred canonical name in the result, and do not invent a permanent catalog entry unless the task includes repository maintenance. ## Build 1. Define the semantic responsibility and boundary before styling. 2. Choose a variant from context and content, not fashion. 3. Preserve project conventions and integrate real content or data contracts. 4. Implement expected states, responsive behavior, keyboard behavior, and failure handling. 5. Verify the component in its actual page context. A component that only looks correct in isolation is incomplete. ## Boundaries - One component concept has one maintained reference. Role, placement, visual variant, and runtime state do not create new catalog entries. - Established independent terminology and discovery intent may justify separate entries that share a model, as with Grid, List, and Masonry.