growth-log

Growth Log Skill

O problema: A maioria das pessoas escreve "corrigi um bug em X" como registro de aprendizado. Isso é uma entrada de diário, não um artefato de aprendizado. Um registro de crescimento real extrai o padrão para que você o reconheça na próxima vez.

Este skill ensina: Como escrever entradas de aprendizado que se acumulam entre sessões. Funciona com qualquer sistema de anotações — arquivos Markdown, Notion, Obsidian, texto puro. Os templates são genéricos; adapte à sua configuração.

Quando Ativar

• Após concluir uma tarefa complexa (vários arquivos, novo recurso, mudança de arquitetura)
• Após uma falha, erro, ou momento em que "aquilo foi mais difícil do que esperava"
• Quando você quiser revisar o que aprendeu ao longo de um período

Quando NÃO ativar: Mudanças triviais (correções de digitação, ajustes de uma linha, alterações de valor de configuração sem depuração). O limite: essa tarefa envolveu depuração, retrabalho, reversão ou uma decisão não óbvia? Se sim → escreva uma entrada. Se não → pule.

As Três Regras

Regra 1: Falhas > Conquistas

Uma falha é nutricionalmente mais densa do que um sucesso. Um bug que levou 2 horas para encontrar ensina mais do que 3 recursos que funcionaram na primeira tentativa.

Ruim: "Implementei o fluxo de login com sucesso." Bom (desenvolvimento web): "Fluxo de login: o token de sessão não estava persistindo porque o SameSite do cookie padrão era Lax no Chrome 128+. Padrão: sempre defina explicitamente SameSite=None; Secure quando for de origens cruzadas. Sinal para reconhecer: autenticação quebra após atualização do navegador ou ao cruzar limites de origem." Bom (pipeline de dados): "Importação CSV falhou silenciosamente em linhas vazias porque pandas.read_csv(dropna=False) mantém linhas de largura zero que len() conta como válidas. Padrão: sempre use df.dropna(how='all', inplace=True) antes da validação de contagem de linhas."

Regra 2: O Princípio Bole (伯乐原则)

Antes de escrever uma nova entrada, pergunte: "Isso é fundamentalmente o mesmo que algo que já registrei?"

Mesma causa raiz, sintoma diferente → mescle, não duplique. Nova causa raiz → nova entrada.

Como verificar: Pesquise entradas existentes por palavras-chave da sua causa raiz antes de escrever. Se encontrar uma correspondência, adicione seu novo sintoma como um exemplo adicional na entrada existente, em vez de criar uma duplicata.

Exemplo: "Esqueci de atualizar o índice de saída após criar um arquivo" e "Esqueci de atualizar as classificações de skill após uma tarefa" — mesma causa raiz (nenhum gatilho de captura automática). Mescle em uma única entrada sobre "lacunas de captura pós-tarefa."

Regra 3: Deve Ser Transferível

Cada entrada deve responder: "Na próxima vez que enfrentar uma situação semelhante, o que farei de diferente?"

Se você não consegue escrever essa frase, ainda não extraiu o padrão.

Como extrair um padrão de um evento concreto:

1. Diga o que aconteceu em uma frase
2. Pergunte "por quê?" iterativamente até chegar à causa raiz (normalmente 3-5 porquês)
3. Generalize: "Que classe de problema é esta?" (não "bug do Chrome 128", mas "mudança no padrão do navegador quebrando comportamento existente")
4. Formule como: "Na próxima vez que eu ver [sinal], eu vou [ação]."
5. Nomeie o sinal: qual observável específico indica que esse padrão está ativo?

Template de Entrada

Escopo: Uma entrada por causa raiz distinta. Comprimento típico: 4-8 frases. Se levar >2 minutos para escrever, você está narrando eventos. Se <30 segundos, você não foi fundo o suficiente.

## [Título: o padrão, não o evento]

### Contexto
- O que eu estava tentando fazer?
- O que deu errado / o que funcionou surpreendentemente bem?

### Causa Raiz / Percepção Central
- O mecanismo subjacente, não apenas o sintoma

### O Padrão (transferível)
- Na próxima vez [situação semelhante], eu vou [ação específica].
- Sinal para reconhecer: [qual observável me diz que esse padrão está ativo?]

### Relacionado
- [nome-da-entrada](../caminho/para/entrada-relacionada.md)

Tipos de Entrada

Todos os quatro tipos usam o template acima. O tipo determina quais seções têm mais peso:

Tipo	Quando Usar	Ênfase	Exemplo de Título
Falha	Algo quebrou, exigiu depuração ou retrabalho	Causa Raiz	"Herança de config ≠ herança de comportamento entre sessões"
Metodologia	Um processo repetível emergiu do trabalho	Contexto / Padrão	"Guia de estudo PPT → prova de livro aberto: estrutura de três camadas"
Descoberta de Padrão	Uma percepção reutilizável sobre ferramentas, sistemas ou pensamento	Seção de Padrão	"Template de descrição de PR: descreva a lacuna, não o recurso"
Mudança de Capacidade	Uma melhoria mensurável de habilidade	Contexto (antes vs depois)	"Git: de clone/push a PR independente com 12 commits"

Checklist de Qualidade

Antes de finalizar uma entrada de registro de crescimento:

• O título nomeia o padrão, não o evento?
• Há uma frase "Na próxima vez eu vou..."?
• O "Sinal para reconhecer" é específico o suficiente para acionar o padrão na próxima vez?
• Eu pesquisei entradas existentes em busca de duplicatas antes de escrever? (Princípio Bole)
• A causa raiz está distinguida do sintoma?
• As memórias relacionadas estão interligadas?
• A entrada tem 4-8 frases? Mais curta = muito superficial; mais longa = narrando eventos.

Antipadrões

• Evite: "Bug corrigido no módulo de pagamento" (evento, não padrão)
• Evite: Copiar a mensagem do commit do git literalmente (commits descrevem o que mudou; registros extraem por que importa)
• Evite: Escrever uma entrada para cada commit (só quando um padrão emerge)
• Evite: Pular a frase transferível (sem ela, é apenas um diário — isso não é negociável)
• Evite: Duplicar o mesmo padrão sob títulos diferentes (viola o Princípio Bole — pesquise antes de escrever)

Armazenamento

Armazene entradas onde você mantém suas anotações. Padrões comuns:

• Arquivos Markdown em um diretório growth-log/ (um arquivo por dia: YYYY-MM-DD.md)
• Uma seção dedicada no Notion, Obsidian ou seu aplicativo de anotações
• Arquivos de texto puro com uma convenção de nomenclatura consistente

Escolha uma convenção e mantenha-a. A capacidade de pesquisa é mais importante que o formato.

Se Você Usar Delivery Gate

O hook de parada delivery-gate verifica se os arquivos de aprendizado foram modificados hoje através de timestamps do sistema de arquivos. Este skill ensina o que escrever — para que o arquivo que o delivery-gate verifica contenha padrões úteis, não timestamps vazios.

Tarefa concluída → delivery-gate verifica: o arquivo de aprendizado foi tocado hoje?
  → Desatualizado (nenhum arquivo modificado): bloqueie — "o que você aprendeu?"
  → Atualizado (arquivo tocado): passe — este skill garante que o conteúdo seja útil

Ter imposição sem metodologia → entradas vazias. Ter metodologia sem imposição → capturas esquecidas. Cada um é independentemente útil; juntos, eles fecham o ciclo.