zero-hallucination-coder

Descripción general de la skill zero-hallucination-coder

La skill zero-hallucination-coder es un flujo de trabajo disciplinado de generación de código para agentes de programación al estilo Claude que necesitan modificar repositorios reales sin inventar APIs, imports, rutas de archivos ni comportamientos. Es ideal para quienes quieren que su asistente de código con IA inspeccione antes de editar, planifique antes de implementar y verifique después de los cambios, en lugar de pasar directamente de una solicitud vaga al código.

Qué problema resuelve

La mayoría de las alucinaciones al programar aparecen cuando el modelo asume la estructura del proyecto, las convenciones del framework, las versiones de dependencias o comportamientos no documentados. zero-hallucination-coder reduce ese riesgo al imponer un ciclo Discuss → Map → Decompose → Execute → Verify. El agente primero aclara la tarea, mapea el código existente, divide el trabajo en pasos concretos, implementa solo cambios sustentados en evidencia y luego comprueba el resultado contra el repositorio.

Úsala cuando los errores sean costosos: autenticación, migraciones de base de datos, cambios de esquema, integraciones de API, flujos con estado, refactors de varios archivos, código sensible al despliegue o cualquier solicitud en la que “probablemente correcto” no sea suficiente.

Usuarios y tareas para los que encaja mejor

La zero-hallucination-coder skill encaja con equipos y desarrolladores individuales que ya tienen una base de código existente y quieren una implementación asistida por IA más segura. Es especialmente útil cuando la persona usuaria puede proporcionar acceso al repositorio, tests que fallan, logs, stack traces, descripciones de issues o criterios de aceptación exactos.

Es menos útil para ediciones triviales, formateo rápido, scripts descartables o tareas en las que la velocidad importa más que la verificación. La skill es intencionalmente más pesada que un prompt normal, así que el coste de configuración debería justificarse por el riesgo o la complejidad del cambio.

Diferenciadores clave

El diferenciador importante no es “escribe código”; los prompts comunes de IA también pueden hacerlo. Su valor está en negarse a avanzar con contexto supuesto. Pone el foco en una estructura verificada, nada de código placeholder, nada de imports imaginados y eliminación al estilo YAGNI de trabajo innecesario antes de implementar. Para decidir si instalarla, ten en cuenta que el repositorio expone el flujo principalmente mediante SKILL.md; no hay scripts complementarios, carpetas de reglas ni archivos de referencia que configurar.

Cómo usar la skill zero-hallucination-coder

Contexto de instalación de zero-hallucination-coder

El código fuente está en engineering/zero-hallucination-coder/skills/zero-hallucination-coder dentro de alirezarezvani/claude-skills. Si tu ejecutor de skills admite instalación desde GitHub, usa el flujo normal de instalación de skills de GitHub para ese directorio, por ejemplo:

npx skills add alirezarezvani/claude-skills --skill zero-hallucination-coder

Como la skill upstream no incluye scripts auxiliares ni carpetas de recursos extra, el archivo principal que conviene revisar después de instalar es SKILL.md. Lee primero la descripción del frontmatter para entender cuándo debería activarse el agente y luego revisa las secciones del flujo de trabajo antes de confiar en ella para ediciones de repositorio de alto riesgo.

Inputs que hacen que la skill funcione

Para un buen zero-hallucination-coder usage, dale al agente suficiente evidencia para evitar conjeturas. Un prompt débil sería: “Add password reset.” Un prompt más sólido sería:

• “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.”

Este tipo de prompt encaja con el ciclo de la skill: discutir requisitos, mapear archivos reales, descomponer la implementación, ejecutar y verificar.

Flujo de trabajo práctico para generación de código

Empieza pidiéndole al agente que use la skill de forma explícita: “Use zero-hallucination-coder for this task.” Luego proporciona la tarea, las restricciones y los criterios de éxito. En la primera respuesta, espera preguntas o un mapa de la base de código, no código inmediato. Eso es una ventaja, no una demora.

Un buen flujo de trabajo es:

1. Pedir un mapa del repositorio relacionado con la tarea.
2. Confirmar el plan y los archivos antes de editar.
3. Dejar que el agente implemente en pasos pequeños.
4. Exigir tests, comprobaciones de tipos, salida de lint o notas de verificación manual.
5. Revisar cualquier supuesto que el agente enumere antes de hacer merge.

Para cambios en varios archivos, pídele al agente que explique por qué toca cada archivo. Eso mantiene la skill anclada al repositorio y facilita la revisión de código.

FAQ de la skill zero-hallucination-coder

¿zero-hallucination-coder es solo para Claude?

El repositorio está escrito como una skill de Claude, pero el flujo de trabajo es ampliamente útil para agentes de programación con IA que pueden leer archivos del repositorio y seguir instrucciones procedimentales. La experiencia de instalación depende de tu runtime de skills. Si tu entorno no admite skills al estilo Claude, aun así puedes leer SKILL.md y adaptar el ciclo a un prompt de proyecto o a una instrucción para el agente.

¿En qué se diferencia de un prompt de programación cuidadoso?

Un prompt cuidadoso le pide al modelo que sea prudente. zero-hallucination-coder codifica un procedimiento operativo repetible: aclarar, inspeccionar, descomponer, implementar y verificar. Eso importa cuando una tarea atraviesa código desconocido, porque el agente recibe la instrucción de fundamentar sus decisiones en archivos observados, no en memoria o convenciones. La contrapartida es la sobrecarga; para ediciones muy pequeñas, normalmente conviene más un prompt corto.

¿Cuándo no debería usar esta skill?

No la uses para corregir erratas, comentarios simples, pequeñas ediciones de documentación, scripts puntuales o tareas en las que no haya contexto de un proyecto existente. Evítala también si no puedes proporcionar acceso al repositorio o suficiente contexto de código fuente para verificar. El valor de la skill viene de mapear y comprobar código real; sin eso, se convierte en una versión más larga de un prompt genérico de programación.

Cómo mejorar la skill zero-hallucination-coder

Dale restricciones más sólidas a zero-hallucination-coder

La forma más rápida de mejorar la salida de zero-hallucination-coder es reemplazar objetivos vagos por límites claros. Indica el framework, runtime, gestor de paquetes, comando de tests, archivos que no se deben tocar, requisitos de compatibilidad y qué cuenta como terminado. Por ejemplo: “Do not change the public API,” “Keep the migration backward-compatible,” o “Use existing repository patterns even if a newer library exists.”

Las restricciones reducen las alucinaciones porque el agente tiene menos oportunidades de inventar arquitectura.

Vigila los modos de fallo habituales

Incluso con esta skill, revisa posibles conjeturas sutiles: APIs de dependencias no verificadas, imports faltantes, nuevas funciones auxiliares que duplican utilidades existentes, tests que mockean hasta ocultar el comportamiento real o código “TODO” que parece completo. Si el agente dice que “asume” algo importante, pausa y pídele que localice evidencia en el repositorio o que solicite una aclaración.

Una buena pregunta de revisión es: “Which parts of this solution are directly supported by inspected files, and which parts required inference?”

Itera después del primer resultado

Trata el primer resultado como un borrador de plan o implementación, no como la respuesta final. Pídele al agente que ejecute una pasada de verificación centrada en los archivos modificados, los casos límite y el código innecesario. Algunos seguimientos útiles son:

• “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.”

Esto mantiene la zero-hallucination-coder guide en un terreno práctico: menos código inventado, menos pasos omitidos y una ruta más clara desde la solicitud hasta una implementación revisable.