Lição 1 de 6: Inventário do .claude/

M5 inteiro é sobre organizar o que você acumulou nos 4 módulos anteriores: as skills, rules e settings que foram parar no .claude/ ao longo de M1–M4.

Por que inventário antes de empacotar

Você passou 4 módulos com o .claude/ evoluindo: rules adicionadas, skills criadas (e algumas adiadas pela regra da 3ª repetição), settings ajustados. Antes de tentar compor isso num pacote reutilizável, mapeie o que tem.

A tentação no M5 é "vamos empacotar tudo num bundle reutilizável." Mas "tudo" inclui o que você nunca usou. Empacotar morto contamina o pacote: quem instala recebe arquivos que só ocupam espaço.

Inventário primeiro separa 3 buckets:

1. CanônicoBucket do inventário: arquivo que veio do Starter intacto, sem você modificar. Não entra no Personal Pack, porque chega de novo a cada projeto direto do Starter.: veio do starter intacto (getting-started, plan-then-work, etc.). Não vai pro Personal Pack; vai do starter direto pra todo projeto novo.
2. PessoalBucket do inventário: arquivo que você adicionou ou modificou. É o material que vira o Personal Pack, empacotado como plugin na L05.: você adicionou ou modificou. Vira o Personal Pack na L05 (empacotado como plugin do Claude Code).
3. MortoBucket do inventário: arquivo que você criou e nunca mais usou. Ruído pro próximo Claude; deleta ou move pra docs/maybe-skills.md se ainda houver dúvida.: criou e nunca usou. Deleta agora, ou move pra docs/maybe-skills.md se ambíguo (revisão na próxima 3ª repetição).

Passo 1 — Liste o .claude/ atual

Cole no Claude:

Lista pra mim, em árvore, tudo que existe em `.claude/` do projeto atual:

- Arquivos diretos em `.claude/`
- Subpastas: `rules/`, `skills/`, e qualquer outra
- Cada arquivo: path + tamanho em linhas + data da última modificação

Formato: `tree`-like com tamanho ao lado. Pra cada skill, mostra também a primeira frase do SKILL.md (o "when to use") pra eu reconhecer.

Aprove. Vai sair um mapa. Anota mentalmente o que você reconhece (skills do Starter que você criou junto) e o que você criou depois.

Passo 2 — Baixe o .claude/ do Starter atualizado

Pra comparar, você precisa do estado atual do Starter, não da versão que você clonou quando começou o curso. Ele pode ter evoluído nas lições anteriores.

Quero comparar meu `.claude/` com o do starter upstream. Roda:

1. `git remote -v`: confirma se já tem remote pro upstream do Starter. Se não tem, sugere o comando `git remote add upstream https://github.com/jpvss/builder-os.git` (ou repo correto). Não roda ainda, só mostra.
2. Se tem (ou depois de adicionar), `git fetch upstream main`
3. Lista os arquivos de `.claude/` na branch `upstream/main` (pode usar `git ls-tree upstream/main -- .claude/`)

Mostra o output.

Aprove. Agora você tem 2 listas: a sua e a do upstream.

Passo 3 — Compara os dois e classifica em 3 buckets

Compara meu `.claude/` com o do upstream e classifica cada arquivo em 1 dos 3 buckets:

1. **canônico**: existe no upstream + meu arquivo é igual (sem mudanças) ou quase igual (1-3 linhas diferentes). Lista nome.
2. **pessoal**: não existe no upstream (criado por mim) OU existe mas eu modifiquei substancialmente. Lista nome + 1 linha do "porquê" se conseguir inferir.
3. **morto**: meu, mas grep no `src/` e em `plans/` mostra zero ocorrências de uso/menção. Suspeita de irrelevância.

Para skills especificamente: olha quando foi a última modificação. Se tem skill criada há 30+ dias com 0 uso no `git log`, sinal forte de morta.

Mostra os 3 buckets como listas.

Aprove. Resultado típico (pra quem fez M1–M4 honestamente):

• Canônico: 5 skills do Starter (getting-started, plan-then-work, commit-and-pr, nextjs-react, ui-design)
• Pessoal: 1-3 rules adicionadas, talvez 1 skill (se a 3ª repetição justificou no M3/M4)
• Morto: idealmente 0, mas pode ter 1-2 skills que pareceram boa ideia e não pegaram

Se o seu bucket "pessoal" tem 0 itens, você ainda não personalizou muito nos módulos anteriores. Isso é informação útil: a L02 (hooks) e a L05 (plugin) vão adicionar substância.

Se o bucket "morto" tem 5+ itens, sinal de que a regra da 3ª repetição não foi respeitada. Vai precisar de limpeza antes de compor.

Passo 4 — Documente o inventário

Cria `docs/personal-pack-inventory.md` com:

# Personal Pack Inventory

Data: <hoje>
Total de arquivos em `.claude/`: <N>

## Canônico (do Starter, não modificado)
- <lista>

## Pessoal (criado ou modificado por mim)
- <lista com 1 linha de razão por item>

## Morto (criado, sem uso detectado)
- <lista>
- Decisão pra cada um: [deletar agora | mover pra `docs/maybe-skills.md` | aguardar L05 antes de decidir]

## Diff vs Starter upstream
- Arquivos novos: <N>
- Arquivos modificados: <N>
- Arquivos do Starter ainda intactos: <N>

Mostra o diff antes de criar.

Aprove.

Passo 5 — Limpe os mortos (opcional, recomendado)

Pra cada item do bucket "morto", decide. Em geral:

• Skill que você nunca usou → deletar (rm -rf .claude/skills/<nome>)
• Rule que não pegou → deletar
• Caso ambíguo ("eu acho que isso pode ser útil ainda") → move pra docs/maybe-skills.md com nota de "criado em [data], 0 uso até [hoje]; revisar em 30 dias"

A regra: arquivo morto em .claude/ é ruído pro próximo Claude que for ler. Quando você abre o claude no projeto, ele lê os SKILL.md disponíveis pra decidir quando usar cada skill. Skill morta dilui essa heurística.

Passo 6 — Faça o commit

Faça commit do `docs/personal-pack-inventory.md` + qualquer deleção feita no Passo 5. Mensagem: `docs: personal-pack inventory`. Mostra os comandos antes.

Aprove. Confira no GitHub.

Build Diary — o .claude/settings.local.json do CEAP tinha 96 entradas; o versionado tinha 28

O CEAP tem dois settings (padrão do Claude Code): o versionado (.claude/settings.json, que vai pro repo) e o local (.claude/settings.local.json, que fica fora do git). O versionado tem 28 entradas no permissions.allow; o local tinha 96.

A diferença é exatamente o que esta lição te faz mapear: canônico (o que entra no repo, é parte do produto que outros vão ler) vs pessoal (o que mora só na sua máquina, atalhos seus). 96 - 28 = 68 entradas eram pessoais: comandos específicos do laptop, paths customizados, atalhos pra projetos paralelos. Quando o CEAP foi publicado open source, só o canônico foi pro git; o local ficou.

Pro Personal Pack a separação tem consequência prática: o próximo membro do time (ou você mesmo em outro projeto) vai consumir o canônico; o pessoal fica só seu. Empacotar tudo junto contamina o canônico com vícios pessoais. O inventário é o passo que torna a separação possível.

Takeaways

• 3 buckets: canônico (do starter, não toca), pessoal (vira Personal Pack), morto (deleta ou move pra maybe-skills).
• Bucket "pessoal" vazio = você ainda não personalizou muito nos módulos anteriores. É informação útil: L02 (hooks) e L05 (plugin) adicionam substância.
• Bucket "morto" com 5+ itens = regra da 3ª repetição não respeitada. Limpa antes de compor.
• Arquivo morto em .claude/ é ruído pro próximo Claude. Skill morta dilui a heurística de quando invocar skill.

Você terminou quando

Quatro coisas:

1. docs/personal-pack-inventory.md commitado com os 3 buckets preenchidos
2. Diff vs Starter upstream documentado (números)
3. Mortos (se houver) deletados ou movidos pra docs/maybe-skills.md
4. Você sabe contar de cabeça quantos arquivos são canônico, pessoal, e morto