🎯 Objetivo: crear el CLAUDE.md inicial del proyecto.

Crie um arquivo CLAUDE.md na raiz deste projeto. Ele é o system prompt
persistente que você vai ler em toda sessão. Inclua estas seções:

- Papel: você é <ex.: um assistente de automações n8n>.
- Contexto: estou construindo <ex.: workflows de IA para uma agência>.
- Como ajudar: me ajude a planejar, construir, depurar e otimizar.
- Preferências: explicações concisas e diretas; português; descreva o resultado
  e me pergunte quando faltar informação.
- Regras: procure uma ferramenta existente antes de criar uma nova; quando algo
  falhar, diagnostique e aprenda; mantenha este arquivo atualizado; nunca peça
  para eu colar chaves no chat (use o .env).

Mantenha enxuto (poucas centenas de linhas). Depois, me mostre o arquivo.

✅ Cómo verificar: el archivo CLAUDE.md existe en la raíz, con las secciones solicitadas y una extensión razonable. Ábrelo y léelo para confirmar que el rol y el contexto son correctos; si quieres, pide ajustes conversando.

🎯 Objetivo: instalar y conectar un MCP server con la clave en .env.

Instale o MCP server de <ex.: Firecrawl, para busca/scraping na web> neste
projeto, com a configuração no NÍVEL DO PROJETO (não global).

Passos:
1. Use o comando de instalação para Claude Code da documentação oficial:
   <cole aqui o comando de instalação do provedor>
2. Gere/atualize o .mcp.json com a entrada do server e um placeholder de API key.
3. Garanta que a chave seja lida do arquivo .env — NÃO me peça para colar a
   chave aqui no chat. Apenas me diga o nome da variável a preencher no .env.
4. Ao final, faça uma verificação de conexão (status do server).

Se o server não aparecer, me lembre de reiniciar o Claude Code.

✅ Cómo verificar: ejecuta /mcp y confirma que el server aparezca en la lista con estado saludable. La clave está en el .env (que está en el .gitignore), no en el chat ni en el .mcp.json.

🎯 Objetivo: iniciar una build completa con un solo prompt (ejemplo: agente de soporte por correo electrónico).

Entre em plan mode. Quero o resultado a seguir, e você decide a arquitetura.

Objetivo: um agente que lê os e-mails recebidos, identifica perguntas de suporte
técnico e rascunha uma resposta baseada nas nossas políticas. Anexei os documentos
<ex.: politicas.pdf e faq.pdf> na pasta do projeto.

Requisitos:
- Use as informações dos documentos como fonte da verdade; não invente.
- E-mails que não forem de suporte devem ser ignorados.
- Quando não houver resposta nos documentos, NÃO invente: avise que vamos
  pesquisar e retornar.

Antes de construir: leia os documentos, decida como armazená-los e buscá-los
(system prompt vs. vector store, escolha e justifique), me faça as perguntas de
esclarecimento e proponha o plano com a lista de credenciais. Não construa até
eu aprovar.

✅ Cómo verificar: la IA leyó la documentación, propuso una arquitectura justificada (p. ej., un vector store por escalabilidad), preguntó lo que faltaba y enumeró las credenciales. Aprueba solo cuando el plan tenga sentido.

🎯 Objetivo: una plantilla reutilizable que hace que la IA diagnostique y corrija.

Deu erro. Contexto completo:

- Onde: <nó/passo/arquivo, ex.: "trace do passo 3, chamada à API X">
- O que eu esperava: <ex.: "que retornasse a lista de resultados">
- O que aconteceu: <sintoma observado>
- Mensagem de erro (literal):
"""
<cole o erro / trecho do trace EXATAMENTE como apareceu>
"""

Diagnostique a causa raiz, explique POR QUE aconteceu, e aplique a correção
mínima necessária. Não mude mais nada além disso. Depois, me diga exatamente
como reproduzir o teste para confirmar que foi resolvido.

✅ Cómo verificar: la IA señala la causa (p. ej., un formato de respuesta de la API distinto del esperado), aplica una corrección específica y te indica el paso de prueba. Vuelve a ejecutar; si aparece un error nuevo, repite la plantilla con el nuevo mensaje.

🎯 Objetivo: mejoras 1-3 (error/lógica), una por vez.

No workflow existente "<nome exato>", aplique UMA melhoria por vez:

[1] Fallback sem match: quando a busca na base não encontrar resposta, em vez de
    inventar, gere um rascunho educado dizendo que vamos pesquisar e retornar.
    Use um marcador de "encontrou/não encontrou" para decidir o caminho.

[2] Filtro por tempo: processe apenas entradas mais recentes que <ex.: 10 minutos>.

[3] Filtro de automáticos: ignore mensagens automáticas (no-reply, postmaster,
    ausência/out-of-office, newsletters, notificações de entrega). Marque com um
    sinalizador e desvie para "ignorar".

Edite ESTE workflow (não crie outro). Me explique o que muda antes de aplicar.

✅ Cómo verificar: para [1], envía una pregunta fuera de la base y comprueba que aparezca el borrador «vamos a investigar» (no una respuesta inventada). Para [2]/[3], envía exactamente el tipo de entrada que debe detectar el filtro y confirma que se desvíe.

🎯 Objetivo: mejoras 4-6 (calidad de la salida), una por vez.

No workflow existente "<nome exato>", aplique UMA melhoria por vez:

[4] Tom de marca: ajuste o tom das respostas para <ex.: amigável, prestativo,
    informal, entusiasmado>. Atualize tanto a resposta principal quanto o
    rascunho de fallback.

[5] Nome do cliente: extraia o nome da assinatura/fechamento da mensagem
    (padrões como "Abraços, João") e use na saudação; se não houver, use uma
    saudação genérica como "Olá".

[6] Indicador de confiança: classifique a resposta como alta/média/baixa pela
    qualidade do match na base, e anexe um selo discreto (verde/amarelo/vermelho)
    no rascunho, só para revisão interna.

Edite ESTE workflow. Teste cada um com a entrada apropriada.

✅ Cómo verificar: [4] el borrador suena con el tono solicitado; [5] el saludo usa el nombre correcto (y recurre al genérico cuando no hay firma); [6] la etiqueta es coherente con qué tan bien respondió la base.

🎯 Objetivo: crear una skill en el formato oficial (ejemplo: redactar un correo).

Crie uma skill no formato oficial do Claude Code, chamável como slash command.

Nome: <ex.: draft-email>
O que faz: <ex.: escrever um e-mail polido, conciso e sem enrolação>.
Argumentos esperados: <ex.: bullets com os pontos-chave, destinatário, tom>.
Comportamento: se eu invocar sem argumentos, pergunte o que faltar antes de
gerar. Salve a saída em <ex.: temporary/>.

Crie a estrutura .claude/skills/<nome>/SKILL.md com nome, descrição, argumentos
e passos. Depois me diga como invocá-la.

✅ Cómo verificar: existe .claude/skills/<nome>/SKILL.md. Limpia el contexto e invoca el slash command (p. ej., /draft-email) y confirma que solicite los datos de entrada y produzca la salida en el lugar correcto.

🎯 Objetivo: construir una tarea programada sin supervisión (investigación diaria → hoja de cálculo).

Entre em plan mode. Construa uma tarefa AGENDADA que roda sozinha, sem humano
presente, todo dia às <ex.: 8h> (cron).

O que ela faz a cada execução:
1. Pesquisa na web o tópico fixo "<ex.: novidades em automação com IA>"
   (definido no topo do arquivo, fácil de trocar).
2. Sintetiza os achados em um resumo curto.
3. Escreve uma linha na planilha <ex.: "Daily Research", aba Sheet1> com as
   colunas: data, tópico, resumo, fontes, status.

Requisitos para rodar sem supervisão (agentic gap):
- Inputs FIXOS (sem me fazer perguntas no meio da execução).
- Saída ESTRUTURADA e previsível.
- Trate erros sem derrubar a tarefa; se uma etapa falhar, registre e siga,
  gravando ao menos uma linha parcial com status de erro.
- Faça LOG claro em cada passo (mensagens específicas, não "falhou").
- Segredos vêm do ambiente, nunca do código nem do chat.

Antes de construir, planeje, me pergunte o que faltar e liste as credenciais.

✅ Cómo verificar: después del deploy, ejecútalo manualmente (no esperes al horario) y revisa el trace paso a paso. Confirma la fila en la hoja de cálculo y la programación (cron + próxima ejecución) en el panel. Fuerza un fallo y confirma que la tarea no se interrumpa y que registre el estado de error.

🎯 Objetivo: generar un frontend con personalidad (no genérico).

Crie o frontend para <ex.: o app de qualificação de leads>. USE a skill de
design de frontend para que NÃO fique com a cara genérica de site gerado por IA.

Estrutura desejada: <ex.: cabeçalho fixo com logo à esquerda e CTA à direita;
hero com texto grande e direto; um formulário que envia os dados e mostra o
resultado retornado pelo backend>.

A URL do backend e quaisquer chaves devem vir de variáveis de ambiente
(placeholder por enquanto). Me mostre o resultado para eu dar feedback
específico depois.

✅ Cómo verificar: el frontend tiene una identidad visual propia (no el diseño predeterminado de IA), el formulario funciona con un placeholder de backend y no aparece ninguna clave en el código del cliente.

🎯 Objetivo: auditar la seguridad de la app antes de abrirla.

Aja como um especialista em segurança e faça uma auditoria detalhada deste app.
Verifique e me reporte achados + correções para cada item:

- Rotas protegidas: existe rota que dispara o backend sem autenticação?
- Chaves expostas: alguma chave/segredo aparece no código do frontend?
- Variáveis de ambiente: todos os segredos estão em env vars (e fora do git)?
- Isolamento de dados (RLS): um usuário consegue ver dados de outro mesmo com
  um bug no frontend?
- Abuso/custo: alguém com a URL consegue rodar o workflow e gastar meus tokens?

Liste os problemas por severidade e proponha a correção de cada um. Depois,
aplique as correções que eu aprovar.

✅ Cómo verificar: recibes una lista por nivel de gravedad. Ninguna clave en el frontend; las rutas que activan el backend requieren autenticación; los secretos solo en variables de entorno; RLS activa para aislar los datos por usuario. Corrige lo que falle y vuelve a auditar.