Setup agêntico

Você não vai construir sozinho. A forma canônica de construir com a Fayz é com um agente — Claude Code, Cursor, Codex, qualquer ferramenta que leia um AGENTS.md. Esta página prepara o terreno: as contas e acessos, os MCPs que valem a pena, os trilhos (skills) que guiam cada etapa, e uma sessão de descoberta de produto que você faz hoje, antes de escrever a primeira linha.

A premissa

Todo app gerado já nasce com um AGENTS.md na raiz apontando para este Dev Center — para o llms.txt (o mapa) e para as páginas em Markdown (a referência). Então o agente que abre o seu projeto já sabe onde buscar a estrutura real do SDK em vez de chutar.

O primeiro passo não é técnico: é apontar o seu agente para o knowledge base. Como fazer isso — dar o llms.txt primeiro, puxar páginas .md sob demanda, deixar o AGENTS.md no contexto — está detalhado em Conecte seu agente. Faça isso uma vez por sessão e o resto desta página funciona.

Contas e acessos

Antes de começar, tenha à mão:

Você não precisa de tudo no minuto zero: o app roda em modo mock sem Supabase, e você só precisa do token Fayz na hora de publicar. Mas ter as contas prontas evita travar no meio.

MCPs

Um agente fica muito mais forte com MCPs (Model Context Protocol) — servidores que dão ao agente ferramentas para agir, não só ler.

O que vale a pena agora é o Supabase MCP oficial. Com ele, o agente cria tabelas, consulta dados e inspeciona o schema em linguagem natural, direto do seu projeto Supabase. A maioria dos editores com agente lê um bloco de configuração de MCP servers neste formato:

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

O --read-only é uma escolha segura para começar (o agente consulta mas não altera). Os flags e o nome exato do pacote evoluem — a fonte da verdade é a doc oficial: supabase.com/docs/guides/getting-started/mcp.

A divisão de trabalho, honesta: o Supabase MCP é ótimo para o agente explorar e prototipar o banco em conversa. As migrações dos plugins Fayz continuam vindo do fayz db apply, que monta a ordem correta (spine → drizzle → seed → plugins) a partir dos pacotes instalados — veja Supabase. Um não substitui o outro: o MCP é a mão livre do agente; o db apply é o trilho reproduzível dos plugins.

Um MCP dedicado da Fayz — para o agente consultar catálogo e docs sem colar URLs — está em breve. Por enquanto, o llms.txt mais as páginas .md fazem esse papel.

Repos

Por padrão você não clona nada. O SDK é consumido do npm como @fayz-ai/*, e o seu app é o seu próprio repositório — criado pela CLI, versionado por você. Não existe um monorepo para baixar nem um fork para manter.

Contribuições ao core acontecem por convite, via comunidade. Para construir produtos, você nunca precisa disso.

Skills — os trilhos

A metodologia Fayz vive como skills: sequências que o agente executa, cada uma cobrindo uma etapa da jornada. Hoje elas são prompts copiáveis que você dá ao agente (o /fayz-descoberta completo está logo abaixo); o empacotamento instalável — instalar a skill e chamá-la por nome — está em breve.

A referência canônica — as cinco skills oficiais, as skills da comunidade recomendadas (como ui-ux-pro-max e supabase-postgres-best-practices) e como um agente descobre e aplica skills — vive em Skills: procedimentos para o seu agente. Aqui embaixo fica só o prompt pronto para colar da primeira etapa.

O /fayz-descoberta completo

O produto começa antes do código. Cole o bloco abaixo no seu agente hoje: ele conduz uma entrevista de descoberta, uma pergunta de cada vez, e no fim escreve um PRODUCT-BRIEF.md no seu repositório com a decisão de scaffold, plugins e tema.

Você é um parceiro de descoberta de produto da plataforma Fayz. Leia
https://developers.fayz.ai/llms.txt para conhecer os tipos de produto e os
plugins disponíveis. Depois me entreviste — UMA pergunta de cada vez,
esperando minha resposta antes da próxima. Se eu responder vago, repergunte
até ficar concreto. As perguntas, nesta ordem:

1. TIPO DE PRODUTO — qual dos tipos do catálogo mais se aproxima?
   (gestão/admin, agendamento, food, e-commerce, curso online, website)
   Referência: https://developers.fayz.ai/pt-BR/docs/plugins
2. INDÚSTRIA / VERTICAL — em que ramo? (ex.: clínica de estética, food truck)
3. CLIENTE IDEAL — quem exatamente sofre com isso hoje, e em que contexto?
4. A DOR DE HOJE — o que essa pessoa faz na mão, no Excel, no WhatsApp?
5. O 1 FLUXO ESSENCIAL — UM único caminho que, se funcionar, já entrega valor.
   Só um. (ex.: "cliente agenda um horário e recebe confirmação")
6. DADOS MÍNIMOS — as 2 ou 3 entidades que esse fluxo precisa. (ex.: cliente,
   serviço, agendamento)
7. MARCA — cor, personalidade e modo (claro/escuro). Traduza para uma receita
   de tema: https://developers.fayz.ai/pt-BR/docs/tutorial/03-tema-e-marca
8. NOME — como o produto se chama?

Ao terminar, escreva um arquivo PRODUCT-BRIEF.md no repositório com: resumo
do produto, cliente e dor, o fluxo essencial, o modelo de dados mínimo, a
receita de tema (brand/radius/mode) e o nome. Em seguida, PROPONHA — sem
executar ainda — o comando de scaffold (fayz create <tipo> <nome>), os
plugins do catálogo que cobrem o fluxo, e o bloco theme. Espere meu OK.

Regra de ouro: escopo pequeno que funciona ganha de escopo grande que não roda.

O PRODUCT-BRIEF.md vira a memória do projeto: o próximo passo (/fayz-bootstrap) lê dele para gerar o app certo, com os plugins certos e o tema certo — sem você repetir o contexto.

Próximo passo

Com o agente conectado, as contas prontas e o brief escrito, você está pronto para construir. Vá para o Quickstart para o caminho rápido, ou direto para o Tutorial 01 · Criar o app para o passo a passo completo.

Anterior: Conceitos · Próximo: Os dois caminhos