continuous-learning
continuous-learning é a skill que transforma as descobertas de
uma sessão no conhecimento da próxima. É a contraparte editorial
do hook propose-knowledge-update: o hook captura sinais
automaticamente, e essa skill é o que o usuário (ou o fluxo
/octopus:review-proposals) usa para rascunhar, testar e
promovê-los.
Por que ter um sistema de aprendizado
Sem ele, cada sessão redescobre as mesmas coisas — o mesmo arquivo surpreendente, a mesma convenção de nomenclatura, a mesma pegadinha específica do projeto. O agent não tem memória entre sessões, e o humano não tem paciência para reexplicar o mesmo contexto duas vezes.
Um sistema de aprendizado é a memória em nível de projeto: rules
em rules/common/, fatos estruturais em knowledge/,
preferências comportamentais em CLAUDE.md. O trabalho da skill
é popular essas casas deliberadamente, em vez de deixá-las
crescer de forma ad hoc.
O ciclo de vida de um aprendizado
- Captura. Algo aconteceu que parece valer a pena guardar. O hook captura isso automaticamente (correções, re-leituras, re-greps); o usuário também pode trazer um aprendizado manualmente (“lembre-se de que sempre usamos X para Y”).
- Rascunho. A skill escreve uma entrada candidata no gênero
apropriado — uma rule para “sempre faça X”, um arquivo de
knowledge para “veja como Y funciona”, uma linha no
CLAUDE.mdpara “o usuário prefere Z”. - Hipótese. O rascunho inclui a previsão: se isso virar uma rule, o agent vai parar de fazer W da próxima vez. A previsão é testável.
- Teste. A próxima sessão que atingir o contexto relevante ou segue a rule ou não. A skill ajuda o usuário a perceber qual dos dois aconteceu.
- Promover ou aposentar. Padrões confirmados se tornam
rules / knowledge / linhas de
CLAUDE.mdde verdade. Padrões que não se confirmaram são arquivados sem constrangimento — metade do sinal capturado acaba sendo contexto pontual, e fingir o contrário só polui a base de conhecimento.
Team mode — aprendizado de review fleet-wide
Tudo acima é o modo default: a captura de sessão de um único dev em
knowledge/. O team mode sobe o mesmo loop captura→promoção pro escopo
time/review — pra que “o time inteiro erra X” vire uma regra em vez de um
comentário de PR redigitado.
-
A captura é contínua e automática. Um Stop hook —
review-log-capture— lê o transcript da sessão, puxa as findings de review (as tagsBLOCKING:/ADVISORY:/QUESTION:quearchitect/security/mentor/pr-reviewemitem) e as anexa ao.octopus/review-log/(gitignored). Sem editar os skills de review. -
A agregação é operator-run, e fleet-aware. O team mode minera o review-log pela frota (reusando a lista
repos:dofleet.yml), agrupa findings por tópico e conta tanto ocorrências quanto espalhamento entre repos distintos. -
O espalhamento roteia o destino. Um padrão em
≥ fleet_reposrepos distintos (default 3) promove pras rules compartilhadas doworkspace:— herdadas por todos os repos; um padrão de um repo só acima delocal(default 5) fica na rule local daquele repo. Os limiares são configuráveis nofleet.yml:fleet.yml learning:local: 5fleet_repos: 3 -
A promoção segue human-gated. Candidatos caem em
.octopus/proposals/e são promovidos via/octopus:review-proposals— o team mode nunca auto-edita uma regra. O loop fecha: review → review-log → padrão fleet-wide → regra no workspace → todo repo herda.
O que ela não faz
- Não edita automaticamente. Toda promoção é uma decisão humana.
- Não sintetiza entre sessões. Cada sinal capturado é avaliado por si só; a skill não infere “você disse X três vezes” sem um prompt explícito.
- Não escreve conselhos genéricos. “Use bons nomes de variáveis” vai numa rule de coding-style, não num aprendizado — aprendizados são específicos do projeto.
Por que pronto para multi-agente
Conhecimento capturado sob o Claude também deve fluir para
Copilot, Codex, Gemini e OpenCode. A skill escreve nos locais
canônicos do Octopus (rules/, knowledge/, equivalentes a
CLAUDE.md por agent) para que a geração do manifest a nível de
projeto consiga absorvê-los. Um aprendizado não fica preso na
memória de sessão de um único agent.