dd-harness 0.37.0 → 0.38.0

package/dist/skills-iniciais.js

@@ -80,382 +80,382 @@ Critérios fortes deixam você iterar sozinho. Critérios fracos ("faça funcion
         slug: "gravar-com-ancora",
         descricao: `Grava uma memória no Brain amarrada ao ponto do código de que ela fala. Invoque quando for gravar memória que descreve um arquivo, função, chave de config ou trecho específico — a âncora é o que faz a memória ser entregue a quem mexer ali depois. Não use para memória que fala do projeto como um todo.`,
         ferramentas: ["mcp__dd-harness__sugerir_ancoras", "mcp__dd-harness__gravar_memoria", "mcp__dd-harness__buscar_memoria", "Read", "Grep"],
-        conteudo: `# Gravar memória com âncora
-
-Memória sem âncora só aparece se alguém lembrar de buscar — e é justamente quando o
-agente *acha que sabe* que ele não busca. A âncora inverte isso: ela faz a memória chegar
-antes da edição, sem ninguém pedir.
-
-Este procedimento é sobre **escolher o alvo certo**. Gravar é uma chamada; escolher a
-âncora é a decisão que faz a memória proteger algo ou nascer inerte.
-
-## 1. Confira que ela não existe
-
-Chame \`buscar_memoria\` com a pergunta que a memória responderia. Se já houver uma que diz
-a mesma coisa, **edite aquela** em vez de criar uma segunda — duas memórias dizendo o
-mesmo se contradizem no dia em que uma for corrigida.
-
-## 2. Descubra o que a sessão tocou
-
-\`sugerir_ancoras\` devolve os arquivos modificados. Isso é **matéria-prima, não escolha**:
-a lista mostra onde o trabalho aconteceu, e a âncora certa é o ponto de que a *memória*
-fala — que pode ser um arquivo que você só leu.
-
-Lista vazia (projeto sem git) não é impedimento: pergunte ao usuário qual ponto a memória
-guarda.
-
-## 3. Escolha o alvo — a decisão que importa
-
-**Prefira sempre \`arquivo#trecho\` a \`arquivo\` inteiro.**
-
-Medido neste projeto: duas memórias ancoradas no mesmo \`config/limites.json\` eram **as
-duas** sinalizadas quando só uma das chaves mudava. Alerta que dispara no lugar errado
-ensina a ignorar o mecanismo — e aí ele deixa de proteger.
-
-O trecho precisa ser **estável e específico**:
-
-| Bom alvo | Por quê |
-|---|---|
-| \`SECURITY DEFINER\` | é a decisão em si; some só se a decisão mudar |
-| \`poolConexoesPostgres\` | nome de chave, sobrevive a reformatação |
-| \`processarPagamento\` | nome de função, muda só em rename deliberado |
-
-| Alvo ruim | Por quê |
-|---|---|
-| \`const x = 3\` | a próxima refatoração reescreve |
-| \`// TODO\` | aparece em toda parte do arquivo |
-| uma linha inteira de código | qualquer espaço a mais quebra o casamento |
-
-**Confirme antes de gravar:** abra o arquivo e veja quantas linhas contêm o texto do alvo.
-Se aparecer em dez lugares, o alvo é largo demais. Se não aparecer em nenhum, a âncora
-nasce quebrada — e ninguém descobre, porque alvo ausente parece deriva legítima.
-
-## 4. Âncora de diretório: quando cabe
-
-\`supabase/migrations\` faz sentido para memória que fala da pasta inteira ("toda migration
-precisa de X"). Não use diretório quando a memória fala de um arquivo dentro dele.
-
-## 5. Proponha ao humano, com o alvo explícito
-
-Diga qual âncora você escolheu **e por quê aquele trecho**. Se você não consegue explicar
-por que o alvo é estável, provavelmente ele não é.
-
-Só então chame \`gravar_memoria\`.
-
-## Se a memória não tem ponto no código
-
-Grave sem âncora, e **diga isso ao usuário**: ela só será encontrada por busca, e ninguém
-será avisado ao mexer em nada. Para memória sobre um acordo com cliente ou uma regra da
+        conteudo: `# Gravar memória com âncora
+
+Memória sem âncora só aparece se alguém lembrar de buscar — e é justamente quando o
+agente *acha que sabe* que ele não busca. A âncora inverte isso: ela faz a memória chegar
+antes da edição, sem ninguém pedir.
+
+Este procedimento é sobre **escolher o alvo certo**. Gravar é uma chamada; escolher a
+âncora é a decisão que faz a memória proteger algo ou nascer inerte.
+
+## 1. Confira que ela não existe
+
+Chame \`buscar_memoria\` com a pergunta que a memória responderia. Se já houver uma que diz
+a mesma coisa, **edite aquela** em vez de criar uma segunda — duas memórias dizendo o
+mesmo se contradizem no dia em que uma for corrigida.
+
+## 2. Descubra o que a sessão tocou
+
+\`sugerir_ancoras\` devolve os arquivos modificados. Isso é **matéria-prima, não escolha**:
+a lista mostra onde o trabalho aconteceu, e a âncora certa é o ponto de que a *memória*
+fala — que pode ser um arquivo que você só leu.
+
+Lista vazia (projeto sem git) não é impedimento: pergunte ao usuário qual ponto a memória
+guarda.
+
+## 3. Escolha o alvo — a decisão que importa
+
+**Prefira sempre \`arquivo#trecho\` a \`arquivo\` inteiro.**
+
+Medido neste projeto: duas memórias ancoradas no mesmo \`config/limites.json\` eram **as
+duas** sinalizadas quando só uma das chaves mudava. Alerta que dispara no lugar errado
+ensina a ignorar o mecanismo — e aí ele deixa de proteger.
+
+O trecho precisa ser **estável e específico**:
+
+| Bom alvo | Por quê |
+|---|---|
+| \`SECURITY DEFINER\` | é a decisão em si; some só se a decisão mudar |
+| \`poolConexoesPostgres\` | nome de chave, sobrevive a reformatação |
+| \`processarPagamento\` | nome de função, muda só em rename deliberado |
+
+| Alvo ruim | Por quê |
+|---|---|
+| \`const x = 3\` | a próxima refatoração reescreve |
+| \`// TODO\` | aparece em toda parte do arquivo |
+| uma linha inteira de código | qualquer espaço a mais quebra o casamento |
+
+**Confirme antes de gravar:** abra o arquivo e veja quantas linhas contêm o texto do alvo.
+Se aparecer em dez lugares, o alvo é largo demais. Se não aparecer em nenhum, a âncora
+nasce quebrada — e ninguém descobre, porque alvo ausente parece deriva legítima.
+
+## 4. Âncora de diretório: quando cabe
+
+\`supabase/migrations\` faz sentido para memória que fala da pasta inteira ("toda migration
+precisa de X"). Não use diretório quando a memória fala de um arquivo dentro dele.
+
+## 5. Proponha ao humano, com o alvo explícito
+
+Diga qual âncora você escolheu **e por quê aquele trecho**. Se você não consegue explicar
+por que o alvo é estável, provavelmente ele não é.
+
+Só então chame \`gravar_memoria\`.
+
+## Se a memória não tem ponto no código
+
+Grave sem âncora, e **diga isso ao usuário**: ela só será encontrada por busca, e ninguém
+será avisado ao mexer em nada. Para memória sobre um acordo com cliente ou uma regra da
 organização, isso é o correto — não force uma âncora que não existe só para ter uma.`,
     },
     {
         slug: "resolver-deriva",
         descricao: `Decide o que fazer quando o check acusa deriva numa memória — se ela ainda vale, se a âncora mudou de lugar, ou se o mundo mudou e ela morreu. Invoque ao ver ALVO AUSENTE ou alvo alterado no resultado de dd-harness check, ou quando o status mostrar observações esperando julgamento.`,
         ferramentas: ["mcp__dd-harness__ler_memoria", "mcp__dd-harness__editar_memoria", "mcp__dd-harness__arquivar_memoria", "Read", "Grep", "Bash(dd-harness check:*)", "Bash(dd-harness status:*)", "Bash(dd-harness reancorar:*)", "Bash(git log:*)", "Bash(git diff:*)"],
-        conteudo: `# Resolver deriva
-
-Deriva é a memória avisando que o mundo que ela descreve mudou. Há **três** respostas
-possíveis, e o atalho tentador é sempre o mesmo — marcar "ainda vale" e fechar o alarme.
-
-É assim que um Brain apodrece parecendo saudável: nenhuma observação aberta, e metade das
-memórias descrevendo um código que não existe mais.
-
-## Primeiro: qual é o tipo?
-
-\`dd-harness check\` distingue dois, e eles pedem coisas diferentes.
-
-**ALVO AUSENTE** — o arquivo ou trecho não existe mais no caminho ancorado.
-**Alterado** — o alvo existe e o conteúdo mudou desde a linha de base.
-
-## ALVO AUSENTE: quase sempre é reancorar
-
-O arquivo mudou de lugar. Se houve rename no commit, o \`check --commit\` já imprime o
-comando \`dd-harness reancorar\` pronto — **confira o destino antes de rodar**: rename por
-similaridade é heurística do git, e reancorar para o lugar errado move a memória em
-silêncio, o que é pior que o alvo ausente.
-
-Se não houve rename, procure o conteúdo (\`Grep\` pelo trecho ancorado). Três desfechos:
-
-- **achou noutro lugar** → reancore para lá
-- **o trecho foi renomeado** (a função virou outra coisa) → reancore para o nome novo, e
-  confira se a memória ainda descreve o que aquele código faz
-- **sumiu de vez** → o mundo mudou; siga para "a memória morreu"
-
-## Alterado: leia a memória ANTES de decidir
-
-Isto é o passo que o atalho pula. Abra a memória com \`ler_memoria\` e leia o **porquê** —
-não o título. A pergunta é:
-
-> A razão que fez esta memória existir continua verdadeira?
-
-Compare com o que mudou (\`git diff\` no alvo). Três desfechos, e cada um tem uma ação
-diferente:
-
-**1. A memória ainda vale** — o código mudou por perto, mas a razão externa continua de
-pé (o fornecedor continua limitando, o compliance continua exigindo). Resolva como "ainda
-vale": a linha de base passa a ser o estado atual.
-
-**2. A memória vale, mas o texto envelheceu** — a razão é a mesma, a descrição não bate
-mais com o código. **Edite a memória** e depois resolva. Resolver sem editar guarda uma
-memória que vai confundir quem a ler.
-
-**3. A razão deixou de existir** — o fornecedor mudou o limite, a lib foi trocada, a
-decisão foi revertida. Aí não é "ainda vale": é \`arquivar_memoria\` com motivo
-\`obsoleta\`. Se outra memória tomou o lugar, use \`--substituida-por\`.
-
-## Nunca faça
-
-**Não resolva em lote.** Cinco observações abertas são cinco perguntas diferentes; marcar
-todas como "ainda vale" é o mesmo que não ter medido nada.
-
-**Não decida sozinho pelo arquivamento.** Resolver "ainda vale" é reversível — a próxima
-deriva reabre. Arquivar tira a memória de circulação, e quem vier depois não saberá que
-ela existiu se você errar. Proponha ao humano.
-
-**Não edite o código para fechar a deriva.** Se o alvo mudou porque alguém corrigiu um
-bug, o código está certo e a memória é que precisa acompanhar.
-
-## O caso que parece deriva e não é
-
-Se o primeiro \`check\` de um projeto acusa tudo, isso não é deriva: é a **linha de base
-sendo adotada**. Medido numa rodada de teste — rodar o primeiro \`check\` com o código já
-alterado fixa o estado errado como base, e reverter para o valor correto passa a ser "a
+        conteudo: `# Resolver deriva
+
+Deriva é a memória avisando que o mundo que ela descreve mudou. Há **três** respostas
+possíveis, e o atalho tentador é sempre o mesmo — marcar "ainda vale" e fechar o alarme.
+
+É assim que um Brain apodrece parecendo saudável: nenhuma observação aberta, e metade das
+memórias descrevendo um código que não existe mais.
+
+## Primeiro: qual é o tipo?
+
+\`dd-harness check\` distingue dois, e eles pedem coisas diferentes.
+
+**ALVO AUSENTE** — o arquivo ou trecho não existe mais no caminho ancorado.
+**Alterado** — o alvo existe e o conteúdo mudou desde a linha de base.
+
+## ALVO AUSENTE: quase sempre é reancorar
+
+O arquivo mudou de lugar. Se houve rename no commit, o \`check --commit\` já imprime o
+comando \`dd-harness reancorar\` pronto — **confira o destino antes de rodar**: rename por
+similaridade é heurística do git, e reancorar para o lugar errado move a memória em
+silêncio, o que é pior que o alvo ausente.
+
+Se não houve rename, procure o conteúdo (\`Grep\` pelo trecho ancorado). Três desfechos:
+
+- **achou noutro lugar** → reancore para lá
+- **o trecho foi renomeado** (a função virou outra coisa) → reancore para o nome novo, e
+  confira se a memória ainda descreve o que aquele código faz
+- **sumiu de vez** → o mundo mudou; siga para "a memória morreu"
+
+## Alterado: leia a memória ANTES de decidir
+
+Isto é o passo que o atalho pula. Abra a memória com \`ler_memoria\` e leia o **porquê** —
+não o título. A pergunta é:
+
+> A razão que fez esta memória existir continua verdadeira?
+
+Compare com o que mudou (\`git diff\` no alvo). Três desfechos, e cada um tem uma ação
+diferente:
+
+**1. A memória ainda vale** — o código mudou por perto, mas a razão externa continua de
+pé (o fornecedor continua limitando, o compliance continua exigindo). Resolva como "ainda
+vale": a linha de base passa a ser o estado atual.
+
+**2. A memória vale, mas o texto envelheceu** — a razão é a mesma, a descrição não bate
+mais com o código. **Edite a memória** e depois resolva. Resolver sem editar guarda uma
+memória que vai confundir quem a ler.
+
+**3. A razão deixou de existir** — o fornecedor mudou o limite, a lib foi trocada, a
+decisão foi revertida. Aí não é "ainda vale": é \`arquivar_memoria\` com motivo
+\`obsoleta\`. Se outra memória tomou o lugar, use \`--substituida-por\`.
+
+## Nunca faça
+
+**Não resolva em lote.** Cinco observações abertas são cinco perguntas diferentes; marcar
+todas como "ainda vale" é o mesmo que não ter medido nada.
+
+**Não decida sozinho pelo arquivamento.** Resolver "ainda vale" é reversível — a próxima
+deriva reabre. Arquivar tira a memória de circulação, e quem vier depois não saberá que
+ela existiu se você errar. Proponha ao humano.
+
+**Não edite o código para fechar a deriva.** Se o alvo mudou porque alguém corrigiu um
+bug, o código está certo e a memória é que precisa acompanhar.
+
+## O caso que parece deriva e não é
+
+Se o primeiro \`check\` de um projeto acusa tudo, isso não é deriva: é a **linha de base
+sendo adotada**. Medido numa rodada de teste — rodar o primeiro \`check\` com o código já
+alterado fixa o estado errado como base, e reverter para o valor correto passa a ser "a
 mudança". Rode \`check\` antes de editar, não depois.`,
     },
     {
         slug: "promover-ou-nao",
         descricao: `Decide se uma memória deve valer para todo projeto do espaço, ou continuar só neste. Invoque ao gravar ou revisar uma memória que parece falar de algo maior que o projeto — um limite de fornecedor, uma regra da organização, uma armadilha da linguagem. Também ao revisar as globais existentes.`,
         ferramentas: ["mcp__dd-harness__ler_memoria", "mcp__dd-harness__buscar_memoria", "mcp__dd-harness__promover_memoria"],
-        conteudo: `# Promover, ou não
-
-Memória global vale para **todo projeto do espaço, inclusive os que ainda não existem**.
-Ela chega ao contexto de qualquer sessão e dispara o alerta antes da edição, como as do
-próprio projeto.
-
-Isso é força e é risco: memória global errada **erra em escala**.
-
-## O teste, em uma pergunta
-
-> Se o próximo projeto repetir este erro, esta memória o teria evitado?
-
-Se a resposta for sim, é global. Se você precisa construir um cenário para chegar ao sim,
-não é.
-
-## O que passa
-
-A razão vem de **fora deste projeto** e continuaria valendo se o projeto não existisse:
-
-- **limite de fornecedor** — "o gateway recusa mais de N tentativas por contrato"
-- **regra da organização** — "todo repositório aqui exige revisão de dois"
-- **armadilha da linguagem ou da ferramenta** — "\`REVOKE\` por coluna não tem efeito
-  quando existe \`GRANT\` na tabela inteira"
-- **bug de terceiro com workaround** — "a versão X da lib quebra em Y; não subir"
-
-Repare no padrão: nenhuma delas menciona um arquivo deste repositório.
-
-## O que NÃO passa
-
-- **decisão deste projeto** — "aqui usamos Drizzle em vez de Prisma". Vale para um
-  projeto; noutro a escolha pode ser outra, e a memória global mentiria.
-- **acordo com um cliente específico** — é do projeto daquele cliente.
-- **algo ancorado num arquivo deste repositório** — se a âncora aponta para
-  \`src/pagamento.js\`, a memória fala deste código. Para alcançar alguns projetos
-  nomeados, existe \`projetos:\` no frontmatter, que é uma **lista** — diferente de global,
-  que é uma propriedade.
-- **"é interessante para todos saberem"** — interessante não é o critério. O critério é
-  o erro que ela evita.
-
-## A ordem importa
-
-**Grave no projeto primeiro. Promova depois.**
-
-A memória nasce onde a lição apareceu, e continua morando lá mesmo depois de promovida —
-a origem é metade do porquê. *"Descobrimos isto no projeto de pagamentos"* explica a
-lição de um jeito que uma origem apagada não explicaria.
-
-## Proponha, não promova
-
-Promover multiplica o alcance. Leve ao humano com:
-
-1. **o teste respondido** — qual erro futuro ela evita, em que projeto plausível
-2. **por que não é deste projeto** — a razão externa, nomeada
-3. **o que acontece se estiver errada** — ela vai chegar a todo projeto do espaço
-
-Só então \`promover_memoria\`.
-
-## Revisar as globais
-
-É reversível: \`promover_memoria\` com \`global: false\` traz de volta. Ao revisar o acervo
-global, reaplique o teste em cada uma — uma memória que era global e virou específica
-(porque o fornecedor mudou, porque a regra caiu) deve voltar ao projeto, não ficar.
-
-**Uma trava a conhecer:** uma global sem vínculo com projeto algum **não pode ser
+        conteudo: `# Promover, ou não
+
+Memória global vale para **todo projeto do espaço, inclusive os que ainda não existem**.
+Ela chega ao contexto de qualquer sessão e dispara o alerta antes da edição, como as do
+próprio projeto.
+
+Isso é força e é risco: memória global errada **erra em escala**.
+
+## O teste, em uma pergunta
+
+> Se o próximo projeto repetir este erro, esta memória o teria evitado?
+
+Se a resposta for sim, é global. Se você precisa construir um cenário para chegar ao sim,
+não é.
+
+## O que passa
+
+A razão vem de **fora deste projeto** e continuaria valendo se o projeto não existisse:
+
+- **limite de fornecedor** — "o gateway recusa mais de N tentativas por contrato"
+- **regra da organização** — "todo repositório aqui exige revisão de dois"
+- **armadilha da linguagem ou da ferramenta** — "\`REVOKE\` por coluna não tem efeito
+  quando existe \`GRANT\` na tabela inteira"
+- **bug de terceiro com workaround** — "a versão X da lib quebra em Y; não subir"
+
+Repare no padrão: nenhuma delas menciona um arquivo deste repositório.
+
+## O que NÃO passa
+
+- **decisão deste projeto** — "aqui usamos Drizzle em vez de Prisma". Vale para um
+  projeto; noutro a escolha pode ser outra, e a memória global mentiria.
+- **acordo com um cliente específico** — é do projeto daquele cliente.
+- **algo ancorado num arquivo deste repositório** — se a âncora aponta para
+  \`src/pagamento.js\`, a memória fala deste código. Para alcançar alguns projetos
+  nomeados, existe \`projetos:\` no frontmatter, que é uma **lista** — diferente de global,
+  que é uma propriedade.
+- **"é interessante para todos saberem"** — interessante não é o critério. O critério é
+  o erro que ela evita.
+
+## A ordem importa
+
+**Grave no projeto primeiro. Promova depois.**
+
+A memória nasce onde a lição apareceu, e continua morando lá mesmo depois de promovida —
+a origem é metade do porquê. *"Descobrimos isto no projeto de pagamentos"* explica a
+lição de um jeito que uma origem apagada não explicaria.
+
+## Proponha, não promova
+
+Promover multiplica o alcance. Leve ao humano com:
+
+1. **o teste respondido** — qual erro futuro ela evita, em que projeto plausível
+2. **por que não é deste projeto** — a razão externa, nomeada
+3. **o que acontece se estiver errada** — ela vai chegar a todo projeto do espaço
+
+Só então \`promover_memoria\`.
+
+## Revisar as globais
+
+É reversível: \`promover_memoria\` com \`global: false\` traz de volta. Ao revisar o acervo
+global, reaplique o teste em cada uma — uma memória que era global e virou específica
+(porque o fornecedor mudou, porque a regra caiu) deve voltar ao projeto, não ficar.
+
+**Uma trava a conhecer:** uma global sem vínculo com projeto algum **não pode ser
 despromovida** — isso a deixaria invisível. Vincule-a a um projeto antes, ou apague.`,
     },
     {
         slug: "escrever-skill",
         descricao: `Escreve uma skill que o modelo de fato invoca e segue, em vez de uma que existe e nunca dispara. Invoque ao criar ou revisar uma skill deste projeto — ou quando notar que um procedimento já foi explicado três vezes e devia estar escrito.`,
         ferramentas: ["mcp__dd-harness__listar_skills", "Read"],
-        conteudo: `# Escrever uma skill que funciona
-
-A falha mais comum de skill não é estar errada — é **nunca disparar**. Ela existe, o
-procedimento está certo, e o modelo nunca a invoca. Não há erro, ninguém descobre, e o
-esforço de escrevê-la some.
-
-O segundo modo de falha é ser prosa: um texto que descreve o assunto em vez de dar os
-passos, e que o modelo lê sem mudar nada do que ia fazer.
-
-## Antes: isto é mesmo uma skill?
-
-Três filtros, **conjuntivos**. Falhou um, não escreva.
-
-| # | Filtro | A pergunta | É skill se |
-|---|---|---|---|
-| 1 | **Repetição consumada** | Isto já foi executado três vezes, em sessões diferentes? | sim — a terceira, não a segunda |
-| 2 | **Passos, não conhecimento** | É uma sequência que se executa, ou um fato que se sabe? | passos — fato é memória |
-| 3 | **Estável** | Os passos seriam os mesmos daqui a três meses? | sim — o que muda a cada uso é prosa |
-
-"Seria conveniente ter" não é repetição. "Fiz duas vezes" não é três.
-
-Chame \`listar_skills\` antes: se já existe uma que cobre o assunto, **edite aquela**. Duas
-skills parecidas competem pela invocação, e o modelo escolhe mal entre elas.
-
-## A descrição é metade do trabalho
-
-É o **único campo que o modelo lê antes de decidir** invocar, e ele fica no contexto de
-toda sessão — inclusive nas que não usam a skill.
-
-**Escreva o gatilho, não o resumo.** A pergunta que a descrição responde é *"quando eu
-deveria parar e usar isto?"*, não *"o que isto é?"*.
-
-| Descrição ruim | Por quê |
-|---|---|
-| "Ajuda com memórias" | não diz quando; nunca dispara |
-| "Procedimento de gravação" | descreve a skill, não a situação |
-| "Use esta skill para gravar" | circular |
-
-| Descrição boa | Por quê |
-|---|---|
-| "Invoque ao gravar memória que descreve um arquivo, função ou chave de config" | nomeia a situação |
-| "Invoque ao ver ALVO AUSENTE no resultado de \`dd-harness check\`" | nomeia o gatilho literal |
-
-**Diga também quando NÃO usar**, se houver confusão provável com outra skill. Uma linha de
-exclusão evita a skill errada disparar.
-
-## O corpo: passos e decisões, não explicação
-
-O corpo só entra no contexto quando a skill é invocada — aqui cabe detalhe. Mas detalhe
-não é prosa.
-
-- **Numere o que tem ordem.** Se a ordem não importa, não numere.
-- **Escreva a decisão, não só a ação.** "Escolha o alvo" não ajuda; "prefira
-  \`arquivo#trecho\` porque âncora de arquivo dispara para a memória errada" ajuda.
-- **Nomeie o caminho errado atraente.** Toda skill que vale existe porque há um atalho
-  tentador — diga qual é e por que ele custa caro. Sem isso o modelo pega o atalho.
-- **Traga a medição, quando houver.** "Medido: duas memórias no mesmo arquivo eram as
-  duas sinalizadas" vale mais que "pode gerar ruído".
-- **Tabelas para distinguir casos.** Bom/ruim lado a lado decide mais rápido que dois
-  parágrafos.
-
-Se o corpo só repete o que a descrição de uma ferramenta MCP já diz, **não escreva a
-skill** — a ferramenta já ensina isso, e melhor.
-
-## O frontmatter faz diferença
-
-- **\`allowed-tools\`** — as ferramentas que a skill usa. Sem isso ela para a cada passo
-  pedindo permissão, e a pessoa aprende a desligar o mecanismo.
-- **\`paths\`** — globs que carregam a skill só quando o trabalho toca aqueles arquivos. É
-  a mesma ideia da âncora, aplicada ao procedimento. Glob largo demais é uma skill sempre
-  presente, que era o que o campo existia para evitar.
-- **\`disable-model-invocation: true\`** (na interface, "só por comando") — para skill com
-  efeito colateral, onde o momento é de quem digita.
-- **\`argument-hint\`** — só quando a skill recebe argumento.
-
-## Depois de escrever
-
-**Releia a descrição sozinha**, sem o corpo. Se você não souber dizer em que momento
-invocá-la, o modelo também não saberá.
-
-Skill deste projeto vive no serviço: o repositório guarda só o ponteiro, e o
-\`dd-harness start\` o reescreve. Se você mudou a descrição, rode-o — o frontmatter em
+        conteudo: `# Escrever uma skill que funciona
+
+A falha mais comum de skill não é estar errada — é **nunca disparar**. Ela existe, o
+procedimento está certo, e o modelo nunca a invoca. Não há erro, ninguém descobre, e o
+esforço de escrevê-la some.
+
+O segundo modo de falha é ser prosa: um texto que descreve o assunto em vez de dar os
+passos, e que o modelo lê sem mudar nada do que ia fazer.
+
+## Antes: isto é mesmo uma skill?
+
+Três filtros, **conjuntivos**. Falhou um, não escreva.
+
+| # | Filtro | A pergunta | É skill se |
+|---|---|---|---|
+| 1 | **Repetição consumada** | Isto já foi executado três vezes, em sessões diferentes? | sim — a terceira, não a segunda |
+| 2 | **Passos, não conhecimento** | É uma sequência que se executa, ou um fato que se sabe? | passos — fato é memória |
+| 3 | **Estável** | Os passos seriam os mesmos daqui a três meses? | sim — o que muda a cada uso é prosa |
+
+"Seria conveniente ter" não é repetição. "Fiz duas vezes" não é três.
+
+Chame \`listar_skills\` antes: se já existe uma que cobre o assunto, **edite aquela**. Duas
+skills parecidas competem pela invocação, e o modelo escolhe mal entre elas.
+
+## A descrição é metade do trabalho
+
+É o **único campo que o modelo lê antes de decidir** invocar, e ele fica no contexto de
+toda sessão — inclusive nas que não usam a skill.
+
+**Escreva o gatilho, não o resumo.** A pergunta que a descrição responde é *"quando eu
+deveria parar e usar isto?"*, não *"o que isto é?"*.
+
+| Descrição ruim | Por quê |
+|---|---|
+| "Ajuda com memórias" | não diz quando; nunca dispara |
+| "Procedimento de gravação" | descreve a skill, não a situação |
+| "Use esta skill para gravar" | circular |
+
+| Descrição boa | Por quê |
+|---|---|
+| "Invoque ao gravar memória que descreve um arquivo, função ou chave de config" | nomeia a situação |
+| "Invoque ao ver ALVO AUSENTE no resultado de \`dd-harness check\`" | nomeia o gatilho literal |
+
+**Diga também quando NÃO usar**, se houver confusão provável com outra skill. Uma linha de
+exclusão evita a skill errada disparar.
+
+## O corpo: passos e decisões, não explicação
+
+O corpo só entra no contexto quando a skill é invocada — aqui cabe detalhe. Mas detalhe
+não é prosa.
+
+- **Numere o que tem ordem.** Se a ordem não importa, não numere.
+- **Escreva a decisão, não só a ação.** "Escolha o alvo" não ajuda; "prefira
+  \`arquivo#trecho\` porque âncora de arquivo dispara para a memória errada" ajuda.
+- **Nomeie o caminho errado atraente.** Toda skill que vale existe porque há um atalho
+  tentador — diga qual é e por que ele custa caro. Sem isso o modelo pega o atalho.
+- **Traga a medição, quando houver.** "Medido: duas memórias no mesmo arquivo eram as
+  duas sinalizadas" vale mais que "pode gerar ruído".
+- **Tabelas para distinguir casos.** Bom/ruim lado a lado decide mais rápido que dois
+  parágrafos.
+
+Se o corpo só repete o que a descrição de uma ferramenta MCP já diz, **não escreva a
+skill** — a ferramenta já ensina isso, e melhor.
+
+## O frontmatter faz diferença
+
+- **\`allowed-tools\`** — as ferramentas que a skill usa. Sem isso ela para a cada passo
+  pedindo permissão, e a pessoa aprende a desligar o mecanismo.
+- **\`paths\`** — globs que carregam a skill só quando o trabalho toca aqueles arquivos. É
+  a mesma ideia da âncora, aplicada ao procedimento. Glob largo demais é uma skill sempre
+  presente, que era o que o campo existia para evitar.
+- **\`disable-model-invocation: true\`** (na interface, "só por comando") — para skill com
+  efeito colateral, onde o momento é de quem digita.
+- **\`argument-hint\`** — só quando a skill recebe argumento.
+
+## Depois de escrever
+
+**Releia a descrição sozinha**, sem o corpo. Se você não souber dizer em que momento
+invocá-la, o modelo também não saberá.
+
+Skill deste projeto vive no serviço: o repositório guarda só o ponteiro, e o
+\`dd-harness start\` o reescreve. Se você mudou a descrição, rode-o — o frontmatter em
 disco não muda sozinho.`,
     },
     {
         slug: "propor-ferramentas",
         descricao: `Pesquisa e propõe MCP servers, skills e bibliotecas que combinem com a stack deste projeto, validando cada candidato contra fonte antes de sugerir. Invoque logo após concluir o briefing — é quando a stack acabou de ser descrita — ou quando a stack mudar. Só propõe: nada é instalado sem OK, e recusar tudo é resposta válida.`,
         ferramentas: ["mcp__dd-harness__ler_artefato", "mcp__dd-harness__listar_skills", "mcp__dd-harness__buscar_memoria", "Read", "Glob", "Grep", "WebSearch", "WebFetch"],
-        conteudo: `# Propor ferramentas para este projeto
-
-O briefing acabou de descrever a stack e as restrições. Este é o único momento em que
-esse contexto está fresco — depois dele, ninguém pergunta de novo, e uma ferramenta que
-faria diferença aqui nunca é considerada.
-
-Roda em subagente (\`context: fork\`): o conteúdo bruto das buscas fica lá, e só a proposta
-volta. Por isso leia tudo do serviço no passo 1 — não conte com o histórico da conversa.
-
-> **Só PROPÕE.** Não instala MCP, não cria skill, não adiciona dependência. Cada adoção é
-> uma tarefa nova, com plano e OK. **Recusar tudo é resposta válida e esperada** — se o
-> usuário não quiser nada, não insista.
-
-## 1. O que já existe (antes de buscar qualquer coisa)
-
-Propor o que o projeto já tem gasta a confiança na proposta inteira.
-
-- **Stack, objetivo e restrições:** \`ler_artefato\` com \`tipo: "briefing"\`. As restrições
-  são **filtro duro** — sugestão que as viola precisa ser marcada como tal, ou descartada.
-- **Skills já existentes:** \`listar_skills\`. Duas skills parecidas competem pela
-  invocação, e o modelo escolhe mal entre elas.
-- **MCP e hooks já ligados:** leia \`.mcp.json\` e \`.claude/settings.json\` do repositório —
-  esses continuam em disco, porque é deles que o host lê.
-- **O que já foi rejeitado:** \`buscar_memoria\` pelo nome de cada candidato antes de
-  propô-lo. Pode haver memória dizendo "não usar X porque Y" — repropor o que foi
-  descartado é o erro que mais rápido faz a proposta ser ignorada.
-
-Briefing vazio: **pare e avise**. Sem a stack, a busca não tem filtro e a proposta vira
-lista genérica — que é pior que nenhuma.
-
-## 2. Pesquise com a stack no filtro
-
-Busque informação **atual** (\`WebSearch\`, \`WebFetch\`), não memória. Três categorias:
-
-- **MCP servers** — o que daria ao agente acesso a algo que hoje ele não alcança neste
-  projeto (o banco, o deploy, o rastreador de issues).
-- **Skills** — procedimento repetido que já exista escrito e testado por outros.
-- **Libs e ferramentas** — do ecossistema da stack, para o problema que o projeto tem.
-
-Ancore cada busca na stack real. "Melhores ferramentas de 2026" devolve lista de blog;
-"MCP server para Postgres com RLS" devolve o que serve aqui.
-
-## 3. Valide contra fonte — não contra memória
-
-Para todo candidato, responda com link:
-
-- **Existe de fato?** Repositório, doc ou pacote oficial.
-- **É mantido?** Último release ou commit. Abandonado → descarte ou marque o risco.
-- **Casa com a stack?** Versão da linguagem, do framework, do runtime.
-- **Respeita as restrições?** Confronte com o briefing. Conflito → **diga**, não esconda.
-- **Já não temos equivalente?** Confronte com o passo 1.
-
-Candidato que não passa: **descarte e diga por quê, em uma linha.** Não infle a lista —
-três propostas boas valem mais que dez, e uma lista longa faz o usuário recusar tudo sem
-ler.
-
-## 4. Apresente
-
-Para cada proposta: **o que é**, **o problema deste projeto que ela resolve**, **o custo**
-(dependência nova, chave de API, processo a manter) e o **link**. Nessa ordem — o
-problema antes da solução, senão parece catálogo.
-
-Separe o que é **recomendação** do que é **possibilidade**. Se nada passou na validação,
-diga isso: "não achei nada que valha para esta stack agora" é uma resposta honesta e
-útil.
-
-## 5. Se algo for adotado
-
-Adotar é tarefa nova: plano curto, OK do usuário, e o protocolo normal do projeto.
-
-Se a decisão vier com uma razão que sobrevive ao dia de hoje — "escolhemos X porque o
-fornecedor limita Y" —, isso pode ser memória. Passe pelos três filtros antes de gravar;
+        conteudo: `# Propor ferramentas para este projeto
+
+O briefing acabou de descrever a stack e as restrições. Este é o único momento em que
+esse contexto está fresco — depois dele, ninguém pergunta de novo, e uma ferramenta que
+faria diferença aqui nunca é considerada.
+
+Roda em subagente (\`context: fork\`): o conteúdo bruto das buscas fica lá, e só a proposta
+volta. Por isso leia tudo do serviço no passo 1 — não conte com o histórico da conversa.
+
+> **Só PROPÕE.** Não instala MCP, não cria skill, não adiciona dependência. Cada adoção é
+> uma tarefa nova, com plano e OK. **Recusar tudo é resposta válida e esperada** — se o
+> usuário não quiser nada, não insista.
+
+## 1. O que já existe (antes de buscar qualquer coisa)
+
+Propor o que o projeto já tem gasta a confiança na proposta inteira.
+
+- **Stack, objetivo e restrições:** \`ler_artefato\` com \`tipo: "briefing"\`. As restrições
+  são **filtro duro** — sugestão que as viola precisa ser marcada como tal, ou descartada.
+- **Skills já existentes:** \`listar_skills\`. Duas skills parecidas competem pela
+  invocação, e o modelo escolhe mal entre elas.
+- **MCP e hooks já ligados:** leia \`.mcp.json\` e \`.claude/settings.json\` do repositório —
+  esses continuam em disco, porque é deles que o host lê.
+- **O que já foi rejeitado:** \`buscar_memoria\` pelo nome de cada candidato antes de
+  propô-lo. Pode haver memória dizendo "não usar X porque Y" — repropor o que foi
+  descartado é o erro que mais rápido faz a proposta ser ignorada.
+
+Briefing vazio: **pare e avise**. Sem a stack, a busca não tem filtro e a proposta vira
+lista genérica — que é pior que nenhuma.
+
+## 2. Pesquise com a stack no filtro
+
+Busque informação **atual** (\`WebSearch\`, \`WebFetch\`), não memória. Três categorias:
+
+- **MCP servers** — o que daria ao agente acesso a algo que hoje ele não alcança neste
+  projeto (o banco, o deploy, o rastreador de issues).
+- **Skills** — procedimento repetido que já exista escrito e testado por outros.
+- **Libs e ferramentas** — do ecossistema da stack, para o problema que o projeto tem.
+
+Ancore cada busca na stack real. "Melhores ferramentas de 2026" devolve lista de blog;
+"MCP server para Postgres com RLS" devolve o que serve aqui.
+
+## 3. Valide contra fonte — não contra memória
+
+Para todo candidato, responda com link:
+
+- **Existe de fato?** Repositório, doc ou pacote oficial.
+- **É mantido?** Último release ou commit. Abandonado → descarte ou marque o risco.
+- **Casa com a stack?** Versão da linguagem, do framework, do runtime.
+- **Respeita as restrições?** Confronte com o briefing. Conflito → **diga**, não esconda.
+- **Já não temos equivalente?** Confronte com o passo 1.
+
+Candidato que não passa: **descarte e diga por quê, em uma linha.** Não infle a lista —
+três propostas boas valem mais que dez, e uma lista longa faz o usuário recusar tudo sem
+ler.
+
+## 4. Apresente
+
+Para cada proposta: **o que é**, **o problema deste projeto que ela resolve**, **o custo**
+(dependência nova, chave de API, processo a manter) e o **link**. Nessa ordem — o
+problema antes da solução, senão parece catálogo.
+
+Separe o que é **recomendação** do que é **possibilidade**. Se nada passou na validação,
+diga isso: "não achei nada que valha para esta stack agora" é uma resposta honesta e
+útil.
+
+## 5. Se algo for adotado
+
+Adotar é tarefa nova: plano curto, OK do usuário, e o protocolo normal do projeto.
+
+Se a decisão vier com uma razão que sobrevive ao dia de hoje — "escolhemos X porque o
+fornecedor limita Y" —, isso pode ser memória. Passe pelos três filtros antes de gravar;
 "experimentamos e gostamos" não passa em nenhum deles.`,
     },
     {
@@ -464,143 +464,143 @@ fornecedor limita Y" —, isso pode ser memória. Passe pelos três filtros ante
         ferramentas: ["mcp__dd-harness__ler_changelog", "Read", "Glob", "Grep", "Edit", "Bash"],
         so_por_comando: true,
         dica_de_argumento: "<caminho da pasta do projeto>",
-        conteudo: `# Atualizar o harness de um projeto
-
-Põe um projeto que consome o dd-harness na versão atual: CLI, hooks, e o bloco do
-protocolo nos pontos de entrada (\`CLAUDE.md\` e \`AGENTS.md\`).
-
-**Entrada esperada:** o caminho da pasta do projeto. Se o usuário não passou, pergunte —
-não presuma que é o diretório atual, porque esta skill quase sempre roda apontando para
-OUTRO projeto.
-
----
-
-## 0. Antes de tudo: entenda o \`CLAUDE.md\` do alvo
-
-**Este é o passo mais importante da skill, e o único que não dá para automatizar.** Faça-o
-antes de rodar qualquer comando que escreva.
-
-O \`CLAUDE.md\` **é do projeto, não do dd-harness**. Cada um escreve o seu: regras de
-negócio, combinados da equipe, jeito de trabalhar daquele time. O harness ocupa ali um
-bloco delimitado — e **só esse bloco é nosso**.
-
-Leia o arquivo inteiro e responda, para você mesmo, três perguntas:
-
-1. **O que ali é do harness?** O bloco entre \`<!-- dd-harness:inicio ... -->\` e
-   \`<!-- dd-harness:fim -->\`. Se não houver marcas, o bloco é o trecho que fala de
-   \`ler_artefato\`/\`ler_roadmap\`/\`listar_skills\` — o protocolo que o molde escreve.
-
-2. **O que ali é do projeto?** Todo o resto. Regras próprias, seções inventadas pelo time,
-   uma linha que alguém acrescentou numa sexta-feira e não explicou. **Nada disso se toca.**
-
-3. **Alguém escreveu dentro do bloco?** É o caso que exige você. Uma regra do projeto pode
-   ter sido acrescentada lá dentro por conveniência — e ela tem que sobreviver à
-   atualização. Perceber isso é a diferença entre atualizar e destruir.
-
-> Já aconteceu: uma linha escrita à mão pelo dono do projeto foi tratada como texto do
-> molde e sobrescrita. Ele teve que dizer "é pq eu botei la". O arquivo é dele; a régua é
-> essa.
-
-**Regra que resume tudo:** na dúvida sobre se um trecho é nosso ou do projeto, **é do
-projeto**. Pergunte em vez de decidir.
-
----
-
-## 1. Diagnostique
-
-\`\`\`
-cd <caminho-do-projeto>
-dd-harness atualizar
-\`\`\`
-
-Ele relata, sem escrever nada, quatro coisas: a versão do CLI, o estado do bloco em
-\`CLAUDE.md\` e \`AGENTS.md\`, e os hooks. Cada item vem com uma ação:
-
-| Marca | Significa |
-|---|---|
-| \`ok\` | em dia, nada a fazer |
-| \`->\` | pode ser aplicado com segurança |
-| \`??\` | **exige decisão sua** — arquivo editado a mão |
-| \`!\` | manual (o CLI global é por máquina, não por projeto) |
-
-## 2. Descubra o que mudou
-
-O bloco carimba a versão do molde (ex: \`v1.2.0\`). Compare com a atual e leia, no
-\`CHANGELOG.md\` do dd-harness, o que mudou entre as duas. É isso que diz **o que** está
-chegando ao projeto — e permite explicar ao usuário, em vez de só dizer "atualizei".
-
-Se a diferença não mexe com o projeto, diga isso: atualização que não muda nada é
-informação útil, não fracasso.
-
-## 3. Aplique o seguro
-
-\`\`\`
-dd-harness atualizar --aplicar
-\`\`\`
-
-Isto escreve **só** os itens \`->\`: troca o miolo do bloco, acrescenta hooks que faltam,
-cria o arquivo que não existe. O que está fora do bloco não é lido nem reescrito.
-
-Os itens \`??\` ficam intactos de propósito — o comando não os toca.
-
-## 4a. Skills que faltam: apresente e pergunte, uma a uma
-
-O item \`?? skills\` lista as skills iniciais que **não estão** neste projeto. Elas caem em
-dois casos que, de fora, são **indistinguíveis**:
-
-- **Nasceu depois deste projeto.** A semeadura só roda em projeto sem skill alguma, então
-  skill nova nunca chega sozinha a um projeto que já existe.
-- **Foi apagada de propósito.** Skill é apagável, e quem apagou tomou uma decisão.
-
-**Nunca recrie sem perguntar.** Incorporar a lista inteira desfaz a segunda decisão em
-silêncio, e desfaz de novo a cada vez que alguém rodar o comando.
-
-Para cada skill faltante, apresente ao usuário:
-
-1. **O nome e o que ela faz** — o diagnóstico já imprime a descrição completa; ela é o
-   campo que diz *quando* a skill serve
-2. **Por que ela pode importar aqui**, com base neste projeto: a stack, o que existe no
-   repositório, o que o BRIEFING diz. "Este projeto tem Brain com âncoras, então
-   \`resolver-deriva\` teria uso" vale mais que repetir a descrição
-3. **A pergunta**: incorporar esta?
-
-Aceite "não" sem insistir. Uma skill recusada é uma decisão do dono, não um item pendente —
-e se ele disser "não" para a mesma skill de novo no mês que vem, isso é sinal de que a
-resposta já está dada.
-
-Com a lista do que ele aceitou, incorpore só essas. Os ponteiros em disco são escritos
-junto; sem eles a skill existe no serviço e host nenhum a descobre.
-
-## 4b. Conduza os outros casos que exigem decisão
-
-Para cada item \`??\` restante, faça o trabalho que o comando não pode fazer:
-
-1. **Mostre ao usuário o que está lá** e o que o molde novo traz.
-2. **Diga o que você acha que aconteceu** — "parece que você acrescentou esta linha
-   sobre o Slack dentro do nosso bloco".
-3. **Proponha o encaixe**, que quase sempre é: manter a linha dele, atualizar o resto, e
-   sugerir mover a linha dele para FORA do bloco, para não conflitar de novo na próxima
-   versão. Essa sugestão é o que impede o problema de se repetir.
-4. **Aguarde o OK.** Nunca edite um bloco \`??\` sem resposta explícita.
-
-## 5. O CLI global
-
-Se o diagnóstico marcou o CLI com \`!\`, o comando é:
-
-\`\`\`
-npm i -g dd-harness@latest
-\`\`\`
-
-Diga ao usuário que isso vale para **a máquina**, não para o projeto — rodar em cada pasta
-não muda nada, e ele só precisa fazer isso uma vez.
-
-## 6. Feche
-
-Relate, em poucas linhas: o que foi atualizado, de que versão para qual, o que ficou
-pendente de decisão e por quê. Se você tocou em \`CLAUDE.md\`, **diga explicitamente que o
-que estava fora do bloco continua intacto** — é a garantia que o usuário quer ouvir.
-
-Se o projeto tem git, sugira conferir o diff antes de commitar. Não commite: o projeto é
+        conteudo: `# Atualizar o harness de um projeto
+
+Põe um projeto que consome o dd-harness na versão atual: CLI, hooks, e o bloco do
+protocolo nos pontos de entrada (\`CLAUDE.md\` e \`AGENTS.md\`).
+
+**Entrada esperada:** o caminho da pasta do projeto. Se o usuário não passou, pergunte —
+não presuma que é o diretório atual, porque esta skill quase sempre roda apontando para
+OUTRO projeto.
+
+---
+
+## 0. Antes de tudo: entenda o \`CLAUDE.md\` do alvo
+
+**Este é o passo mais importante da skill, e o único que não dá para automatizar.** Faça-o
+antes de rodar qualquer comando que escreva.
+
+O \`CLAUDE.md\` **é do projeto, não do dd-harness**. Cada um escreve o seu: regras de
+negócio, combinados da equipe, jeito de trabalhar daquele time. O harness ocupa ali um
+bloco delimitado — e **só esse bloco é nosso**.
+
+Leia o arquivo inteiro e responda, para você mesmo, três perguntas:
+
+1. **O que ali é do harness?** O bloco entre \`<!-- dd-harness:inicio ... -->\` e
+   \`<!-- dd-harness:fim -->\`. Se não houver marcas, o bloco é o trecho que fala de
+   \`ler_artefato\`/\`ler_roadmap\`/\`listar_skills\` — o protocolo que o molde escreve.
+
+2. **O que ali é do projeto?** Todo o resto. Regras próprias, seções inventadas pelo time,
+   uma linha que alguém acrescentou numa sexta-feira e não explicou. **Nada disso se toca.**
+
+3. **Alguém escreveu dentro do bloco?** É o caso que exige você. Uma regra do projeto pode
+   ter sido acrescentada lá dentro por conveniência — e ela tem que sobreviver à
+   atualização. Perceber isso é a diferença entre atualizar e destruir.
+
+> Já aconteceu: uma linha escrita à mão pelo dono do projeto foi tratada como texto do
+> molde e sobrescrita. Ele teve que dizer "é pq eu botei la". O arquivo é dele; a régua é
+> essa.
+
+**Regra que resume tudo:** na dúvida sobre se um trecho é nosso ou do projeto, **é do
+projeto**. Pergunte em vez de decidir.
+
+---
+
+## 1. Diagnostique
+
+\`\`\`
+cd <caminho-do-projeto>
+dd-harness atualizar
+\`\`\`
+
+Ele relata, sem escrever nada, quatro coisas: a versão do CLI, o estado do bloco em
+\`CLAUDE.md\` e \`AGENTS.md\`, e os hooks. Cada item vem com uma ação:
+
+| Marca | Significa |
+|---|---|
+| \`ok\` | em dia, nada a fazer |
+| \`->\` | pode ser aplicado com segurança |
+| \`??\` | **exige decisão sua** — arquivo editado a mão |
+| \`!\` | manual (o CLI global é por máquina, não por projeto) |
+
+## 2. Descubra o que mudou
+
+O bloco carimba a versão do molde (ex: \`v1.2.0\`). Compare com a atual e leia, no
+\`CHANGELOG.md\` do dd-harness, o que mudou entre as duas. É isso que diz **o que** está
+chegando ao projeto — e permite explicar ao usuário, em vez de só dizer "atualizei".
+
+Se a diferença não mexe com o projeto, diga isso: atualização que não muda nada é
+informação útil, não fracasso.
+
+## 3. Aplique o seguro
+
+\`\`\`
+dd-harness atualizar --aplicar
+\`\`\`
+
+Isto escreve **só** os itens \`->\`: troca o miolo do bloco, acrescenta hooks que faltam,
+cria o arquivo que não existe. O que está fora do bloco não é lido nem reescrito.
+
+Os itens \`??\` ficam intactos de propósito — o comando não os toca.
+
+## 4a. Skills que faltam: apresente e pergunte, uma a uma
+
+O item \`?? skills\` lista as skills iniciais que **não estão** neste projeto. Elas caem em
+dois casos que, de fora, são **indistinguíveis**:
+
+- **Nasceu depois deste projeto.** A semeadura só roda em projeto sem skill alguma, então
+  skill nova nunca chega sozinha a um projeto que já existe.
+- **Foi apagada de propósito.** Skill é apagável, e quem apagou tomou uma decisão.
+
+**Nunca recrie sem perguntar.** Incorporar a lista inteira desfaz a segunda decisão em
+silêncio, e desfaz de novo a cada vez que alguém rodar o comando.
+
+Para cada skill faltante, apresente ao usuário:
+
+1. **O nome e o que ela faz** — o diagnóstico já imprime a descrição completa; ela é o
+   campo que diz *quando* a skill serve
+2. **Por que ela pode importar aqui**, com base neste projeto: a stack, o que existe no
+   repositório, o que o BRIEFING diz. "Este projeto tem Brain com âncoras, então
+   \`resolver-deriva\` teria uso" vale mais que repetir a descrição
+3. **A pergunta**: incorporar esta?
+
+Aceite "não" sem insistir. Uma skill recusada é uma decisão do dono, não um item pendente —
+e se ele disser "não" para a mesma skill de novo no mês que vem, isso é sinal de que a
+resposta já está dada.
+
+Com a lista do que ele aceitou, incorpore só essas. Os ponteiros em disco são escritos
+junto; sem eles a skill existe no serviço e host nenhum a descobre.
+
+## 4b. Conduza os outros casos que exigem decisão
+
+Para cada item \`??\` restante, faça o trabalho que o comando não pode fazer:
+
+1. **Mostre ao usuário o que está lá** e o que o molde novo traz.
+2. **Diga o que você acha que aconteceu** — "parece que você acrescentou esta linha
+   sobre o Slack dentro do nosso bloco".
+3. **Proponha o encaixe**, que quase sempre é: manter a linha dele, atualizar o resto, e
+   sugerir mover a linha dele para FORA do bloco, para não conflitar de novo na próxima
+   versão. Essa sugestão é o que impede o problema de se repetir.
+4. **Aguarde o OK.** Nunca edite um bloco \`??\` sem resposta explícita.
+
+## 5. O CLI global
+
+Se o diagnóstico marcou o CLI com \`!\`, o comando é:
+
+\`\`\`
+npm i -g dd-harness@latest
+\`\`\`
+
+Diga ao usuário que isso vale para **a máquina**, não para o projeto — rodar em cada pasta
+não muda nada, e ele só precisa fazer isso uma vez.
+
+## 6. Feche
+
+Relate, em poucas linhas: o que foi atualizado, de que versão para qual, o que ficou
+pendente de decisão e por quê. Se você tocou em \`CLAUDE.md\`, **diga explicitamente que o
+que estava fora do bloco continua intacto** — é a garantia que o usuário quer ouvir.
+
+Se o projeto tem git, sugira conferir o diff antes de commitar. Não commite: o projeto é
 do usuário e as regras de commit dele são dele.`,
     },
     {
@@ -609,123 +609,123 @@ do usuário e as regras de commit dele são dele.`,
         ferramentas: ["mcp__dd-harness__ler_memoria", "mcp__dd-harness__buscar_memoria", "Read", "Grep", "Glob", "WebSearch", "WebFetch", "Bash(dd-harness status:*)", "Bash(dd-harness check:*)", "Bash(dd-harness ler:*)", "Bash(git log:*)", "Bash(git diff:*)"],
         so_por_comando: true,
         dica_de_argumento: "[pasta/slug para revisar uma só, ou vazio para varrer o acervo]",
-        conteudo: `# Revisar memória
-
-A deriva pega a memória cujo **código** mudou. Esta skill existe para a outra — a que
-ninguém olha há muito tempo e cuja **razão** pode ter morrido sem deixar rastro no
-repositório: o fornecedor mudou o limite, o bug de terceiro foi corrigido, a exigência de
-compliance caiu, a lib passou a fazer nativamente o que a memória ensina a contornar.
-
-Nenhum \`check\` acusa isso. O alvo está intacto; é o mundo que mudou.
-
-## A regra que não se quebra
-
-**Você não edita, não arquiva e não apaga. Nada.** Esta skill investiga e apresenta o
-caso; quem decide é o usuário, na conversa.
-
-Isso não é cautela decorativa: arquivar tira a memória de circulação, e quem vier depois
-não saberá que ela existiu se você errar. O custo dos dois erros é assimétrico — manter
-uma memória morta custa uma linha de índice; apagar uma viva custa o incidente que ela
-evitava, e ninguém vai ligar uma coisa à outra.
-
-## Idade não é veredito
-
-O critério tentador é "ninguém revisitou há muito tempo, logo não serve". **Está errado, e
-o ROADMAP deste projeto já registra por quê:** contagem baixa correlaciona com *raridade*,
-não com inutilidade — a memória que protege contra o erro raro e catastrófico é a que tem
-a contagem mais baixa de todas.
-
-Então idade é **motivo para olhar**, nunca argumento no parecer. Se o único fundamento que
-você tiver para propor a saída de uma memória for "é antiga", **você não tem fundamento**:
-relate como "continua valendo" e siga.
-
-## 1. Escolha as candidatas
-
-Com \`pasta/slug\` no argumento, é aquela — pule para o passo 2.
-
-Sem argumento, monte a lista nesta ordem:
-
-1. \`dd-harness status\` — as que ele já aponta como **revisão vencida** entram primeiro
-2. Memórias antigas que **nunca** tiveram deriva (código estável ao redor: é exatamente
-   onde esta skill enxerga o que o \`check\` não vê)
-3. As que citam **coisa de fora** — versão, fornecedor, limite, prazo, bug de terceiro:
-   são as que envelhecem sem avisar
-
-**Teto de cinco por rodada.** Cada memória é uma investigação de verdade; trazer quinze
-pareceres rasos é pior que trazer três com evidência, e o usuário não consegue decidir
-sobre quinze de uma vez.
-
-## 2. Leia a memória inteira — o porquê, não o título
-
-\`ler_memoria\`. A pergunta que governa tudo:
-
-> A razão que fez esta memória existir continua verdadeira **hoje**?
-
-Identifique de que tipo é a afirmação, porque cada uma se verifica num lugar diferente:
-
-| Tipo | Onde se confere |
-|---|---|
-| Sobre o código deste projeto | o próprio repositório |
-| Sobre lib, versão ou API | changelog, release notes, a doc atual |
-| Sobre fornecedor, limite ou contrato | a doc do fornecedor |
-| Sobre bug de terceiro | o issue: foi corrigido? |
-| Sobre decisão interna | o projeto ainda funciona assim? |
-
-## 3. Vá conferir — não opine
-
-Este é o passo que separa esta skill de um chute fundamentado.
-
-- **No repositório:** a âncora existe? O código ainda faz o que a memória descreve?
-  \`git log\` no alvo mostra que alguém mexeu naquilo?
-- **Fora:** quando a razão é externa, **procure a fonte**. Um \`WebSearch\` pela versão atual
-  da lib, pelo limite atual da API, pelo issue citado. Se a memória diz "a v3 não suporta
-  X" e a v5 suporta, isso é achado — e sem ir olhar você nunca saberia.
-
-Se não conseguir verificar, **diga que não conseguiu.** "Não achei fonte para confirmar o
-limite atual" é um parecer honesto e útil. Inventar uma conclusão para parecer produtivo é
-o pior resultado possível desta skill.
-
-## 4. Traga o parecer
-
-Um bloco por memória, na conversa. Curto, com a evidência à mostra:
-
-\`\`\`
-pasta/slug — Título
-
-  Diz: [a afirmação, em uma linha]
-  Verifiquei: [o que você foi olhar, com link/caminho/commit]
-  Achei: [o que encontrou de fato]
-  Parecer: continua valendo | envelheceu no texto | a razão pode ter morrido
-  Por quê: [o fundamento — nunca "é antiga"]
-\`\`\`
-
-Três pareceres possíveis, e nenhum é uma ação:
-
-**Continua valendo** — a razão está de pé. Diga isso e siga; não há trabalho a fazer.
-
-**Envelheceu no texto** — a razão continua, a descrição não bate mais. Mostre o trecho
-que está errado e o que seria o texto certo. O usuário decide se manda editar.
-
-**A razão pode ter morrido** — você encontrou evidência de que o motivo acabou. Mostre a
-evidência. Use "pode": você investigou, não sentenciou; pode haver contexto que a memória
-não registrou e o usuário conhece.
-
-Ao fim, uma linha só: quantas revisou, quantas continuam valendo, quantas merecem a
-atenção dele. Se nenhuma mereceu, **diga exatamente isso** — "revisei cinco, todas
-continuam valendo" é um resultado bom, não uma rodada perdida.
-
-## Nunca faça
-
-**Não proponha saída em lote.** Cinco memórias são cinco perguntas; um "essas cinco podem
-sair" é o mesmo que não ter investigado nenhuma.
-
-**Não use a data de revisão como argumento.** Ela é agenda, não julgamento. Uma memória
-vencida que você verificou e continua verdadeira é "continua valendo" — não "vencida".
-
-**Não confunda com deriva.** Se o achado é "o arquivo ancorado sumiu", isso é trabalho da
-\`resolver-deriva\`; diga ao usuário e aponte para lá em vez de resolver aqui.
-
-**Não vá pelo acervo inteiro.** O teto de cinco é o que mantém cada parecer com evidência.
+        conteudo: `# Revisar memória
+
+A deriva pega a memória cujo **código** mudou. Esta skill existe para a outra — a que
+ninguém olha há muito tempo e cuja **razão** pode ter morrido sem deixar rastro no
+repositório: o fornecedor mudou o limite, o bug de terceiro foi corrigido, a exigência de
+compliance caiu, a lib passou a fazer nativamente o que a memória ensina a contornar.
+
+Nenhum \`check\` acusa isso. O alvo está intacto; é o mundo que mudou.
+
+## A regra que não se quebra
+
+**Você não edita, não arquiva e não apaga. Nada.** Esta skill investiga e apresenta o
+caso; quem decide é o usuário, na conversa.
+
+Isso não é cautela decorativa: arquivar tira a memória de circulação, e quem vier depois
+não saberá que ela existiu se você errar. O custo dos dois erros é assimétrico — manter
+uma memória morta custa uma linha de índice; apagar uma viva custa o incidente que ela
+evitava, e ninguém vai ligar uma coisa à outra.
+
+## Idade não é veredito
+
+O critério tentador é "ninguém revisitou há muito tempo, logo não serve". **Está errado, e
+o ROADMAP deste projeto já registra por quê:** contagem baixa correlaciona com *raridade*,
+não com inutilidade — a memória que protege contra o erro raro e catastrófico é a que tem
+a contagem mais baixa de todas.
+
+Então idade é **motivo para olhar**, nunca argumento no parecer. Se o único fundamento que
+você tiver para propor a saída de uma memória for "é antiga", **você não tem fundamento**:
+relate como "continua valendo" e siga.
+
+## 1. Escolha as candidatas
+
+Com \`pasta/slug\` no argumento, é aquela — pule para o passo 2.
+
+Sem argumento, monte a lista nesta ordem:
+
+1. \`dd-harness status\` — as que ele já aponta como **revisão vencida** entram primeiro
+2. Memórias antigas que **nunca** tiveram deriva (código estável ao redor: é exatamente
+   onde esta skill enxerga o que o \`check\` não vê)
+3. As que citam **coisa de fora** — versão, fornecedor, limite, prazo, bug de terceiro:
+   são as que envelhecem sem avisar
+
+**Teto de cinco por rodada.** Cada memória é uma investigação de verdade; trazer quinze
+pareceres rasos é pior que trazer três com evidência, e o usuário não consegue decidir
+sobre quinze de uma vez.
+
+## 2. Leia a memória inteira — o porquê, não o título
+
+\`ler_memoria\`. A pergunta que governa tudo:
+
+> A razão que fez esta memória existir continua verdadeira **hoje**?
+
+Identifique de que tipo é a afirmação, porque cada uma se verifica num lugar diferente:
+
+| Tipo | Onde se confere |
+|---|---|
+| Sobre o código deste projeto | o próprio repositório |
+| Sobre lib, versão ou API | changelog, release notes, a doc atual |
+| Sobre fornecedor, limite ou contrato | a doc do fornecedor |
+| Sobre bug de terceiro | o issue: foi corrigido? |
+| Sobre decisão interna | o projeto ainda funciona assim? |
+
+## 3. Vá conferir — não opine
+
+Este é o passo que separa esta skill de um chute fundamentado.
+
+- **No repositório:** a âncora existe? O código ainda faz o que a memória descreve?
+  \`git log\` no alvo mostra que alguém mexeu naquilo?
+- **Fora:** quando a razão é externa, **procure a fonte**. Um \`WebSearch\` pela versão atual
+  da lib, pelo limite atual da API, pelo issue citado. Se a memória diz "a v3 não suporta
+  X" e a v5 suporta, isso é achado — e sem ir olhar você nunca saberia.
+
+Se não conseguir verificar, **diga que não conseguiu.** "Não achei fonte para confirmar o
+limite atual" é um parecer honesto e útil. Inventar uma conclusão para parecer produtivo é
+o pior resultado possível desta skill.
+
+## 4. Traga o parecer
+
+Um bloco por memória, na conversa. Curto, com a evidência à mostra:
+
+\`\`\`
+pasta/slug — Título
+
+  Diz: [a afirmação, em uma linha]
+  Verifiquei: [o que você foi olhar, com link/caminho/commit]
+  Achei: [o que encontrou de fato]
+  Parecer: continua valendo | envelheceu no texto | a razão pode ter morrido
+  Por quê: [o fundamento — nunca "é antiga"]
+\`\`\`
+
+Três pareceres possíveis, e nenhum é uma ação:
+
+**Continua valendo** — a razão está de pé. Diga isso e siga; não há trabalho a fazer.
+
+**Envelheceu no texto** — a razão continua, a descrição não bate mais. Mostre o trecho
+que está errado e o que seria o texto certo. O usuário decide se manda editar.
+
+**A razão pode ter morrido** — você encontrou evidência de que o motivo acabou. Mostre a
+evidência. Use "pode": você investigou, não sentenciou; pode haver contexto que a memória
+não registrou e o usuário conhece.
+
+Ao fim, uma linha só: quantas revisou, quantas continuam valendo, quantas merecem a
+atenção dele. Se nenhuma mereceu, **diga exatamente isso** — "revisei cinco, todas
+continuam valendo" é um resultado bom, não uma rodada perdida.
+
+## Nunca faça
+
+**Não proponha saída em lote.** Cinco memórias são cinco perguntas; um "essas cinco podem
+sair" é o mesmo que não ter investigado nenhuma.
+
+**Não use a data de revisão como argumento.** Ela é agenda, não julgamento. Uma memória
+vencida que você verificou e continua verdadeira é "continua valendo" — não "vencida".
+
+**Não confunda com deriva.** Se o achado é "o arquivo ancorado sumiu", isso é trabalho da
+\`resolver-deriva\`; diga ao usuário e aponte para lá em vez de resolver aqui.
+
+**Não vá pelo acervo inteiro.** O teto de cinco é o que mantém cada parecer com evidência.
 Fila é para ser processada aos poucos, e ela não vai a lugar nenhum.`,
     },
 ];