Feedback log para skills — implementação no revisao-conteudo e criacao-conteudo

Skills viram artefatos de aprendizado quando registram correções reais do usuário e promovem padrões recorrentes a regras vinculantes. Esta nota é o log de implementação desse princípio em duas skills da Epost, mais o checklist replicável para aplicar a próximas.

Tese central

A skill como prompt estático degrada a cada sessão porque correções do usuário não são capturadas. Adicionar um feedback log dentro da pasta da skill, com curadoria periódica, transforma a skill em memória operacional que reduz erros recorrentes ao longo do tempo. Princípio em [[fonte-tiktok-feedback-de-memoria-em-skills-claude]].

Arquitetura comum às duas skills

Três níveis hierárquicos de memória, mais uma ponte central:

Arquivo	Lido em runtime?	Promoção
feedback-log.md	não	captura bruta, base de curadoria
padroes-em-observacao.md	sim, sinal leve	2 ocorrências confirmadas
regras-consolidadas.md	sim, vinculante	3+ ocorrências consistentes
analise-estilo/vicios-ia.md	via system prompt	banco central de vícios — recebe #novo-vicio exportado de qualquer skill

Curadoria roda sob comando explícito, nunca automática. Trigger: 30 entradas ou 30 dias.

Decisões arquiteturais que importam

Três níveis em vez de dois. Sem o nível “padrões em observação”, correções únicas viram regra (ruído) ou são esquecidas (perda). O intermediário absorve sinal e dá tempo para confirmação ou contradição.

Contexto importa para promoção. Duas entradas só contam para a mesma regra se compartilharem 2 de 3 entre canal/formato, ICP/audiência, território/pilar. Tom de Stories B2C não é o mesmo contexto de tom de LinkedIn artigo investidor — mesmo que a regra implícita pareça igual.

Vícios viajam pra fonte central. Cada skill pode descobrir vício novo, mas o lugar dele é analise-estilo/vicios-ia.md. Skills locais só registram recorrência. Evita N cópias do mesmo vício espalhadas pelo plugin.

Atenção redobrada antes da regra formal. Vícios e fit-ICP recorrentes (2+ ocorrências) recebem checagem antecipada na produção, antes da promoção a regra vinculante. Outras categorias seguem o threshold padrão de 3+. Estender atenção redobrada para tudo dilui o sinal.

Captura silenciosa com uma linha de lembrete. No fim de cada entrega, uma linha lembra que correções podem virar memória. Nada de “anotei isso”, “feedback registrado”, confirmações. Silêncio é o contrato.

Walkthrough — o que mudou em cada skill

revisao-conteudo

Skill de output curto, corrige peça pronta. Captura em eixo único: marca | tom | CTA | estrutura | vício. Atenção redobrada apenas para vícios.

Steps adicionados ao SKILL.md:

• Step 0.5 (carregamento de memória)
• Section 5.5 (linha de lembrete)
• Step 7 (captura silenciosa)
• Step 7.5 (atenção redobrada para vícios recorrentes)

criacao-conteudo

Skill de output longo (kit de 8 componentes), cria do zero. Quatro diferenças relevantes:

Eixo duplo na captura. Componente (copy-principal | hook | cta | visual | formato | decisao-upstream | contexto) × Issue (vicio | marca | tom | estilo-37signals | argumento | fit-icp | fit-territorio | formato-canal). Permite distinguir “tom errado em CTA para Comprador Online” de “tom errado em copy principal para Marketplace”.

Atenção redobrada estendida para fit-ICP. Erro de fit-ICP é sintoma de mismatch upstream e merece prioridade no Passo 5 (Check de fit) antes da promoção formal a regra.

Captura não registra correções de estrutura, tamanho ou componentes do kit. “Muito longo”, “tira a sugestão de música”, “só 2 hooks” são decisões de skill, não de feedback. Se quiser mudar isso, abre projeto separado para modificar o SKILL.md. Essa fronteira protege a skill da deriva por preferência momentânea.

Memórias separadas por skill. As duas skills podem aprender as mesmas regras (ex: “rápido” sem número), mas não compartilham consolidações. A única ponte é a de vícios, via banco central. Se em 6 meses a redundância pesar, refatora para memória compartilhada.

Checklist replicável

Para aplicar o padrão a outra skill:

1. Mapear categorias de feedback que a skill pode receber. Vai além de marca/tom/CTA/estrutura/vício? Tem componentes de output múltiplos? Tem decisões upstream que afetam tudo?
2. Decidir eixo único vs duplo. Output curto e linear: único. Kit com componentes diferentes: duplo (Componente × Issue).
3. Mapear contexto pivô. Quais variáveis precisam coincidir para duas correções contarem como mesma regra? Tipicamente 2 entre canal/audiência/área/objetivo.
4. Decidir o que NÃO captura. Estrutura do output costuma ficar de fora. Escolha entre variações também. Reframe do pedido idem.
5. Decidir atenção redobrada. Quais categorias ganham checagem antes da promoção formal? Default: vício. Adicione fit-ICP ou equivalente se a skill tem essa camada.
6. Criar os três arquivos com cabeçalhos, formato de entrada e regras de curadoria. Manter exemplos comentados para format-by-example.
7. Atualizar SKILL.md. Adicionar Passo 0.5 (carregamento de memória), linha de lembrete na entrega, passo final de captura silenciosa. Documentar atenção redobrada onde aplicar.
8. Bootstrap vazio. Arquivos sobem com headers e exemplos comentados. Funcionam de cara, enchem com uso real.

Como aplicar a outras skills

Cinco perguntas antes de desenhar:

• A skill produz conteúdo onde o usuário corrige por motivo de qualidade?
• O output tem componentes distintos com regras próprias?
• Qual o pivô de contexto que diferencia duas situações?
• Existe banco central de alguma categoria que a skill possa alimentar?
• Qual fronteira proteger contra deriva?

Quando NÃO aplicar

Skills determinísticas onde feedback é ruído: pdf, xlsx, docx. Output é estruturado e correção do usuário é de input, não da skill.

Skills onde captura silenciosa quebra UX: prospeccao-* quando o output é lista factual de empresas. Corrigir nome de empresa não vira regra.

Skills com uso esparso. Feedback log assume volume — em skill usada 1x ao mês, 30 entradas levam 3 anos. Não compensa.

Próximos passos

• Copiar os 4 arquivos de cada skill (revisao-conteudo-skill-update/ e criacao-conteudo-skill-update/ no workspace Epost) para a pasta da skill no plugin
• Avaliar aplicação em analise-estilo — skill que mantém o banco central, com feedback log próprio para o processo de extração de estilo, não para os vícios em si
• Em 30 dias, rodar primeira curadoria das duas skills e validar a regra de promoção 3+

Conecta com

• [[fonte-tiktok-feedback-de-memoria-em-skills-claude]]
• [[comparacao-claude-code-vs-cowork]]
• [[skill-analise-de-estilo]]
• [[sessao-skill-revisao-conteudo-2026-04-14]]

Notas candidatas a promover

• skills-como-processos-operacionais.md — princípio mais largo de que processos de negócio viram skills com memória
• memoria-operacional-em-agentes-de-ia.md — abstração além de skills, sobre agentes em geral acumulando aprendizado por feedback