Agentic setup

You won't be building this alone. The canonical way to build with Fayz is with an agent — Claude Code, Cursor, Codex, any tool that reads an AGENTS.md. This page gets the ground ready: the accounts and access you need, the MCPs worth having, the rails (skills) that guide each stage, and a product discovery session you can run today, before writing your first line.

The premise

Every generated app ships with an AGENTS.md at the root pointing to this Dev Center — to llms.txt (the map) and to the Markdown pages (the reference). So the agent that opens your project already knows where to find the SDK's real structure instead of guessing.

The first step isn't technical: it's pointing your agent at the knowledge base. How to do that — give it llms.txt first, pull .md pages on demand, keep AGENTS.md in context — is covered in Connect your agent. Do it once per session and the rest of this page works.

Accounts and access

Before you start, have these ready:

You don't need all of it on minute zero: the app runs in mock mode without Supabase, and you only need the Fayz token when it's time to publish. But having the accounts ready keeps you from stalling halfway through.

MCPs

An agent gets much stronger with MCPs (Model Context Protocol) — servers that give the agent tools to act, not just to read.

The one worth having right now is the official Supabase MCP. With it, the agent creates tables, queries data and inspects the schema in natural language, straight from your Supabase project. Most agent-capable editors read an MCP server config block in this format:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": [
        "-y",
        "@supabase/mcp-server-supabase@latest",
        "--read-only",
        "--project-ref=<your-project-ref>"
      ],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "<your-access-token>"
      }
    }
  }
}

--read-only is a safe choice to start with (the agent queries but doesn't change anything). The flags and the exact package name evolve — the source of truth is the official docs: supabase.com/docs/guides/getting-started/mcp.

The honest division of labor: the Supabase MCP is great for letting the agent explore and prototype the database in conversation. Fayz plugin migrations still come from fayz db apply, which assembles the correct order (spine → drizzle → seed → plugins) from the installed packages — see Supabase. One doesn't replace the other: the MCP is the agent's free hand; db apply is the reproducible rail for plugins.

A dedicated Fayz MCP — so the agent can query the catalog and docs without you pasting URLs — is coming soon. For now, llms.txt plus the .md pages do that job.

Repos

By default you clone nothing. The SDK is consumed from npm as @fayz-ai/*, and your app is your own repository — created by the CLI, versioned by you. There's no monorepo to download and no fork to maintain.

Contributions to the core happen by invitation, via the community. To build products, you never need it.

Skills — the rails

The Fayz methodology lives as skills: sequences the agent runs, each covering one stage of the journey. Today they're copy-pasteable prompts you hand to the agent (the full /fayz-descoberta is right below); installable packaging — install the skill and call it by name — is coming soon.

The canonical reference — the five official skills, the recommended community skills (like ui-ux-pro-max and supabase-postgres-best-practices) and how an agent discovers and applies skills — lives in Skills: procedures for your agent. What follows here is just the ready-to-paste prompt for the first stage.

The full /fayz-descoberta

The product starts before the code. Paste the block below into your agent today: it runs a discovery interview, one question at a time, and at the end writes a PRODUCT-BRIEF.md in your repository with the scaffold, plugin and theme decisions.

You are a product discovery partner for the Fayz platform. Read
https://developers.fayz.ai/llms.txt to learn the product types and the
available plugins. Then interview me — ONE question at a time, waiting for
my answer before the next one. If I answer vaguely, ask again until it's
concrete. The questions, in this order:

1. PRODUCT TYPE — which of the catalog types is the closest match?
   (management/admin, scheduling, food, e-commerce, online course, website)
   Reference: https://developers.fayz.ai/en/docs/plugins
2. INDUSTRY / VERTICAL — what line of business? (e.g. aesthetics clinic, food truck)
3. IDEAL CUSTOMER — who exactly suffers from this today, and in what context?
4. TODAY'S PAIN — what does that person do by hand, in Excel, over WhatsApp?
5. THE 1 ESSENTIAL FLOW — ONE single path that, if it works, already delivers value.
   Just one. (e.g. "a customer books a slot and gets a confirmation")
6. MINIMUM DATA — the 2 or 3 entities that flow needs. (e.g. customer,
   service, appointment)
7. BRAND — color, personality and mode (light/dark). Translate it into a theme
   recipe: https://developers.fayz.ai/en/docs/tutorial/03-theme-and-brand
8. NAME — what is the product called?

When you're done, write a PRODUCT-BRIEF.md file in the repository with: the
product summary, the customer and the pain, the essential flow, the minimum
data model, the theme recipe (brand/radius/mode) and the name. Then PROPOSE —
without running anything yet — the scaffold command (fayz create <type> <name>),
the catalog plugins that cover the flow, and the theme block. Wait for my OK.

Golden rule: a small scope that works beats a large scope that doesn't run.

PRODUCT-BRIEF.md becomes the project's memory: the next step (/fayz-bootstrap) reads from it to generate the right app, with the right plugins and the right theme — without you repeating the context.

Next step

With the agent connected, the accounts ready and the brief written, you're set to build. Head to the Quickstart for the fast path, or straight to Tutorial 01 · Create the app for the full walkthrough.

Previous: Concepts · Next: The two paths