loot

O que loot faz?

Toda sessão drops loot. A maior parte morre no chat. Seu trabalho: encontrá-lo, escrevê-lo tudo, julgá-lo com base em evidências em vez de entusiasmo, e enviar apenas a peça rara que merecer, depois que o usuário disser sim.

A maior parte do valor do loot está em LOOT.md: um registro contínuo de tudo que o usuário descobriu. Publicar é a exceção.

Loot é qualquer parte valiosa da sessão, não apenas descobertas paralelas:

Tipo	Como se parece	Forma usual
Build	o app, ferramenta ou script sobre o qual a sessão tratava	repo
Componente	uma peça que funciona fora deste projeto (um hook, um parser, uma config, um prompt)	repo ou gist
Técnica	um truque, correção ou método (deixou X 4× mais rápido, fez Y funcionar localmente)	post + gist ou repo
Know-how	correções e feedback que o usuário te deu que melhoraram a saída	skill
História	o caminho do problema ao resultado, becos sem saída incluídos	post
Dados	benchmarks, comparações, medições	post ou README do repo

Uma sessão geralmente contém vários itens. Um único item frequentemente merece várias formas (repo + post + demo).

Modos

Comando	Faz
/loot	escaneia esta sessão, mostra a tabela, pergunta o que enviar
/loot "<tópico>"	olha apenas uma coisa (mais barato): "o truque do ffmpeg"
/loot 2, /loot all	envia o drop 2, ou todos os drops classificados como Raro ou melhor, sem perguntar quais
/loot --list	lista sessões passadas recentes para escolher
/loot <sessao.jsonl>	escaneia uma sessão passada em vez desta
/loot review	reavalia o que já está em LOOT.md (veja passo 6)

1. Escanear

Leia toda a conversa e os arquivos que ela tocou. Para uma sessão passada, ou quando partes anteriores desta foram resumidas, leia a transcrição:

node <pasta desta skill>/scripts/transcript.mjs list          # sessões recentes do Claude Code + Codex
node <pasta desta skill>/scripts/transcript.mjs read <arquivo>   # texto condensado, segredos ocultados

A transcrição desta sessão é o arquivo mais novo em ~/.claude/projects/<projeto>/. Se você não conseguiu ler além de um resumo, diga isso na tabela: descobertas iniciais podem estar faltando. Liste candidatos. Para cada um, escreva o que ele faz e a prova de que funciona (teste, benchmark, antes/depois, reação do usuário).

Descarte um item quando ele só funciona na configuração deste usuário e não pode ser tornado geral, quando é principalmente código de outra pessoa, ou quando é trabalho particular ou de cliente do usuário. Não mencione segredos, credenciais ou dados pessoais da sessão na tabela.

2. Avaliar

A classificação é um filtro, e seu trabalho é dizer não. Você é um mau juiz do trabalho que acabou de ajudar a fazer: não consegue dizer o que é novo para o mundo, e tende a elogiar o usuário. Então a raridade vem das evidências, e o julgamento acontece longe da conversa.

Colete evidências para cada candidato:

• consulta: o que um estranho com esse problema digitaria em uma caixa de busca
• busca: execute-a (web, GitHub, npm/PyPI) e liste os resultados mais próximos com links. Busque pelo que ele faz, não pelo seu nome. Sem ferramenta de busca: "não verificado".
• prova: um teste, benchmark ou antes/depois que realmente aconteceu na sessão, com onde (o comando, o arquivo, a mensagem), ou "nenhuma". Nunca reconstrua prova de memória: notas de IA inventam nomes, números e detalhes.
• diferencial: o que ele faz que o resultado mais próximo não faz, medido se possível

Avalie em outro lugar. Se você pode iniciar um subagente, dê a ele apenas os candidatos e suas evidências, nunca a conversa, com este resumo: "Avalie cada item contra o padrão abaixo. Argumente para Comum primeiro e eleve um item apenas quando suas evidências atingirem o padrão. Quando em dúvida, avalie mais baixo. Use apenas as evidências fornecidas; nunca adicione ou assuma nada. Para qualquer item um requisito abaixo do próximo nível, nomeie a evidência mais barata que o elevaria." Se não conseguir, escreva o argumento mais forte de que cada item é Comum antes de avaliá-lo.

Raridade	Precisa de tudo isso	Formas
Comum	qualquer coisa abaixo de Raro	uma linha em LOOT.md
Raro	uma consulta real; uma busca citada que não encontrou equivalente, ou um diferencial medido sobre o resultado mais próximo; prova de que funciona	gist, post curto, ou um repo ou skill pequeno
Épico	Raro, mais um diferencial medido sobre uma alternativa nomeada, e funciona a partir de um clone limpo	repo ou skill, post, demo, rascunhos de lançamento

Regras duras:

• "não verificado" ou "nenhuma prova" significa Comum, por mais bom que pareça.
• Algo equivalente existe e o diferencial não é medido: Comum. Um diferencial argumentado a partir de READMEs de outros projetos não é medido.
• Empates arredondam para baixo.
• Quase acertos ganham um próximo passo. Um item um requisito abaixo do próximo nível é rotulado [COMUM, perto de Raro] ou [RARO, perto de Épico] e ganha uma linha próximo:: a evidência mais barata que o elevaria, e aproximadamente quanto tempo leva. Isso transforma um "não" em uma tarefa que o usuário pode escolher.
• Espere que quase tudo seja Comum. Se mais de um item em uma sessão avaliar acima de Comum, diga por que esta sessão é a exceção.
• Comum não é fracasso. É a entrada de diário que impede o trabalho de ser perdido.

Mostre a tabela de loot, com as evidências para qualquer coisa acima de Comum, e pare:

LOOT: 3 drops
1. [RARO, perto de Épico] remotion-ae-transitions: Transições estilo After Effects no Remotion, totalmente local
   consulta: "remotion after effects transitions"
   busca: @remotion/transitions (slides, fades, wipes), um pacote pago de templates; nenhum faz estas
   prova: 6 transições renderizadas e aprovadas na sessão
   diferencial: não medido, então não Épico → gist + post curto
   próximo: renderizar as mesmas 3 cenas com @remotion/transitions e comparar; depois uma execução de clone limpo (~45 min)
2. [COMUM] truque de duas passadas do ffmpeg: documentado na wiki do ffmpeg → LOOT.md
3. [COMUM] carregador de fonte personalizado: útil apenas neste projeto → LOOT.md
Enviar quais? (números, "todos", ou "nenhum")

Mostre no máximo 7 drops, do mais forte primeiro. Todo o resto ganha uma linha em "anotado".

Depois de mostrar a tabela, anexe-a ao LOOT.md na raiz do projeto (crie-o se estiver faltando), datado. Um drop merece uma entrada completa apenas se uma sessão futura pudesse dar errado, ou refazer trabalho real, sem ele. Caso contrário é uma entrada "anotada" de uma linha. O diário só é útil se permanecer legível.

3. Forjar

Para cada item escolhido, construa a coisa finalizada em uma nova pasta fora do histórico do repositório atual (padrão ../<slug>, ou onde o usuário disser). Leia references/forge.md para a lista de verificação de cada forma. Em resumo:

• Generalize-o. Remova nomes de projeto, caminhos fixos, detalhes de cliente e código morto. Deve funcionar a partir de um clone limpo com os passos do README. Execute-o.
• Nomeie-o. Curto, memorável, diz o que faz. Verifique se o nome está livre: gh search repos <nome>, npm view <nome> (exit 1 significa livre).
• Tagline. Uma linha que diz a um estranho o que ele faz e para quem.
• Logotipo. Simples, uma ou duas cores, legível em 16px, funciona em claro e escuro.
• Preview social. Um cartão 1280×640 (logotipo, nome, tagline) para que links compartilhados mostrem uma imagem em vez de um cartão em branco do GitHub.
• README. Resultado primeiro, depois início rápido, depois como funciona.
• Prova. Um teste, um benchmark, ou um antes/depois. Nunca invente números.

Skills: se a forma escolhida for uma skill, siga a skill skill-factory que está ao lado desta (../skill-factory/SKILL.md), passando a ela as evidências do item (consulta, resultados de busca, prova, diferencial) como especificação inicial. Pule os passos 3–5 para esse item: a skill-factory testa, revisa e controla o lançamento ela mesma.

4. Verificar (nunca pule)

1. Escaneie cada pasta que você publicará em busca de segredos:

   • sempre: node <pasta desta skill>/scripts/scan.mjs <pasta>
   • também, se gitleaks estiver instalado: gitleaks dir <pasta>, e gitleaks git <pasta> quando a pasta tiver histórico git.

   Corrija cada achado, ou marque um falso positivo com loot:allow naquela linha e diga por quê. Olhe cada linha warn manualmente. Nunca envie histórico git existente que o gitleaks não escaneou; sem gitleaks, publique a partir de um novo git init.

2. Leia cada arquivo que será publicado. Procure por dados pessoais, nomes de cliente, nomes de host internos, links de repositórios privados e código sob outra licença.

3. Mostre ao usuário um manifesto: cada destino (nome do repo, público ou privado, rascunho de blog ou ao vivo), os arquivos, a tagline. Peça um sim claro. Um sim cobre exatamente aquele manifesto, nada mais.

5. Publicar

Leia references/ship.md para comandos e alternativas. Use suas próprias ferramentas primeiro; recorra a passar ao usuário um comando ou arquivo pronto para executar.

• Repo: gh repo create, descrição, tópicos, push.
• Post: dev.to ou Hashnode como rascunho quando um token já estiver configurado; caso contrário, um arquivo Markdown. Medium: Markdown mais instruções de importação.
• Posts de lançamento (Show HN, X, Reddit), apenas Épico: rascunhos em uma pasta launch/ ignorada pelo git. Nunca os publique.
• Finalize com links para tudo publicado e qualquer coisa deixada para o usuário.

6. Revisar (/loot review)

Classificações de uma sessão são um palpite. Evidências se acumulam com o tempo:

1. Leia LOOT.md. Agrupe entradas que são a mesma coisa vista novamente (mesma ideia raiz, mesmo se redigida de forma diferente).
2. Reavalie um drop quando algo mudou: ele apareceu em 3 ou mais sessões, ganhou prova (usuários, um benchmark, alguém pediu por ele), ou uma nova busca não encontra mais equivalente. Use as mesmas regras de evidência e o mesmo avaliador externo.
3. Mostre o que mudou e por quê. Escreva uma seção "revisão" datada em LOOT.md; nunca reescreva entradas antigas. Depois ofereça-se para publicar qualquer coisa que agora seja Raro ou melhor.

Usar o que o agente tem

Necessidade	Melhor	Alternativa que sempre funciona
Logotipo / imagem de capa	sua própria geração de imagem ou um MCP de imagem, se você tiver um	SVG escrito à mão
Varredura de segredos	gitleaks (também cobre histórico git)	scripts/scan.mjs incluído
Vídeo de demonstração	Remotion (Node)	screenshots + GIF
Screenshots	uma ferramenta de navegador	peça ao usuário uma
"Existe?"	busca na web	marque "não verificado" (limita a Comum)
Sessões passadas ou resumidas	scripts/transcript.mjs (Claude Code, Codex)	peça ao usuário para colar ou exportar a conversa
Avaliação independente	um subagente que nunca vê a conversa	o argumento mais forte para Comum, escrito primeiro
Publicar repo	CLI gh	imprima os comandos
Publicar post	API da plataforma com um token existente	arquivo Markdown

Regras

• Nada vai a público sem o sim do usuário no manifesto exato.
• Nunca peça, digite ou armazene credenciais. Se uma ferramenta não estiver logada, recorra.
• Nunca publique segredos, dados pessoais, ou trabalho de cliente ou empregador.
• Respeite licenças: não relicencie código que você não escreveu.
• Nenhuma prova inventada: sem benchmarks, usuários, citações ou contagens de estrelas falsas.
• Escreva na voz do usuário do chat, não como um comunicado de imprensa.