Claude Code CLAUDE.md Permission Recipe: reduzir contexto repetido e acesso arriscado

Muitas falhas com Claude Code não vêm de um modelo fraco. Elas surgem porque as regras do projeto mudam a cada sessão. Um CLAUDE.md claro com permission recipe reduz contexto repetido, edições arriscadas e falta de verificação.

Este artigo mostra a primeira receita para iniciantes. O objetivo não é congelar o agente, mas separar read-only, ask-before, never-touch e proof commands.

Leituras relacionadas: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

Por que este padrão funciona

CLAUDE.md não é memória, é contrato de trabalho. Quando nomeia comandos de prova, diretórios protegidos e caminhos de PDF, Gumroad e consultoria, ajuda desenvolvimento e publicação.

A permission recipe transforma contrato em comportamento. Separar áreas reduz a chance de Claude Code avançar para ações perigosas.

Fluxo prático

1. Escreva objetivo, qualidade, comandos de prova e caminhos de receita no CLAUDE.md
2. Divida arquivos em read-only, ask-before e never-touch
3. Nomeie proof commands que podem rodar sem aprovação extra
4. Deixe deploy, deleção e ações irreversíveis com confirmação humana
5. Após publicar, tire captura de h1, início, CTA e links Gumroad

Situação	Ação segura	Prova
Site solo	Permitir corpo de artigo; formulários e API ficam ask-before	build e URL pública
PR de equipe	Permitir review de diff; parar antes de push ou deploy	PR diff
Página de receita	Proteger links de produto, preços e formulários	checagem de clique

Prompt e código para copiar

Crie uma CLAUDE.md permission recipe para este projeto. Inclua read-only, ask-before, never-touch, auto proof commands, checagens de URL pública e regras para proteger PDF grátis, produtos Gumroad e consultoria.

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

O exemplo não é arquivo real de configuração. Ele modela a decisão. Ajuste para permissões, CI e deploy da equipe.

Três exemplos reais

Primeiro setup

Deixe ler README e package.json, depois crie CLAUDE.md antes da primeira edição. Limite a primeira edição a um arquivo.

Artigo multilíngue

Não confie só em slug e frontmatter. Inclua regra de início do texto e CTA no idioma correto, com captura.

Antes da consultoria

Leve tabela de permissões, áreas bloqueadas e comandos de prova. A sessão vira implementação.

Falhas a evitar

• Escrever apenas princípios no CLAUDE.md sem áreas bloqueadas concretas.
• Permitir deploy ou deleção por conveniência.
• Tratar links de produto e formulários como conteúdo comum.

Regras longas demais são ignoradas. Comece curto e adicione uma regra após cada falha real.

Como ligar PDF grátis, Gumroad e consultoria

Se o básico ainda é instável, use o cheatsheet grátis. Para CLAUDE.md, permissions, hooks, MCP e CI, o Setup Guide é o caminho pago mais rápido.

Para padronizar review e debug, use 50 Prompt Templates. Para regras de equipe ou receita, use consultoria. Compare em products.

O que verificar antes e depois de publicar

Antes de publicar, veja se artigo e novas regras não contradizem a recipe. Depois, em mobile, confira h1, início, CTA e links de produto em cada idioma.

Métricas para acompanhar

Observe cliques no Setup Guide, PDF starts, visitas à consultoria e artigos de permission. Se consultoria sobe, leitores querem design operacional.

Revisão operacional de 30 minutos

Quando o permission recipe do CLAUDE.md entra no trabalho real, a revisão mais útil acontece no dia seguinte. Leia o log e anote escopo permitido, arquivos alterados, comandos de prova e páginas públicas inspecionadas. Não escreva só “verificado”; registre h1 mobile, início do texto, área CTA, link Gumroad e caminho de consultoria.

Separe confiança do operador e comportamento do leitor. Do lado operacional, confirme áreas bloqueadas, build, mesmo slug público e ausência de corpo em inglês nas páginas traduzidas. Do lado do leitor, confirme o próximo passo: PDF grátis para comandos, Gumroad para gargalo repetível e consultoria para desenho de workflow.

Transforme a revisão em uma regra futura. Não adicione dez regras por problema. Adicione uma: perguntar antes de mexer em layout, clicar cada URL Gumroad em produção ou capturar o início do texto em cada idioma. Regra pequena executada todo dia vale mais que política longa.