zero-hallucination-coder

Überblick über den zero-hallucination-coder skill

Der zero-hallucination-coder skill ist ein disziplinierter Code-Generation-Workflow für Coding Agents im Claude-Stil, die echte Repositories ändern sollen, ohne APIs, Imports, Dateipfade oder Verhalten zu erfinden. Er eignet sich besonders für Nutzer, die einen AI-Coding-Partner wollen, der vor dem Bearbeiten prüft, vor der Implementierung plant und Änderungen anschließend verifiziert, statt von einer vagen Anfrage direkt in Code zu springen.

Welches Problem er löst

Die meisten Coding-Halluzinationen entstehen, wenn das Modell Projektstruktur, Framework-Konventionen, Dependency-Versionen oder undokumentiertes Verhalten annimmt. zero-hallucination-coder senkt dieses Risiko, indem er eine Schleife aus Discuss → Map → Decompose → Execute → Verify erzwingt. Der Agent klärt zuerst die Aufgabe, kartiert den bestehenden Code, zerlegt die Arbeit in konkrete Schritte, implementiert nur fundierte Änderungen und prüft das Ergebnis anschließend gegen das Repository.

Nutzen Sie ihn, wenn Fehler teuer werden: Authentifizierung, Datenbankmigrationen, Schemaänderungen, API-Integrationen, zustandsbehaftete Abläufe, Multi-File-Refactorings, deploymentkritischer Code oder jede Anfrage, bei der „wahrscheinlich richtig“ nicht ausreicht.

Für welche Nutzer und Aufgaben er am besten passt

Der zero-hallucination-coder skill passt zu Teams und einzelnen Entwicklern, die bereits eine bestehende Codebase haben und AI-gestützte Implementierung sicherer machen möchten. Besonders nützlich ist er, wenn der Nutzer Repository-Zugriff, fehlschlagende Tests, Logs, Stack Traces, Issue-Beschreibungen oder genaue Akzeptanzkriterien bereitstellen kann.

Weniger sinnvoll ist er für triviale Änderungen, schnelle Formatierungen, Wegwerfskripte oder Aufgaben, bei denen Geschwindigkeit wichtiger ist als Verifikation. Der Skill ist bewusst schwergewichtiger als ein normaler Prompt; der Einrichtungsaufwand sollte daher durch Risiko oder Komplexität der Änderung gerechtfertigt sein.

Zentrale Unterscheidungsmerkmale

Das wichtige Unterscheidungsmerkmal ist nicht „schreibt Code“; das können gewöhnliche AI-Prompts auch. Der Wert liegt darin, dass der Skill nicht auf vermutetem Kontext weiterarbeitet. Er betont verifizierte Struktur, keinen Platzhaltercode, keine erfundenen Imports und ein YAGNI-artiges Streichen unnötiger Arbeit vor der Implementierung. Für Installationsentscheidungen ist wichtig: Das Repository stellt den Workflow hauptsächlich über SKILL.md bereit; es gibt keine begleitenden Skripte, Rules-Ordner oder Referenzdateien, die konfiguriert werden müssen.

So verwenden Sie den zero-hallucination-coder skill

Installationskontext für zero-hallucination-coder

Die Quelle liegt unter engineering/zero-hallucination-coder/skills/zero-hallucination-coder in alirezarezvani/claude-skills. Wenn Ihr Skill Runner die Installation aus GitHub unterstützt, verwenden Sie den normalen GitHub-Installationsablauf des Verzeichnisses, zum Beispiel:

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

Da der Upstream-Skill keine Hilfsskripte oder zusätzlichen Ressourcenordner enthält, ist die wichtigste Datei nach der Installation SKILL.md. Lesen Sie zuerst die Frontmatter-Beschreibung, um zu verstehen, wann der Agent den Skill auslösen soll, und überfliegen Sie anschließend die Workflow-Abschnitte, bevor Sie ihn für risikoreiche Repository-Änderungen einsetzen.

Eingaben, mit denen der Skill zuverlässig arbeitet

Für eine starke zero-hallucination-coder usage sollten Sie dem Agent genügend Belege geben, damit er nicht raten muss. Ein schwacher Prompt wäre: „Add password reset.“ Ein stärkerer Prompt ist:

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

Diese Art von Prompt passt zur Schleife des Skills: Anforderungen besprechen, reale Dateien kartieren, die Implementierung zerlegen, ausführen und verifizieren.

Praktischer Workflow für Code Generation

Bitten Sie den Agent zu Beginn ausdrücklich, den Skill zu verwenden: „Use zero-hallucination-coder for this task.“ Geben Sie dann Aufgabe, Einschränkungen und Erfolgskriterien an. In der ersten Antwort sollten Sie Fragen oder eine Karte der Codebase erwarten, nicht sofort Code. Das ist ein Vorteil, keine Verzögerung.

Ein guter Workflow ist:

1. Fordern Sie eine Repository-Karte an, die sich auf die Aufgabe bezieht.
2. Bestätigen Sie Plan und Dateien, bevor Änderungen vorgenommen werden.
3. Lassen Sie den Agent in kleinen Schritten implementieren.
4. Verlangen Sie Tests, Type Checks, Lint-Ausgaben oder Hinweise zur manuellen Verifikation.
5. Prüfen Sie alle Annahmen, die der Agent auflistet, bevor Sie mergen.

Bei Änderungen über mehrere Dateien hinweg sollten Sie den Agent erklären lassen, warum jede Datei angefasst wird. Das hält den Skill geerdet und erleichtert das Code Review.

zero-hallucination-coder skill FAQ

Ist zero-hallucination-coder nur für Claude gedacht?

Das Repository ist als Claude skill geschrieben, aber der Workflow ist allgemein nützlich für AI Coding Agents, die Repository-Dateien lesen und prozeduralen Anweisungen folgen können. Die Installationserfahrung hängt von Ihrer Skill Runtime ab. Wenn Ihre Umgebung keine Skills im Claude-Stil unterstützt, können Sie trotzdem SKILL.md lesen und die Schleife in einen Projekt-Prompt oder eine Agent-Anweisung übertragen.

Worin unterscheidet er sich von einem sorgfältigen Coding-Prompt?

Ein sorgfältiger Prompt bittet das Modell, vorsichtig zu sein. zero-hallucination-coder kodifiziert ein wiederholbares Vorgehen: klären, prüfen, zerlegen, implementieren, verifizieren. Das ist wichtig, wenn eine Aufgabe unbekannten Code umfasst, weil der Agent angewiesen wird, Entscheidungen auf beobachtete Dateien zu stützen statt auf Erinnerung oder Konventionen. Der Nachteil ist zusätzlicher Aufwand; für sehr kleine Änderungen ist ein kürzerer Prompt meistens besser.

Wann sollte ich diesen Skill nicht verwenden?

Verwenden Sie ihn nicht für Tippfehlerkorrekturen, einfache Kommentare, kleine Dokumentationsänderungen, Einmalskripte oder Aufgaben ohne bestehenden Projektkontext. Vermeiden Sie ihn auch, wenn Sie keinen Repository-Zugriff oder nicht genug Quellkontext für die Verifikation bereitstellen können. Der Wert des Skills entsteht durch das Kartieren und Prüfen echten Codes; ohne das wird er nur zu einer längeren Version eines generischen Coding-Prompts.

So verbessern Sie den zero-hallucination-coder skill

Geben Sie zero-hallucination-coder stärkere Einschränkungen

Der schnellste Weg, die Ausgabe von zero-hallucination-coder zu verbessern, ist, vage Ziele durch klare Grenzen zu ersetzen. Nennen Sie Framework, Runtime, Package Manager, Testbefehl, Dateien, die tabu sind, Kompatibilitätsanforderungen und was als erledigt gilt. Zum Beispiel: „Do not change the public API,“ „Keep the migration backward-compatible,“ oder „Use existing repository patterns even if a newer library exists.“

Einschränkungen reduzieren Halluzinationen, weil der Agent weniger Gelegenheit hat, Architektur zu erfinden.

Achten Sie auf typische Fehlerquellen

Auch mit diesem Skill sollten Sie auf subtile Vermutungen achten: nicht verifizierte Dependency-APIs, fehlende Imports, neue Helper-Funktionen, die bestehende Utilities duplizieren, Tests, die das reale Verhalten wegmocken, oder „TODO“-Code, der vollständig wirkt. Wenn der Agent sagt, er „assumes“ etwas Wichtiges, halten Sie an und bitten Sie ihn, Belege im Repository zu finden oder eine Klärung anzufordern.

Eine gute Review-Frage lautet: „Which parts of this solution are directly supported by inspected files, and which parts required inference?“

Nach der ersten Ausgabe iterieren

Behandeln Sie das erste Ergebnis als Entwurfsplan oder Implementierung, nicht als endgültige Antwort. Bitten Sie den Agent, einen Verifikationsdurchlauf mit Fokus auf geänderte Dateien, Edge Cases und unnötigen Code durchzuführen. Nützliche Follow-ups sind:

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

So bleibt der zero-hallucination-coder guide praktisch: weniger erfundener Code, weniger übersprungene Schritte und ein klarerer Weg von der Anfrage zu einer reviewfähigen Implementierung.