$docdiet
Use este skill apenas quando o usuário solicitar explicitamente uma revisão, limpeza ou atualização de documentação (normalmente invocando $docdiet). É um skill de revisão/atualização sob demanda e isolado, não um gancho automático por tarefa. Revise ou atualize apenas o escopo de documentação nomeado pelo usuário ou claramente exposto pela alteração solicitada; não inicie uma auditoria não relacionada.
Uma solicitação explícita como $docdiet all docs ou $docdiet project-wide autoriza uma varredura delimitada em todo o projeto. Nesse modo, o escopo é limitado a arquivos de documentação sob a raiz do repositório com extensões .md, .mdx, .rst ou .adoc, além de arquivos README* e CONTRIBUTING* na raiz. Exclua diretórios e arquivos gerados ou de terceiros, changelogs/notas de versão, licenças ou material legal, códigos de conduta e arquivos protegidos pelo repositório. A descoberta é limitada a uma listagem rg --files usando essas extensões e exclusões, com limite de 200 caminhos; inspecione apenas os caminhos retornados por essa listagem. Use no máximo uma pesquisa de referência exata adicional, com caminho limitado (rg -l -F), para um conceito público alterado. Se o limite ou o limite da pesquisa for atingido, relate o restante não revisado em vez de expandir o escopo.
Regras de decisão
- Primeiro, limite o escopo. Se nenhum arquivo ou seção de documentação for nomeado, nenhuma documentação estiver sendo tocada e nenhuma renomeação/remoção pública precisar de verificação de referência, pare. Não inspecione a documentação para decidir se deve inspecionar a documentação.
- Edite a fonte canônica. Documente apenas informações duráveis que desenvolvedores, usuários, operadores ou mantenedores precisam: contratos, configuração, operações, restrições, invariantes, comportamento não óbvio, migrações e avisos críticos. Omita triviais de implementação, estado temporário, histórico de depuração, fatos inferidos e resumos de conclusão.
- Substitua, não acumule. Atualize a explicação existente, remova texto obsoleto e vincule a uma fonte canônica quando outro documento precisar de um ponteiro. Mantenha detalhes históricos apenas para migração, compatibilidade ou justificativa arquitetural.
- Mantenha a limpeza local. Ao editar um arquivo de documentação, limpe apenas a seção tocada e o texto próximo que tenha evidência clara de estar desatualizado, duplicado, contraditório, substituído, enganoso, desnecessariamente verboso ou vinculado ao conceito alterado/removido. Se a evidência exigir investigação substancial, deixe-o como está.
- Limite as pesquisas de referência. Para um conceito público renomeado, removido ou alterado, no máximo uma pesquisa exata com caminho limitado é permitida. Prefira
rg -l -Fcom globs de documentação e relate nomes de arquivos, não linhas completas correspondentes. Fora do modo explícito de varredura em todo o projeto acima, não faça inventário de documentação não relacionada, navegue por árvores de documentação, execute verificações de links em todo o repositório, investigue histórico não relacionado ou crie um agente de limpeza. - Crie arquivos raramente. Adicione um arquivo de documentação apenas para informações duráveis e distintas sem um lar canônico adequado já conhecido da tarefa.
Proteção
Não reescreva oportunisticamente documentação gerada, changelogs/notas de versão, licenças ou material legal, códigos de conduta, documentação de terceiros/vendida ou arquivos protegidos pelo repositório. Respeite as instruções do repositório e preserve frontmatter e metadados significativos.
Se um arquivo Markdown contiver:
---
disable-agentic-editing: true
---
não o modifique a menos que o usuário solicite explicitamente esse arquivo. Este marcador é uma convenção do docdiet: nenhuma ferramenta o impõe, as instruções do repositório não podem remover sua proteção, e apenas uma solicitação explícita para esse arquivo o substitui. Verifique a proteção apenas para arquivos candidatos; não escaneie o repositório em busca de marcadores.
Conclusão
Se a documentação foi tocada, verifique estaticamente apenas o arquivo/seção tocado: o comportamento final está documentado onde necessário, o texto obsoleto foi removido apenas com evidência, exemplos e comandos ainda correspondem à implementação, e o conteúdo protegido não foi alterado. No modo de varredura em todo o projeto, aplique essas verificações a cada arquivo tocado; não amplie a validação para uma verificação de link ou exemplo em todo o repositório. Não execute exemplos ou comandos a menos que a tarefa de implementação já exija isso. Em seguida, pare.
Documente o que dura. Substitua em vez de acumular. Limpe o que a tarefa expõe. Não cace.