Coding agents

Beignet's conventions are enforced by tooling — beignet lint checks dependency direction, beignet doctor reports registration and structure drift, and generators produce canonical output. That makes a Beignet app unusually legible to coding agents: an agent can generate an artifact, check its own work, and fix drift without guessing at project conventions. Three integration points connect agents to that tooling.

Package-shipped skills

Beignet packages ship TanStack Intent skills with the npm package version that contains the code they describe. Generated apps trust the relevant Beignet packages through package.json#intent.skills, so an agent can load the guidance that matches the installed Beignet version instead of relying on a copied file that drifts.

Start with Intent from the app root:

bunx @tanstack/intent@latest install
bunx @tanstack/intent@latest list
bunx @tanstack/intent@latest load @beignet/core#app-architecture

Use the matching runner for the app's package manager, such as npx, pnpm dlx, or yarn dlx.

Load the narrow skill for the task:

The scaffolded guide files

beignet create writes AGENTS.md and CLAUDE.md at the app root. Agents that follow the AGENTS.md convention read AGENTS.md automatically, and Claude reads CLAUDE.md; both files contain the same conventions and also apply to humans.

It carries the conventions an agent cannot discover by reading code:

• Registration is explicit. Generators create or update the central server/ entrypoints for route groups, schedules, tasks, and outbox registries. Hand-written files still need to be wired there before they run, and beignet doctor --fix --dry-run previews exact guarded repairs before beignet doctor --fix --plan <plan-id> applies them.
• Prefer generators. beignet make output lands in the right place, wires registries, and passes lint and doctor; hand-written files often miss a wiring step.
• The capability index. A need-to-API table for the machinery agents most often reimplement by accident: query-cache invalidation, service contexts for non-HTTP entrypoints, reaching ports outside a request, raw routes, metadata-driven rate limits and idempotency, route-level test harnesses, and env validation.
• The validation loop. Run beignet check after each change — it runs the app's Biome lint, beignet lint, beignet doctor --strict, tests, and typecheck in one pass — and treat findings as the next task.
• Placement rules and the naming grammar. Where feature artifacts live, and how defineX, createX, and createXProvider divide the API.

The guide deliberately excludes anything discoverable from the code or covered elsewhere: package skills own framework-specific agent guidance, the README.md owns setup and run instructions, and AGENTS.md and CLAUDE.md own app-local conventions. Keeping them short keeps agents reading them.

The MCP server

beignet mcp runs a Model Context Protocol server over stdio, exposing the app's guidance and focused feature maps as resources plus the CLI's inspection, generation, and operational commands as tools.

Resources are read-only:

Operational tools isolate app code from the long-lived MCP server, bound the structured result, and stop the complete process tree when the request is cancelled or its timeout expires. Optional module overrides must remain app-relative; the server rejects paths outside the app root where it started. Cancellation and timeouts cannot roll back side effects that already completed. Inspect app state before retrying an interrupted operation or one that reports a cleanup failure. Tool outputs are exactly the JSON the CLI's --json flags produce, so anything written against beignet map --json, beignet explain ... --json, beignet check --json, beignet db ... --json, beignet doctor --json, beignet lint --json, beignet task run ... --json, beignet schedule run ... --json, or beignet outbox ... --json reads MCP results unchanged. For persistent generated work, the intended coding loop is app_map to orient, explain to focus one concept, make or an edit to change it, db_schema_sync when provider tables changed, db with generate then migrate, the relevant task, schedule, or outbox tool when operational work is required, and check to verify the whole app.

Generated apps ship a .mcp.json that registers the server through the app-local @beignet/cli bin, so Claude Code picks it up with zero configuration. Other clients, such as Cursor and VS Code, take the same command in their own config files (.cursor/mcp.json or .vscode/mcp.json):

{
  "mcpServers": {
    "beignet": {
      "command": "./node_modules/.bin/beignet",
      "args": ["mcp"]
    }
  }
}

Run the MCP client from the app root so the relative bin path resolves to the installed app version. For one-off usage outside an installed app, use the scoped package name with a registry runner, such as bunx @beignet/cli mcp or npx @beignet/cli mcp; never use the unscoped beignet npm name.

llms.txt

The docs site publishes two plain-text views of itself, rebuilt on every docs build:

• https://beignetjs.com/llms.txt — an llms.txt-style index mirroring the docs navigation: every page with its title, URL, and description.
• https://beignetjs.com/llms-full.txt — the full text of every docs page in one file.

Use the index when an agent should navigate to the right page and fetch it; use the full file when an agent retrieves grep-style over the whole corpus.

See the CLI reference for the beignet mcp command and App architecture for the structure the conventions in AGENTS.md and CLAUDE.md describe.