AI & Agent Tooling

WireKit is designed to be legible to large language models and AI coding agents. Every component shares one predictable <x-wirekit::*> namespace, every prop and slot is published in a machine-readable schema, and every documentation page is downloadable as raw Markdown — so whatever assistant you work with can discover the full component library, suggest the right tag, and write correct Blade the first time.

This page is the single reference for that surface: the public manifests served from docs.wirekit.app, the project-side Artisan exports you run inside your own app, and the editor and agent integrations that tie them together. Everything here is additive — none of it changes how your app builds or ships.

Quick start: onboard your assistant

Paste this into your AI assistant (Cursor, Claude Code, ChatGPT, GitHub Copilot Chat, or any other) to point it at WireKit's full surface in one shot:

WireKit is a free, MIT-licensed UI component library for Laravel Livewire.
Every component is a Blade tag of the form <x-wirekit::name>.

- Machine-readable component index (every component, prop, slot, category):
  https://docs.wirekit.app/components.json
- Surface sitemap (components, Alpine plugins, fonts, icons, commands, CSS classes):
  https://docs.wirekit.app/api-map.json
- Block index (every blueprint and page layout, with its dependencies):
  https://docs.wirekit.app/blocks.json
- Concise LLM overview:
  https://docs.wirekit.app/llms.txt
- Raw Markdown for any page: append .md to its URL, e.g.
  https://docs.wirekit.app/components/modal.md

Use these to write correct WireKit Blade. Prefer composing existing
WireKit components over hand-rolling raw HTML.

The assistant now knows where to look up any component instead of guessing prop names — the single biggest win for accuracy.

Why WireKit works well with AI

One namespace, zero guesswork. Every component is <x-wirekit::*>. An assistant that learns the pattern once can compose the entire library — no per-component import lines, no ambiguous class names to disambiguate.
A machine-readable schema. components.json lists every component with its exact prop names, types, defaults, and slots — so an agent reads the contract instead of hallucinating it.
Raw Markdown per page. Append .md to any docs URL to get the original source, ready to drop into a context window. The examples are guaranteed to match what a developer sees because it is the same source that renders the page.
Project-side exports. Artisan commands emit the same schema from inside your app, so an agent working in your repository understands WireKit with no network access at all.
A ready-made rules file. php artisan wirekit:cursor-rules drops a Cursor rules file into your project so the editor's assistant follows WireKit conventions automatically.
A live MCP server. php artisan wirekit:mcp-serve lets an MCP-capable editor query the component catalog as live tools while you author — so it reads the real props and design tokens instead of recalling them.

Machine-readable manifests

The manifests below are published at the root of docs.wirekit.app and regenerated on every docs deploy, so they always describe the current release. Fetch them directly — no authentication, no rate limit.

Manifest	URL	What it contains
Component index	`components.json`	Every component with its props, slots, category, and docs URL
Surface sitemap	`api-map.json`	Every WireKit surface — components, Alpine plugins, fonts, icons, commands, helpers, CSS classes — grouped, with the docs route for each
Block index	`blocks.json`	Every blueprint and page-layout block with its category, tags, dependencies, preview URL and Markdown source
LLM overview	`llms.txt`	A concise, plain-text overview written for language models

components.json — the component index

The canonical machine-readable description of the library. Each entry carries the component's tag name, its category, every prop with its type and default, its slots, and a link to the human docs page. An agent fetches it once and writes against the real contract:

# 1. Pull the full component index (props, slots, categories for every component).
curl -s https://docs.wirekit.app/components.json

# 2. Or pipe it through jq to list just the tag names.
curl -s https://docs.wirekit.app/components.json | jq -r '.components[].name'

api-map.json — the surface sitemap

The hierarchical view: what exists, grouped by kind, with the docs route for each entry. Where components.json answers "what props does this component take", the api-map answers "what surfaces are there at all" — so a tool can suggest the right one and fetch its page on demand rather than pulling every component's full record first.

# 1. List the groups and how many surfaces each one holds.
curl -s https://docs.wirekit.app/api-map.json | jq -r '.groups[] | "\(.id): \(.count)"'

blocks.json — the block index

The block-level counterpart to components.json: every blueprint and page layout, with the dependencies it composes from, its preview URL and a link to its Markdown source. An agent that has been asked for a settings page or a pricing section reads this to find the block that already exists instead of assembling one from primitives.

# 1. Find every block that composes from a given component.
curl -s https://docs.wirekit.app/blocks.json | jq -r '.blocks[] | select(.dependencies[]? == "stat") | .slug'

llms.txt — the LLM overview

A short, plain-text orientation file describing what WireKit is, the <x-wirekit::*> namespace, and where to find the deeper manifests. It follows the emerging llms.txt convention for exposing a site to language models, and it is the smallest possible file to seed an assistant's context before it dives into components.json.

Raw Markdown for any page

Every documentation page is available as raw Markdown — append .md to its URL:

https://docs.wirekit.app/components/button       → the rendered page
https://docs.wirekit.app/components/button.md    → the raw Markdown source

Drop the Markdown straight into a chat context window or a retrieval index. Because it is the exact source that renders the page, the code examples an assistant reads are the same ones a developer sees — no drift between what the model learns and what actually ships.

Project-side exports

Prefer to keep everything local? Three Artisan commands emit the same machine-readable data from inside your own app — ideal for an agent working in your repository without network access, or for committing a schema snapshot your whole team shares. Full flag documentation lives in the CLI Reference.

`wirekit:export-json` — the schema manifest

Emits the same component schema as components.json, generated from the package installed in your app:

# 1. Print the schema to stdout (machine-minified JSON).
php artisan wirekit:export-json

# 2. Add --pretty for a human-readable, diff-friendly file you can commit.
php artisan wirekit:export-json --pretty > .wirekit-schema.json

php artisan wirekit:install already writes a .wirekit-schema.json to your project root for exactly this purpose — a zero-configuration feeder file for IDE extensions and AI tools. Commit it for stable autocomplete across your team, or add it to .gitignore to keep it fresh on every install. It is regenerated on every wirekit:install run.

`wirekit:export-api-map` — an AI-friendly sitemap

Emits a hierarchical, machine-readable sitemap of every WireKit surface — components, Alpine plugins, and docs routes. It is built specifically for MCP servers, Claude Code, ChatGPT Codex, Cursor, Aider, and other AI tooling that wants to know which surfaces exist and where to read more:

# 1. Emit the AI-friendly sitemap of every WireKit surface.
php artisan wirekit:export-api-map

`wirekit:export-blocks` — the block manifest

The block-level counterpart to wirekit:export-json. Emits every blueprint and page-layout block with its slug, kind, title, description, category, tags, dependencies, responsive and dark-mode flags, its preview URL, and the URL of its raw Markdown source:

# 1. Emit the manifest of every blueprint and page-layout block.
php artisan wirekit:export-blocks

Runs from a checkout, not from an install The block sources are documentation rather than package code, so a Composer install does not carry them. Run this one from a clone of the repository. In an installed package it fails by name rather than emitting an empty manifest — an empty result and a run whose sources were silently absent read identically, and the wrong one of those looks like a project with no blocks.

Editor & agent integration

Cursor

wirekit:cursor-rules publishes WireKit's Cursor rules file to .cursor/rules/wirekit.mdc in your project. The file teaches Cursor's assistant the <x-wirekit::*> namespace, the composition conventions, and the house rules — so completions follow WireKit patterns from the start:

# 1. Publish the WireKit rules file into .cursor/rules/wirekit.mdc.
php artisan wirekit:cursor-rules

# 2. Re-run with --force to overwrite an existing copy after an upgrade.
php artisan wirekit:cursor-rules --force

Commit .cursor/rules/wirekit.mdc so every teammate's editor shares the same rules.

MCP server (live, local)

php artisan wirekit:mcp-serve runs a local Model Context Protocol server over stdio (JSON-RPC 2.0). An MCP-capable editor spawns it as a child process and queries the component catalog live while you author — so the assistant reads real prop signatures and design tokens instead of recalling them. It is local and read-only: no port, no daemon, no network, and always version-matched to the WireKit installed in your app. It exposes:

search_components — find components by name or description
list_components — every component, grouped by category
get_component — one component in full: its props, slots, sub-components and docs URL, plus whether it is an anonymous or a class-based component. Each prop carries its default expression exactly as the source writes it, the inline comment beside it where the source has one, and any @example values that comment declares. A class-based component's props also carry their declared PHP type; an anonymous component's @props block declares no types, so that field is null
get_component_examples — worked examples for one component, taken from its documentation page
get_component_accessibility — what one component has already wired: the roles and aria-* attributes its markup emits, the keys its behavior handles, the names it waits for you to supply, and the design tokens it reads
get_tokens — the design-token reference (colors, spacing, radii, and the rest)
get_conventions — the house rules for authoring WireKit markup, served as the shipped documents rather than as a list kept alongside them. Pass detailed for the full authoring ruleset instead of the short entry point
list_recipes — the recipe library: the composed page shapes wirekit:make scaffolds, each with the command that writes it
get_recipe — one recipe in full, including the Blade source the scaffold writes
list_presets — the bundled theme presets, each with the command that applies it
get_preset — one preset with the exact CSS custom properties the command appends, light and dark

list_presets and get_preset read the same registry wirekit:theme writes from, which is the whole reason they exist rather than a table in these docs. A theme preset is applied by running a command, never by hand-copying tokens into app.css — an assistant that knows the presets by name can offer the command instead of inventing a palette.

list_recipes answers a question the component tools cannot: is the whole page already written? The recipe library ships as real Blade — a documentation reader, a marketing landing page, a live KPI strip, an on-page table of contents and more — and wirekit:make recipe:<name> writes one into a project. Ask list_recipes for the current set rather than guessing at it. An assistant that only sees components assembles the page out of primitives instead, which is more code, more decisions and a worse result than the composition somebody already reviewed. Both tools read the shipped stubs rather than the documentation pages, so they answer the same in your installation as they do here.

get_conventions is the one to ask for FIRST, once per session, and the reason is that nothing else in this list will tell you. A prop signature says what a component accepts; it does not say that a Tailwind palette class, a dark: prefix, a hand-written color, an outer margin or an icon sized with h-4 w-4 is rejected here — and each of those fails a build guard rather than merely looking off. An editor reading .cursor/rules/wirekit.mdc from disk already had those rules; an MCP client has no filesystem and had no way to reach them.

The two documents it serves both ship inside the package, so the answer is whatever your installed version says and there is no third copy to keep in step:

Document	What it is	Served as
`AGENTS.md`	the short entry point at the package root — the namespace, the composition rules, and the handful of things that are rejected outright	the default response
`.cursor/rules/wirekit.mdc`	the full authoring ruleset, the same file `wirekit:cursor-rules` publishes into your project	`detailed`

Both are in the installed tarball, so you can also read them straight out of vendor/pushery/wirekit/ when you have a filesystem — the tool exists for the clients that do not.

get_component_accessibility is the one worth asking for before adding a role, an aria-* attribute or a key handler of your own, and both wrong answers ship markup that looks right. A role placed on top of one the component already carries is two competing contracts on one element. A name the component waits for and never receives leaves a landmark that is announced and says nothing. Every field is read out of the sources that ship — the markup for the roles, the attributes and the tokens, the template and the behavior for the keys — so it describes the version you have installed rather than a checklist somebody kept by hand. The token list is the per-component half of "does this follow the token system": every component does, and a build guard fails on a hardcoded value, so the answer worth returning is which knobs this one reads rather than a sentence every component would carry identically.

get_component_examples is the one worth asking for before writing markup. A prop list tells an assistant what is allowed; an example shows a composition somebody reviewed — which sub-component wraps which, which props are set together, what the canonical shape of that component actually is. Ask for a sub-component (card.body) and you get its parent's page, because that is where a card body is shown inside a card. The same holds for a primitive that a family documents on one page without a dotted name — reading-spine answers with the reading page, bento-cell with the bento-grid page — so a component whose examples live under a different heading still answers with usage rather than with silence.

The examples are extracted from the documentation when the package is built, not read at runtime: the documentation is not part of the installed package, so a server that read it would answer correctly in WireKit's own repository and "no examples" in yours. A test fails the build when the two drift apart.

Point your editor's MCP settings at the command. The universal stdio form (works in a project-local .cursor/mcp.json and most MCP clients):

{
  "mcpServers": {
    "wirekit": {
      "command": "php",
      "args": ["artisan", "wirekit:mcp-serve"]
    }
  }
}

The server must run from your Laravel project root (where artisan lives) — a project-local .cursor/mcp.json does this automatically. For Claude Code, register it from the project root:

# 1. Register the WireKit MCP server (run from your project root).
claude mcp add wirekit -- php artisan wirekit:mcp-serve

It is not meant to be run by hand — the editor manages its lifecycle.

No MCP client? Any agent that runs in your repository works just as well against the project-side exports: point it at the committed .wirekit-schema.json (or run wirekit:export-api-map) so it resolves component names and props locally, with no network round-trip. The api-map's hierarchical shape lets a tool suggest the right surface and then fetch the matching docs page on demand.

GitHub Copilot and other assistants

Any assistant that reads your workspace benefits from a committed .wirekit-schema.json at the project root — it surfaces every component and prop as the model indexes your repository. Pair it with the published components.json for the always-current release schema.

CLI introspection

For an agent that can run shell commands, two read-only commands expose the library without leaving the terminal:

# 1. List every component — optionally filtered by category.
php artisan wirekit:list
php artisan wirekit:list --category=Form

# 2. Reveal one component's props, slots, and usage.
php artisan wirekit:show button

Prompting tips

Anchor the assistant first. Give it the quick-start block above before asking for components, so it looks up components.json instead of guessing prop names.
Ask for composition, not raw HTML. WireKit's value is in composing <x-wirekit::row>, <x-wirekit::card>, <x-wirekit::stat>, and friends — prompt for those rather than <div> scaffolding.
Pin the version. If you committed .wirekit-schema.json, tell the assistant to treat it as the source of truth so it matches your installed release exactly.