zero-hallucination-coder
por alirezarezvanizero-hallucination-coder é uma skill de Code Generation para mudanças mais seguras em repositórios. Ela orienta agentes pelas etapas Discuss, Map, Decompose, Execute e Verify para evitar APIs, imports, caminhos e código placeholder inventados. É mais indicada para trabalhos de alto risco envolvendo autenticação, banco de dados, migrações, APIs ou múltiplos arquivos; ignore em edições triviais.
Esta skill recebe 76/100, o que a torna uma boa candidata para listagem no diretório para usuários que buscam um fluxo de programação rigoroso para reduzir APIs inventadas, verificações ignoradas e soluções superdimensionadas. Pelo SKILL.md, ela parece acionável e operacionalmente útil, mas a confiança na adoção é limitada pela ausência de arquivos de apoio ou orientação de instalação/README e por sinais residuais de placeholder/TODO.
- A descrição no frontmatter define condições de acionamento claras: tarefas de código complexas, críticas, com vários arquivos, ou pedidos explícitos para planejar com cuidado e evitar código alucinado.
- A skill estabelece um ciclo disciplinado Discuss -> Map -> Decompose -> Execute -> Verify, dando aos agentes mais estrutura operacional do que um prompt genérico de programação.
- Ela se exclui explicitamente de edições triviais, correções de digitação e scripts descartáveis, o que ajuda a evitar acionamentos excessivos.
- Não há arquivos de apoio, referências, scripts nem README, então o fluxo depende inteiramente do único documento SKILL.md.
- O repositório traz sinais de placeholder/TODO, o que sugere que ainda podem existir pontos de acabamento ou completude a resolver.
Visão geral da skill zero-hallucination-coder
A skill zero-hallucination-coder é um workflow disciplinado de Code Generation para agentes de programação no estilo Claude que precisam alterar repositórios reais sem inventar APIs, imports, caminhos de arquivos ou comportamentos. Ela é mais indicada para quem quer um parceiro de programação com IA que inspecione antes de editar, planeje antes de implementar e verifique depois das mudanças, em vez de ir direto de um pedido vago para o código.
Que problema ela resolve
A maioria das alucinações em programação acontece quando o modelo presume a estrutura do projeto, convenções do framework, versões de dependências ou comportamentos não documentados. zero-hallucination-coder reduz esse risco ao impor um ciclo Discuss → Map → Decompose → Execute → Verify. O agente primeiro esclarece a tarefa, mapeia o código existente, divide o trabalho em etapas concretas, implementa apenas mudanças fundamentadas e então confere o resultado contra o repositório.
Use quando erros saem caro: autenticação, migrações de banco de dados, mudanças de schema, integrações com APIs, fluxos com estado, refatorações em múltiplos arquivos, código sensível a deploy ou qualquer solicitação em que “provavelmente correto” não seja suficiente.
Usuários e tarefas mais indicados
A zero-hallucination-coder skill combina com times e desenvolvedores solo que já têm uma base de código existente e querem uma implementação assistida por IA mais segura. Ela é especialmente útil quando o usuário consegue fornecer acesso ao repositório, testes falhando, logs, stack traces, descrições de issues ou critérios de aceite exatos.
Ela é menos útil para edições triviais, formatação rápida, scripts descartáveis ou tarefas em que velocidade importa mais do que verificação. A skill é intencionalmente mais pesada que um prompt comum, então o custo de preparação deve ser justificado pelo risco ou pela complexidade da mudança.
Principais diferenciais
O diferencial importante não é “escreve código”; prompts comuns de IA também fazem isso. O valor está na recusa em avançar com base em contexto presumido. A skill enfatiza estrutura verificada, ausência de código placeholder, nenhum import imaginado e remoção no estilo YAGNI de trabalho desnecessário antes da implementação. Para decisões de instalação, observe que o repositório expõe o workflow principalmente por meio de SKILL.md; não há scripts complementares, pastas de regras ou arquivos de referência para configurar.
Como usar a skill zero-hallucination-coder
Contexto de instalação da zero-hallucination-coder
O código-fonte fica em engineering/zero-hallucination-coder/skills/zero-hallucination-coder dentro de alirezarezvani/claude-skills. Se o seu executor de skills oferece suporte à instalação via GitHub, use o fluxo normal de instalação de skill desse diretório no GitHub, por exemplo:
npx skills add alirezarezvani/claude-skills --skill zero-hallucination-coder
Como a skill upstream não inclui scripts auxiliares nem pastas extras de recursos, o principal arquivo a inspecionar após a instalação é SKILL.md. Leia primeiro a descrição no frontmatter para entender quando o agente deve acioná-la; depois, revise as seções de workflow antes de depender dela para edições de alto risco em repositórios.
Entradas que fazem a skill funcionar
Para um bom zero-hallucination-coder usage, dê ao agente evidências suficientes para evitar suposições. Um prompt fraco seria: “Add password reset.” Um prompt mais forte seria:
- “Implement password reset for the existing Express app.”
- “Use the current mailer and user model; do not introduce a new email provider.”
- “Inspect the auth routes, database schema, and test setup before editing.”
- “Return a plan first, identify files you will touch, then implement with tests.”
- “If a needed API or table is missing, stop and ask instead of inventing it.”
Esse tipo de prompt se alinha ao ciclo da skill: discutir requisitos, mapear arquivos reais, decompor a implementação, executar e verificar.
Workflow prático para Code Generation
Comece pedindo explicitamente ao agente para usar a skill: “Use zero-hallucination-coder for this task.” Em seguida, forneça a tarefa, as restrições e os critérios de sucesso. Na primeira resposta, espere perguntas ou um mapa da base de código, não código imediato. Isso é uma funcionalidade, não um atraso.
Um bom workflow é:
- Peça um mapa do repositório relacionado à tarefa.
- Confirme o plano e os arquivos antes das edições.
- Deixe o agente implementar em etapas pequenas.
- Exija testes, checagens de tipos, saída de lint ou notas de verificação manual.
- Revise quaisquer suposições listadas pelo agente antes de fazer merge.
Para mudanças em múltiplos arquivos, peça ao agente que explique por que cada arquivo foi alterado. Isso mantém a skill ancorada no projeto e facilita o code review.
FAQ da skill zero-hallucination-coder
A zero-hallucination-coder é só para Claude?
O repositório foi escrito como uma skill Claude, mas o workflow é amplamente útil para agentes de programação com IA que conseguem ler arquivos do repositório e seguir instruções procedurais. A experiência de instalação depende do runtime de skills que você usa. Se o seu ambiente não oferece suporte a skills no estilo Claude, você ainda pode ler SKILL.md e adaptar o ciclo para um prompt de projeto ou instrução de agente.
Em que ela difere de um prompt cuidadoso de programação?
Um prompt cuidadoso pede que o modelo seja cauteloso. zero-hallucination-coder codifica um procedimento operacional repetível: esclarecer, inspecionar, decompor, implementar, verificar. Isso importa quando uma tarefa passa por código desconhecido, porque o agente é instruído a fundamentar decisões em arquivos observados, não em memória ou convenção. O trade-off é o overhead; para edições muito pequenas, um prompt mais curto costuma ser melhor.
Quando não devo usar esta skill?
Não use para corrigir typos, comentários simples, pequenas edições de documentação, scripts pontuais ou tarefas que não envolvem contexto de um projeto existente. Também evite se você não puder fornecer acesso ao repositório ou contexto de código-fonte suficiente para verificação. O valor da skill vem de mapear e checar código real; sem isso, ela vira apenas uma versão mais longa de um prompt genérico de programação.
Como melhorar a skill zero-hallucination-coder
Dê restrições mais fortes à zero-hallucination-coder
A forma mais rápida de melhorar a saída de zero-hallucination-coder é trocar objetivos vagos por limites claros. Nomeie o framework, runtime, gerenciador de pacotes, comando de teste, arquivos que não podem ser alterados, requisitos de compatibilidade e o que conta como concluído. Por exemplo: “Do not change the public API,” “Keep the migration backward-compatible,” ou “Use existing repository patterns even if a newer library exists.”
Restrições reduzem alucinação porque o agente tem menos oportunidades de inventar arquitetura.
Fique atento a modos de falha comuns
Mesmo com esta skill, revise suposições sutis: APIs de dependências não verificadas, imports ausentes, novas funções auxiliares que duplicam utilitários existentes, testes que mockam o comportamento real a ponto de escondê-lo ou código com “TODO” que parece completo. Se o agente disser que “assume” algo importante, pause e peça para ele localizar evidências no repositório ou solicitar esclarecimento.
Uma boa pergunta de revisão é: “Quais partes desta solução são diretamente sustentadas por arquivos inspecionados, e quais exigiram inferência?”
Itere depois da primeira saída
Trate o primeiro resultado como um plano ou implementação em rascunho, não como a resposta final. Peça ao agente uma rodada de verificação focada nos arquivos alterados, casos de borda e código desnecessário. Follow-ups úteis incluem:
- “Remove any code not required by the acceptance criteria.”
- “List every external API used and where it is defined.”
- “Check whether an existing utility already solves this.”
- “Add or update the smallest meaningful tests.”
- “Explain how to manually verify the change.”
Isso mantém o zero-hallucination-coder guide prático: menos código inventado, menos etapas puladas e um caminho mais claro entre a solicitação e uma implementação revisável.
