Checklist de auditoria inicial de repositório com Claude Code

A primeira sessão do Claude Code em um repositório existente não deve começar editando. Deve começar com um mapa. O agente lê rápido, mas velocidade só ajuda quando entradas, áreas protegidas, comandos de prova e caminhos de negócio estão claros.

A intenção é simples: usar Claude Code em um código real sem perder controle. O objetivo ainda não é criar feature, e sim tornar visíveis escopo, risco, verificação e CTA de receita em 20 minutos.

Leituras relacionadas: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-harness-lite-workflow.

Por que este padrão vem antes da primeira edição

Claude Code funciona melhor quando a tarefa tem uma fronteira clara. Uma boa fronteira nomeia arquivos que pode ler, arquivos que pode editar, operações proibidas e a prova que encerra o trabalho. Sem isso, um prompt pequeno de iniciante pode virar reescrita ampla, e uma mudança de conteúdo pode quebrar PDF gratuito, Gumroad ou consultoria.

Esse padrão também ajuda receita porque conecta prova técnica com prova para o leitor. Uma página que builda localmente mas envia o leitor ao produto errado não está pronta. Ao registrar scope, comando, URL pública e CTA, amanhã você melhora por evidência, não por memória.

Fluxo prático

1. Ler primeiro apenas README, package.json e entradas de rota
2. Marcar generated, billing, auth, migrations e .env como áreas protegidas
3. Limitar a primeira edição a três arquivos ou menos
4. Escolher um comando de prova antes de qualquer patch
5. Em conteúdo ou landing page, auditar PDF gratuito, Gumroad e consultoria

Situação	Movimento seguro	Prova
Site Astro de conteúdo	Antes de criar um artigo, inspecione collection, slug, heroImage e padrão de CTA. Corpo e rota paga entram na auditoria.	build, diff, URL
Dashboard React	Para um defeito pequeno de layout, fique no componente, CSS e screenshot. Auth e billing ficam protegidos.	screenshot, test
Repositório API	Comece lendo rota e comando de teste. Migrations e secrets ficam fora da primeira tarefa.	log, command, handoff

A primeira passada deve ser curta. A auditoria deve gerar uma decisão, não um relatório gigante. Se depois de 20 minutos a decisão ainda está confusa, o passo seguro é ler mais um arquivo, não começar a editar.

Prompt e código copiáveis

Audite este repositório antes da primeira edição. Não edite ainda. Retorne arquivos de entrada, áreas protegidas, arquivos seguros, menor comando de prova e checks de URL pública e CTA.

const audit = {
  repo: "customer-portal",
  intent: "first safe Claude Code session",
  scope: ["README.md", "package.json", "src/routes"],
  protected: [".env", "billing/", "migrations/"],
  proof: ["npm.cmd run build", "git diff --stat"],
};

export function readyForFirstEdit(report) {
  return report.scope.length > 0 &&
    report.protected.length > 0 &&
    report.proof.some((command) => command.includes("build"));
}

console.log(readyForFirstEdit(audit));

O código é pequeno de propósito. Ele transforma uma ideia operacional em objeto verificável: existe scope, existem áreas protegidas e existe ao menos um comando de prova. Você pode adaptar para publicação, app, debug ou handoff.

Três exemplos reais

Site Astro de conteúdo

Antes de criar um artigo, inspecione collection, slug, heroImage e padrão de CTA. Corpo e rota paga entram na auditoria.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Dashboard React

Para um defeito pequeno de layout, fique no componente, CSS e screenshot. Auth e billing ficam protegidos.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Repositório API

Comece lendo rota e comando de teste. Migrations e secrets ficam fora da primeira tarefa.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Falhas que devem ser evitadas

• Pedir para corrigir tudo mistura auditoria e implementação.
• Build local não basta se URL pública ou CTA apontam para o lugar errado.
• Sem áreas protegidas, uma edição útil pode virar incidente.

Outra falha sutil é drift de localização. O artigo em inglês pode explicar o produto correto enquanto outro idioma mantém CTA antigo. Por isso a verificação pública precisa ler h1, abertura e CTA em cada idioma, não só frontmatter lang.

Como levar o leitor ao PDF, Gumroad e consultoria

Se o leitor ainda precisa dominar comandos, envie para o cheatsheet gratuito. Se o bloqueio está em setup, permissões, CLAUDE.md, hooks, MCP ou CI/CD, o melhor próximo passo pago é o Setup Guide. Para prompts repetidos de review, debugging e refactor, use 50 Prompt Templates. Para rollout de equipe, desenho de workflow ou rota de receita, use a consultoria. Para comparar opções, veja products.

Não empurre todo leitor direto para produto pago. Iniciantes geralmente precisam primeiro de um PDF simples. Quem repete prompts está mais perto de templates. Quem trava em permissões, CLAUDE.md, hooks, MCP ou CI/CD está mais perto do Setup Guide. Times com dúvidas de processo estão mais perto da consultoria.

O que verificar antes e depois de publicar

Verificar este artigo significa conferir h1, abertura do texto, heroImage, links internos, links Gumroad e caminho de consultoria. HTTP 200 não basta se o CTA aponta para a próxima ação errada.

Na publicação multilíngue, verifique japonês, inglês, chinês, coreano, espanhol, francês, alemão, português, hindi e indonésio separadamente. O slug pode bater e o corpo ainda estar antigo. Screenshots mobile mostram abertura e CTA juntos.

Métricas para observar depois

Observe inícios de PDF, cliques Gumroad, visitas a products, visitas a training, origem de busca, países e taxa de clique de artigo para CTA. Se PV sobe sem Gumroad, falta ajuste de produto. Se consulta sobe a partir de artigo técnico, o leitor provavelmente precisa de desenho de workflow.