Claude + Obsidian→ Os pilares da produtividade.

Crie ou atualize ~/.claude/settings.json (sem apagar o que já existe) com:
- "model": "opus" (ou "fable", se a conta tiver) e "outputStyle": "Concise"
- permissions.deny: Read(./.env), Read(./.env.*), Bash(rm -rf *), Bash(git push --force*)
- permissions.ask: Bash(git push*)
- env: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Mostre o arquivo final, valide o JSON e me diga como conferir com /config e /permissions.

Depois leia este projeto e me diga em 10 linhas: o que ele faz, como rodar e testar,
e o que falta para você trabalhar bem (CLAUDE.md, .env.example, testes, .brain).
Não altere nada ainda.

Organize os segredos deste projeto:
1. Crie .env.example por app (apps/api e apps/web) com toda variável que o código usa, sem valores.
2. Garanta no .gitignore: .env, .env.*, !.env.example, .claude/settings.local.json.
   Se algum .env já foi commitado, me avise e mostre como remover do histórico.
3. Faça a API ler pelo ambiente (dotenv só em desenvolvimento) e falhar no boot se faltar
   variável obrigatória.
4. Audite o front: liste toda VITE_* e diga se alguma é segredo; mova chamadas a serviços
   externos com chave para a API (front → nossa API → serviço externo).
5. Escreva .brain/seguranca.md com as regras: segredos só na API; front só VITE_ públicas;
   sessão em cookie httpOnly + Secure + SameSite=Lax; validação zod na API; rate limit no login;
   CORS só para o domínio do front; logs sem senha, token, CPF ou cartão; erro sem stack trace.
Não leia o conteúdo do meu .env. Me mostre o que mudou.

Configure o cérebro deste projeto. Primeiro me pergunte: (A) por projeto, ./.brain versionado
no git, ou (B) central, vault em [C:\Cerebro ou ~/Cerebro]/Projetos/[NOME]/brain com link
simbólico ./.brain (e ./.brain no .gitignore)? Depois:
1. Crie a estrutura: README.md (índice), arquitetura.md, padroes.md, api.md, banco.md, testes.md,
   local.md, ui/ (tokens.css, base.css, componentes/), decisoes/, planos/, diario/.
   Ignore .brain/.obsidian/workspace* no git.
2. Se for B, crie também no vault: 00-Inbox, Projetos, Areas, Recursos, Arquivo, Templates
   (projeto, decisao-adr, diario, reuniao) com frontmatter tags/projeto/data/status, e um CLAUDE.md
   na raiz do vault com as regras de escrita: Markdown do Obsidian, [[wikilinks]], callouts,
   um assunto por nota, notas em português e código em inglês, nunca apagar (mover para Arquivo/).
3. Crie o CLAUDE.md do projeto: o que faz e para quem; stack (monorepo pnpm · apps/web React+Vite+TS
   · apps/api Node+TS · Postgres · R2); comandos pnpm dev/test/lint/typecheck/build; regra do cérebro
   (procurar antes de criar; ADR em decisoes/; diário ao fim da tarefa); regras (100% modular, UI só
   com .brain/ui, segredos só na API, TDD, commits tipo(escopo): descrição); fluxo brainstorming →
   writing-plans → executing-plans → revisor + qa → verification-before-completion.
4. Instale as skills do Obsidian: /plugin marketplace add kepano/obsidian-skills e
   /plugin install obsidian@obsidian-skills.
Se o projeto já existe, documente módulos, rotas, banco e componentes duplicados sem mudar código.
Me mostre a árvore final.

Vamos iniciar o projeto [NOME]. Antes de qualquer código, me entreviste, UMA pergunta
por vez, e só avance quando eu responder:
1. O que o sistema faz e para quem? Qual problema resolve hoje e como é feito sem ele?
2. Fluxos principais (3 a 5), telas, o que é MVP e o que fica para depois.
3. Precisa de login? Quais papéis? Há dados sensíveis (pessoais, pagamento, saúde)?
4. Integrações (Slack, Drive, Calendar, e-mail, pagamento), arquivos (R2), relatórios.
5. Hospedagem (Railway ou Cloudflare), domínio, prazo, o que não pode falhar.

Stack fixa: monorepo pnpm · apps/web (React + Vite + TS) · apps/api (Node + TS) · Postgres · R2.
Regras: 100% modular; UI só com .brain/ui; segredos só na API (front só VITE_* públicas);
sessão em cookie httpOnly; validação zod na API; TDD; commits tipo(escopo): descrição.
Boas práticas obrigatórias: nenhum token, chave ou client_secret em requisição do front;
o front chama só a nossa API; CORS restrito; rate limit no login; logs sem dado pessoal.

Ao terminar a entrevista: escreva .brain/produto.md (problema, usuários, fluxos, MVP, fora do
escopo) e o plano do MVP em .brain/planos/mvp.md. Me mostre para aprovar.
Nada de código antes da aprovação.

Monte o monorepo pnpm de [NOME] (crie a pasta e o git init se não existirem):
- pnpm-workspace.yaml com apps/* e packages/*
- apps/web: React + Vite + TS (só VITE_* públicas), proxy /api para a API em desenvolvimento
- apps/api: Fastify + TS, rota GET /health, zod, dotenv, CORS só para o front,
  porta por process.env.PORT
- packages/ui (componentes .brain/ui em React, prefixo k-), packages/types (contratos zod
  compartilhados entre web e api), packages/config (eslint, prettier, tsconfig base)
- scripts na raiz: dev (web + api com concurrently), test, lint, typecheck, build
- .env.example por app, .gitignore, README de 10 linhas, .claude/ e .brain/ na raiz
Rode pnpm install e pnpm dev e cole a saída. Nenhuma feature ainda.

Com base em .brain/produto.md, gere o .brain inicial de [NOME]:
- arquitetura.md: diagrama Mermaid web ↔ api ↔ postgres ↔ r2, módulos por domínio
  (apps/api/src/modules/[dominio]) e fronteiras, sem import circular
- pastas.md: onde cada coisa vive no monorepo
- auth.md (padrão da casa): e-mail + senha com argon2 [ou OAuth Google]; sessão em cookie httpOnly,
  Secure, SameSite=Lax, 7 dias, renovada na API; papéis admin · [PAPEL-2] checados por middleware
  em cada rota (botão escondido não é permissão); o front só sabe "estou logado e sou X" via GET /me;
  senha mínima 10, rate limit 5/min no login, reset por link de 15 min; excluir a conta apaga tudo (LGPD)
- seguranca.md: segredos só na API, front só VITE_, validação zod, CORS restrito, logs sem dado pessoal
- banco.md com o schema inicial, testes.md (unitário, integração, E2E), local.md (rodar em 5 min),
  deploy.md (Railway ou Cloudflare)
Arquivos curtos e objetivos. Me mostre antes de criar qualquer código.

Deixe as skills deste projeto funcionando, de uma vez:
1. Instale: /plugin install superpowers@claude-plugins-official · /plugin marketplace add anthropics/skills
   e /plugin install example-skills@anthropic-agent-skills (frontend-design, webapp-testing, mcp-builder)
   · /plugin install security-guidance@claude-plugins-official · /plugin install typescript-lsp@claude-plugins-official
   · /plugin marketplace add kepano/obsidian-skills e /plugin install obsidian@obsidian-skills.
2. Crie as nossas quatro em .claude/skills/[nome]/SKILL.md (frontmatter name + description, corpo curto):
   - qa-testes: critérios de aceite do plano (ou escreva 3 a 7 e peça OK); unitário (regras + bordas),
     integração (rota + banco de teste), E2E do fluxo principal em 375 e 1280 px; rode testes, lint,
     typecheck e build e cole só as falhas; relatório .brain/testes/QA-data-feature.md
     (critério | ✅/❌ | evidência); bugs com passos para reproduzir; proibido "deve funcionar".
   - ui-ux: antes, leia .brain/ui/tokens.css e componentes/ e só use o que está lá; checklist: uma ação
     primária por tela, estados carregando/vazio/erro/sucesso, 375/768/1280 px, toque 44 px, contraste AA,
     foco visível, teclado, aria, botões com verbo, erros dizem como resolver; entrega: ajustes por
     impacto + componentes que faltaram (crie via design-system).
   - design-system: confirme que não existe em .brain/ui/componentes (ou estenda com variante); HTML
     semântico + CSS com prefixo k- usando só tokens.css + base.css (adeque as cores ao design do sistema
     via tokens); responsivo, teclado, aria, estados hover/focus/disabled/loading; documente no topo
     (quando usar, variantes, exemplo) e atualize INVENTARIO.md; substitua as cópias e rode qa-testes.
   - otimizacao: meça antes (profiler, EXPLAIN ANALYZE, Lighthouse) → 3 gargalos por tempo → corrija um
     por vez (índice, N+1, cache, paginação, lazy, bundle) → benchmark antes/depois → ADR; auditoria
     (dependências circulares, módulos com 2 responsabilidades, UI duplicada, configs espalhadas) em
     .brain/planos/otimizacao-data.md (problema | impacto | esforço); ganho < 10% não vale.
3. Copie as quatro para ~/.claude/skills/ (globais) e confirme com /skills.
4. Leia .brain/produto.md e arquitetura.md e diga que skill ainda falta para este projeto
   (stack, integrações, deploy); se existir em marketplace, instale; se não, crie.
5. Adicione ao CLAUDE.md: "antes de responder, verifique se existe skill para o pedido e diga
   'Usando: [skill]'. Para features: brainstorming → writing-plans → executing-plans → verification".
Me mostre a lista final com /skills.

Crie de uma vez, em .claude/agents/, os cinco agentes abaixo. Cada arquivo com frontmatter
(name, description, tools, model) e instruções curtas. Modelo de todos: opus (ou fable, se a conta
tiver). Ao final rode ls .claude/agents e me mostre.

revisor · opus · Read, Grep, Glob, Bash
  Leia .brain/padroes.md. Em git diff main...HEAD: bugs e bordas; segurança (entrada, segredos,
  autorização); algo já existe no .brain?; testes faltando. Saída por severidade com arquivo:linha
  e correção. Não altera código. Crítico bloqueia.
qa · opus · Bash, Read, Grep, Glob
  Roda testes, lint, typecheck, build; cola só falhas (máx. 60 linhas). Cada critério ✅/❌ com
  comando + saída real. Nunca "passou" sem saída.
arquiteto · opus · Read, Grep, Glob
  Lê o .brain inteiro. Propõe a solução mais simples que respeita a modularização: módulos,
  contratos, o que é compartilhado, riscos. ADR + Mermaid. Não implementa.
documentador · opus · Read, Write, Edit, Grep, Glob, Bash
  Compara código e .brain; atualiza só o que mudou (arquitetura, api, banco, componentes);
  escreve o diário de hoje: o que mudou, por quê, como testar, pendências. Não inventa.
seguranca · opus · Read, Grep, Glob, Bash
  OWASP Top 10, segredos no repo (git log incluído), npm audit, autorização por rota, validação de
  entrada, o que vaza pro front (VITE_), CORS, cookies, logs sensíveis. Achados com prova. Não altera.

Depois adicione no CLAUDE.md: "fim de tarefa = revisor (corrija os críticos) → qa → documentador ·
release = seguranca" e me diga como chamar cada um (/agents).

Crie os hooks deste projeto em .claude/hooks/ (bash, chmod +x) e registre em .claude/settings.json:
- format.sh (PostToolUse, matcher Edit|Write): lê tool_input.file_path do JSON no stdin (jq) e
  formata: prettier para ts/tsx/js/jsx/css/md/json, black para py. Sai em silêncio se não houver arquivo.
- guard.sh (PreToolUse, matcher Bash): lê tool_input.command e bloqueia com exit 2 (mensagem
  "Bloqueado: …" no stderr) rm -rf /, git push --force, git reset --hard, DROP TABLE/DATABASE
  e qualquer leitura de .env (cat, type, Get-Content).
- diario.sh (Stop): garante .brain/diario/AAAA-MM-DD.md com frontmatter (tags: [diario], data)
  e anexa hora + git diff --stat.
Stack: [STACK]. Me diga como testar cada um; eu confiro com /hooks.

Configure as integrações deste projeto:
1. Plugins oficiais: pergunte quais usamos e instale (/plugin install github@claude-plugins-official,
   atlassian para Jira, figma, sentry, slack, supabase, linear, notion, vercel).
2. Slack, Google Drive e Google Calendar: me guie para ligar em claude.ai → Configurações → Conectores
   e autenticar aqui com /mcp (aparecem como "claude.ai Slack", "claude.ai Google Drive"…).
   Teste listando meus eventos de amanhã.
3. Crie .mcp.json no projeto para servidores próprios com tokens por ${VARIAVEL} (nunca o valor)
   e mostre como adicionar um servidor remoto com claude mcp add --transport http.
4. Use mcp-builder e crie um MCP em mcp/ para a nossa API [NOME] com as ferramentas listar_x,
   criar_x e status_x; token via env; testes; registre em .mcp.json.
5. Fluxo diário: ao fechar tarefa, poste no Slack #[CANAL] o resumo do diário (5 linhas); toda
   segunda crie no Calendar o evento "Review [NOME]" (30 min) e salve o plano da semana em
   Drive/[PASTA]/planos/. Antes de enviar qualquer coisa para fora, me mostre o texto.
Documente tudo em .brain/integracoes.md e desligue em /mcp o que não usamos.

Ligue o Postgres em apps/api com segurança:
1. Local: docker-compose.yml com postgres:16 (usuário, senha e banco de desenvolvimento), volume
   persistente e script db:up. DATABASE_URL de dev no .env.example (sem senha real).
2. Drizzle: schema em src/db/schema.ts, migrations em drizzle/, conexão por DATABASE_URL com pool
   e SSL (sslmode=require) fora do local; scripts db:migrate, db:seed e db:studio.
3. Só queries parametrizadas (nunca string concatenada); banco de teste separado para os testes
   de integração.
4. Produção (Railway → New → Database → PostgreSQL): escreva em .brain/banco.md o SQL que roda
   uma vez: CREATE ROLE app LOGIN PASSWORD '…'; GRANT CONNECT ON DATABASE; GRANT USAGE, CREATE ON
   SCHEMA public; ALTER DEFAULT PRIVILEGES … GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app.
   A API usa o usuário app, nunca o postgres.
5. Backup diário e restauração, também em .brain/banco.md.
Nunca leia meu .env. Rode as migrations no banco local e cole a saída.

Crie o módulo storage em apps/api usando o Cloudflare R2:
- cliente @aws-sdk/client-s3 com region "auto" e endpoint https://[R2_ACCOUNT_ID].r2.cloudflarestorage.com;
  credenciais R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY e R2_BUCKET só no .env da API
  (adicione ao .env.example)
- POST /uploads/presign: valida tipo e tamanho (PDF, PNG, JPG até 10 MB), gera a chave
  [pasta]/[uuid].[ext] e devolve URL pré-assinada de PUT com 5 min (@aws-sdk/s3-request-presigner)
- GET /files/:id: URL pré-assinada de leitura de 15 min, só para quem tem permissão
- registro do arquivo no Postgres (dono, nome, tamanho, tipo, chave)
- no front, componente de upload de .brain/ui que usa a URL, nunca as chaves; bucket privado
Documente em .brain/integracoes.md o passo a passo do painel (Create bucket → Manage R2 API Tokens
→ Object Read & Write só neste bucket → copiar as chaves e o Account ID).

Prepare o deploy de [NOME] no Railway:
1. apps/api ouvindo em process.env.PORT, GET /health, CORS só para o domínio do web; build e start
   funcionando a partir da raiz: pnpm install --frozen-lockfile && pnpm --filter api build /
   pnpm --filter api start.
2. apps/web: build pnpm --filter web build e start pnpm --filter web preview --host 0.0.0.0
   --port $PORT; VITE_API_URL da produção.
3. Escreva .brain/deploy.md com o passo a passo: npm i -g @railway/cli, railway login, railway init,
   railway add --database postgres, railway link, um serviço por app com Root Directory apps/api e
   apps/web, DATABASE_URL=${{Postgres.DATABASE_URL}}, variáveis do .env.example (sem valores),
   railway domain, healthcheck /health e deploy pelo GitHub na main.
4. Checklist de release: migrations, variáveis conferidas, smoke test no domínio.
Nada de segredo no repositório.

Publique [NOME] na Cloudflare:
1. Web no Pages: npm i -g wrangler, wrangler login, build pnpm --filter web build,
   wrangler pages deploy apps/web/dist --project-name [NOME]; ou Workers & Pages → Connect to Git
   (build pnpm --filter web build, output apps/web/dist, VITE_API_URL de produção). Crie o script deploy:web.
2. Domínio [DOMINIO]: DNS na Cloudflare, SSL automático, www → raiz; api.[DOMINIO] como CNAME
   para a API no Railway com proxy ligado.
3. Se a API for para Workers: adapte apps/api para Hono (roda em Node e em Workers), wrangler.toml
   (name, main, compatibility_date), segredos via wrangler secret put JWT_SECRET e DATABASE_URL
   (Hyperdrive para o Postgres), wrangler deploy.
Documente em .brain/deploy.md e me diga quando escolher Railway ou Workers para a API.

Deixe [NOME] testável localmente:
1. Ambiente: docker-compose com [POSTGRES/REDIS], scripts dev, test, lint, typecheck, db:migrate,
   db:seed, e .brain/local.md "rodando em 5 minutos". Rode do zero e cole a saída.
2. scripts/smoke.sh: sobe a app, chama [ROTA-1], [ROTA-2], [ROTA-3], falha se alguma não
   responder 200 em 5 s, derruba a app. Rode e cole.
3. No navegador (claude --chrome): abra http://localhost:[PORTA], percorra [LOGIN] → [DASHBOARD]
   → [AÇÃO], screenshot de cada tela, erros de console e o que quebra em 375 px.
   Lista de bugs por severidade. Não corrija ainda.

Configure o fluxo de Git de [NOME]:
1. Se ainda não existe: git init com .gitignore do monorepo (node_modules, dist, .env, .env.*,
   !.env.example, .claude/settings.local.json), commit "chore: bootstrap" e
   gh repo create [ORG/NOME] --private --source=. --push.
2. Instale /plugin install commit-commands@claude-plugins-official e
   /plugin install github@claude-plugins-official; rode /install-github-app para revisão automática nos PRs.
3. .github/workflows/ci.yml: lint, typecheck, testes e build em cada PR; proteja a main
   (PR obrigatório, CI verde).
4. Regra para toda tarefa daqui em diante: branch feat/[nome], commits pequenos tipo(escopo): descrição
   com testes e lint antes de cada um, PR com gh pr create (resumo, como testar, checklist) e me
   mostrar o link. Anote isso no CLAUDE.md.

Quero: [O QUE]. Contexto: [MÓDULO / TELA]. Pronto quando: [COMO EU SEI].
1. Use brainstorming, uma pergunta por vez. Consulte o .brain antes de propor: reutilize o que existe.
2. Quando eu aprovar, writing-plans e salve em .brain/planos/[NOME].md.
3. Execute com executing-plans em lotes de 3 tarefas; UI só com .brain/ui (se faltar, design-system
   primeiro); a cada lote rode o subagent revisor e corrija os críticos.
4. No fim: qa-testes com os critérios do plano (unitário, integração, E2E em 375 e 1280 px, relatório
   com evidência), verification-before-completion, documentador (diário + .brain) e PR com gh pr create.
Me entregue: link do PR, pendências e evidência dos testes. Nada de código antes do plano aprovado.

Tela [NOME] para [QUEM] fazer [TAREFA]. Use ui-ux.
Opção A: /design com este brief. Opção B: frontend-design no código.
Só componentes de .brain/ui; se faltar, design-system antes (prefixo k-, só tokens, adeque as cores
ao design do sistema via tokens.css). Uma ação primária por tela; estados carregando/vazio/erro/sucesso;
screenshot em 375 e 1280 px.
Depois audite todas as telas: liste cada botão, dropdown, tabela e modal que não vem de .brain/ui
e unifique por PR (uma família por vez) com qa-testes no fim.

Bug: [ERRO]. Esperado: [X]. Reproduzir: [PASSOS].
Não corrija ainda: reproduza, levante 3 hipóteses, teste a mais provável, faça a correção mínima
+ teste de regressão, rode a suíte e me mostre o diff.

Se você não seguiu [REGRA]: releia CLAUDE.md e .brain/padroes.md, diga o que faltou e refaça.
Eu confiro com /context, /skills, /hooks, /mcp e /usage.

Use otimizacao em [ROTA/TELA/JOB]. Hoje: [TEMPO]. Meta: [META].
Meça primeiro (profiler, EXPLAIN ANALYZE, Lighthouse), liste os 3 gargalos por tempo e corrija um
por vez (índice, N+1, cache, paginação, lazy, bundle) com benchmark antes/depois e ADR.
Depois audite o sistema inteiro: dependências circulares, módulos com duas responsabilidades,
UI duplicada, configs espalhadas → .brain/planos/otimizacao-[DATA].md priorizado
(problema | impacto | esforço). Ganho < 10% não vale a complexidade.