m1nga/pacote-de-experiência

Experience Pack

Uma frase: cada projeto mantém seu próprio ledger de experiência; um teste de fronteira destila a parte portátil; apenas a parte portátil viaja entre projetos.

Funciona com entrada digitada ou ditada: descrições confusas, coloquiais e multilíngues de "o que deu errado" são matéria-prima válida para uma entrada no ledger — a skill as estrutura, o usuário apenas confirma.

As duas camadas

Camada	Arquivo	Dono	Regras de conteúdo
Ledger	EXPERIENCE.md na raiz do projeto	o projeto	datado, concreto, específico do projeto permitido; apenas experiência de processo — nunca verdade do produto, nunca um registro de decisão
Portátil	o arquivo de lições portáteis do projeto (ex.: LESSONS.md) e/ou o pacote de referência desta skill	viaja	abstrato, sem substantivos de produto, verdadeiro em um PROJETO DIFERENTE lido por um estranho

Pipeline: algo acontece → entrada no ledger (no mesmo dia, enquanto dói) → passagem de destilação periódica → lições portáteis. Decisões estratégicas e de produto nunca viajam: a experiência herda, as decisões morrem.

Protocolo A — REGISTRAR (ledger)

Adjudicação de raiz primeiro. O ledger vive na raiz do projeto — então confirme que EXISTE uma raiz do projeto antes de escrever. Se o diretório de trabalho atual for um diretório home, Área de Trabalho, Downloads ou qualquer outro local não pertencente a um projeto, pergunte a qual projeto esta experiência pertence e escreva o ledger lá. Nunca crie um EXPERIENCE.md em um diretório home ou na Área de Trabalho. Se nenhum diretório de projeto puder ser estabelecido, ou o destino não puder ser gravado, não descarte a entrada silenciosamente: produza a entrada totalmente formatada como texto copiável e diga ao usuário onde ela deve eventualmente ficar.

Crie EXPERIENCE.md na raiz do projeto no primeiro dia (ou no primeiro uso). Anexe uma entrada quando qualquer um destes ocorrer: um incidente custou tempo real/dinheiro/confiança; um método funcionou visivelmente; um revisor independente pegou algo que o autor perdeu; um padrão de colaboração teve sucesso ou fracasso; o usuário corrigiu o curso do agente.

Formato da entrada:

### AAAA-MM-DD — título
**O que aconteceu:** fatos, concretos.
**O que fizemos:** a resposta, concreta.
**O que funcionou / o que falhou:** ambos, honestamente.
**Custo:** tempo / tokens / confiança / retrabalho.
**Portátil?** sim → <slug-da-lição> | ainda não | não (específico do projeto).

Regras: registre experiência de processo, não fatos de produto; se o workspace tiver regras de higiene de contaminação (substantivos proibidos), o ledger as obedece; nunca retroatribua datas ou reescreva entradas antigas — anexe correções como novas entradas. Escreva as entradas do ledger em qualquer idioma em que o projeto vive (siga o hábito existente do usuário; se desconhecido, pergunte uma vez).

Regras vinculantes (destiladas dos projetos adotantes do pacote):

• Registrar é parte de concluído. A correção de um incidente não pode ser declarada completa até que sua entrada no ledger exista — o ledger é um portão, não um diário. (Um adotante inicial preencheu 8 entradas em um dia porque nada forçava a escrita no momento do incidente; combates a incêndio nunca deixam tempo para diários.)
• Importações de inicialização são legítimas, retroatribuição silenciosa não é. Ao adotar o pacote em um projeto com histórico: date cada entrada pela data do INCIDENTE e declare a importação em uma nota datada no topo do ledger. Uma entrada datada no passado sem uma importação declarada é fabricação.
• Higiene de distribuição. O ledger contém informações internas do projeto. Em um repositório com um remoto público, coloque EXPERIENCE.md no gitignore por padrão; publique apenas a camada portátil testada pela fronteira.
• Descoberta. Adicione uma linha de ponteiro ao arquivo de verdade principal do projeto (CLAUDE.md / AGENTS.md / mapa do sistema / documento de estado) para que um agente sem contexto POSSA encontrar o ledger; um ledger não descoberto não registra nada para a próxima sessão.
• Um ledger ignorado pelo git precisa de uma rota de fuga declarada. Ignorar o ledger pelo git (regra acima) também o remove da recuperação via clone/push. Um ledger ignorado pelo git DEVE ter um canal de backup ou sincronia declarado — um repositório ou branch privado, uma pasta sincronizada, uma cópia agendada; o usuário escolhe — registrado como uma linha na nota de cabeçalho do ledger. Sem isso, uma troca de máquina ou reclone apaga silenciosamente a memória do projeto: trocar de máquinas se torna amnésia que ninguém nota até o próximo incidente se repetir.

Protocolo B — DESTILAR (teste de fronteira)

Para cada entrada do ledger marcada como "Portátil? sim/ainda não", execute os testes em ordem:

1. Teste de substituição — remova todos os substantivos próprios e números específicos. A afirmação ainda ensina algo? Entra em colapso → é uma decisão, morre.
2. Mecanismo vs. escolha — diz como as coisas funcionam ou falham (mecanismo → herda), ou quem/o quê/quanto foi escolhido (escolha → morre)?
3. Teste de re-derivação — um estranho inteligente poderia re-derivar isso do próprio contexto do novo projeto? Se só pudesse vir da estratégia do projeto antigo, é a estratégia antiga falando — morre.
4. Teste de custo irrecuperável — seu único valor é que esforço foi gasto nisso? Morre.
5. Teste de verificabilidade — verificar isso requer um substantivo morto? Abstraia-o ou deixe-o morrer.

Os sobreviventes são reescritos como uma linha imperativa abstrata + porquê + como aplicar, marcados com proveniência ("projeto anterior, destilado · data"). Escreva a camada portátil em inglês (ou bilingue): o ledger pode usar qualquer idioma em que o projeto vive, mas lições portáteis viajam para estranhos — jargão local do projeto as prende. Itens ambíguos padrão para MORRER — o ledger os mantém recuperáveis para uma passagem posterior. REBAIXAMENTO (raro): um artefato em forma de estratégia reentra em outro projeto apenas como uma HIPÓTESE explícita com uma condição de revalidação, e apenas por chamada do usuário — nunca silenciosamente.

Protocolo C — COMPARTILHAR / APLICAR (outro projeto aprende com este)

1. No projeto receptor: leia references/rebuild-experience-pack.md (a saga empacotada desta skill) e/ou o arquivo de lições portáteis do projeto de origem — nunca o ledger do projeto de origem, arquivos de verdade ou estratégia.
2. Inicialize o próprio EXPERIENCE.md do projeto receptor (Protocolo A, incluindo adjudicação de raiz).
3. Percorra os cinco conselhos do pacote como uma lista de verificação de configuração; adote o que se aplica; registre desvios como a primeira entrada do ledger do projeto receptor.
4. Lições adotadas entram no projeto receptor marcadas com proveniência; são restrições de engenharia, não decisões do usuário — o usuário pode reclassificar qualquer uma delas.

Limites — o que esta skill nunca faz

• Nunca copia estratégia, fatos de produto, personas, preços, canais, nomes de clientes ou identidades de conta entre projetos — em nenhuma direção.
• Nunca trata o ledger como um registro de decisão; decisões vivem nos próprios arquivos de verdade/decisão do projeto com suas próprias regras de proveniência.
• Nunca edita outras skills ou a configuração global do usuário.
• Nunca lê material em quarentena/arquivado de um projeto para "enriquecer" um pacote; a entrada de destilação é apenas o ledger e os arquivos vivos.

Relacionamento com skills adjacentes

• conclude-rounds — revisa as rodadas da conversa atual. Um usuário dizendo "复盘" ou "vamos revisar" sobre ESTA conversa pertence a ela; esta skill é dona de post-mortems em nível de projeto que sobrevivem à conversa.
• iteration-close — fecha uma iteração de uma direção contínua (destilar, deletar bagagem, etiquetar, semear). Execute o Protocolo B do experience-pack como parte dele se ambos estiverem instalados; iteration-close é dona do ritual de fechamento. Ressalva que ambas as skills devem honrar: "o histórico do git é o arquivo" vale APENAS para arquivos rastreados. Material não rastreado/ignorado pelo git (IP privado em um repositório público) não tem arquivo — coloque-o em quarentena sob uma regra local explícita (ex.: _retired/) antes de qualquer purga; deletá-lo é perda permanente, não limpeza.
• diagnose-project-rebuild — quando uma direção é SUBSTITUÍDA, o teste de fronteira aqui é o mesmo teste usado para decidir o que sobrevive; a skill de rebuild é dona do diagnóstico e dos mecanismos de purga, e recebe APENAS a camada portátil desta skill como entrada.
• Esta skill é agnóstica a produto e deve permanecer assim: se um substantivo de projeto aparecer neste arquivo ou em suas referências, isso é um defeito — remova-o.

Notas do motor

Nada aqui depende do tempo de execução de um fornecedor. "Sessão nova" e "sonda sem contexto" significam qualquer instância de agente iniciada sem o contexto anterior — um novo chat, um subagente ou uma segunda ferramenta. Onde um tempo de execução de skill estiver ausente, aplique os protocolos manualmente: os formatos de arquivo e testes acima são a skill.

Referência

references/rebuild-experience-pack.md — a experiência empacotada e sem substantivos de uma saga real de contaminação de cinco reconstruções: as seis portas de contaminação, o método de redefinição de bloqueio de origem, a pilha de verificação de três sondas, o protocolo de colaboração multi-IA e os cinco conselhos de prevenção.