Lição 10 de 10: Checklist do Módulo 1

Confira os 10 critérios que separam um setup pronto de um que vai dar problema na primeira semana. A checklist segue a mesma forma das que vão fechar cada módulo daqui pra frente: você descreve, Claude lê seu repo e responde OK/FAIL item por item.

A checklist fica salva no browser. Da próxima vez que você abrir projeto novo a partir do template, abre essa página de novo, marca tudo do zero, e sabe que está pronto.

Como usar a checklist

Cada item embaixo tem 3 partes: o critério, um detalhe explicando por que importa, e (na maioria) um link de remediação que volta pra lição onde aquilo foi ensinado.

Como passar: clica em cada item conforme você confere no seu projeto. O estado fica salvo no navegador.

Como conferir: dois prompts em batelada (5 itens cada) que você cola no Claude. Ele abre os arquivos, roda git ls-files e grep, e responde OK/FAIL pra cada item.

Prompts pra verificação

Vou usar a checklist da lição 10 do Builder OS. Confere os 5 primeiros itens no estado atual deste projeto e me responde com OK / FAIL pra cada um, com 1 linha explicando o porquê:

1. CLAUDE.md foi personalizado (não tem mais "[um produto que faz X para Y]" nem outros placeholders do template).
2. Nenhum secret/key/token aparece em arquivo versionado (`git diff --cached HEAD~5..HEAD | grep -iE "(api[_-]?key|secret|token|password|bearer|sk_live|sk_test)"` retorna vazio).
3. Existe pelo menos 1 arquivo em `.claude/rules/` que NÃO é `bilingual-content.md`, `no-secrets-in-claude-md.md`, ou `plan-lifecycle.md` (ou seja, uma regra custom que eu adicionei).
4. `.claude/settings.json` tem pelo menos 1 entrada no `allow` que eu adicionei na lição 9 (não veio do template original). Lista as entradas e marca quais são novas.
5. `.claude/settings.local.json` está listado no `.gitignore` (`git check-ignore .claude/settings.local.json` retorna o caminho).

E os 5 últimos:

Continua a conferência da checklist. Itens 6-10:

6. Nenhum `.env` real está versionado, só `.env.example` (`git ls-files | grep -E "^\.env" ` deve listar só `.env.example`).
7. A pasta `plans/` existe (mesmo que com só um `.gitkeep`), e `plans/archive/` também.
8. Quando eu abro uma sessão `claude` nova nesse projeto, na primeira mensagem você cita o framework, o fluxo de planos, e os skills (sinal de que o skill `getting-started` está disparando).
9. Os commits do projeto têm mensagens descritivas no estilo Conventional Commits — não `wip`, `init`, `changes`. Roda `git log --oneline -10` e me diz se algum tem mensagem genérica demais.
10. README.md, package.json e CLAUDE.md não têm mais a string "Builder OS Starter" como nome do projeto (`grep -i "builder os starter" README.md package.json CLAUDE.md` deve retornar vazio).

Pra cada item: OK / FAIL + 1 linha de motivo.

Conforme o Claude responder, você marca os itens correspondentes na checklist acima.

Decisão: você está pronto pro Módulo 2?

A regra depende do número de itens marcados:

Quando um item falhar

A função da checklist é capturar as falhas antes que virem dívida, então falhar em algum item faz parte do uso. Cada item tem um link "como corrigir" que volta pra lição onde aquela decisão foi ensinada.

Casos onde você pode deixar pra depois sem culpa:

• Item 3 (regra custom): se você ainda não tem domínio claro do produto, pode adiar até o Módulo 2 ou 3. Volta na lição 7 quando souber o que é uma regra justa pro seu caso.
• Item 8 (skill getting-started disparando): se não está disparando, é bug do template: abre uma issue em jpvss/builder-os. Não bloqueia o Módulo 2.

Casos onde você não segue antes de corrigir:

• Item 2 (secret vazado): rotaciona o secret hoje mesmo. O git history guarda o segredo pra sempre, então remover do arquivo atual não basta.
• Item 5 (settings.local.json no gitignore): se não está, qualquer commit seu pode vazar allowlist pessoal. 30 segundos pra adicionar uma linha em .gitignore.

Reuso desta checklist

A checklist mora no repo do site Builder OS (jpvss/builder-os-web, privado por enquanto). Conforme você criar projetos futuros a partir do template, abre essa página de novo, marca tudo do zero, repete o ciclo. O audit ID dos itens é compartilhado entre todos os projetos do template, então você configura uma vez e vale pra todos.

Os módulos 2, 4 e 5 têm checklists próprias com a mesma forma. Esta é a primeira de várias.

Takeaways do M1

• Claude Code é um agente que lê e edita o seu repo e roda comandos com a sua aprovação. Toda a configuração mora em arquivos versionados (CLAUDE.md, .claude/rules/, .claude/skills/, .claude/settings.json), e roda igual em qualquer superfície (terminal, Cursor/VS Code, app desktop).
• CLAUDE.md é o briefing do agente. Com ele personalizado, o Claude responde com contexto do seu produto; com os placeholders do template ainda no lugar, ele responde sem saber o que você está construindo.
• Rules e skills moldam o comportamento default. Uma rule é um fato sempre-ligado que vale no caminho onde mora (path-scoped); uma skill é um procedimento que carrega quando o description: reconhece o contexto.
• settings.json é o modelo de permissões. Allowlist apertado evita prompts repetidos sem abrir a porta pra comandos destrutivos.

Você terminou quando

Você marcou 7 ou mais itens da checklist e tem clareza sobre quais (se algum) precisa fechar antes do Módulo 2.