zero-hallucination-coder

Overview of zero-hallucination-coder skill

The zero-hallucination-coder skill is a disciplined Code Generation workflow for Claude-style coding agents that need to change real repositories without inventing APIs, imports, file paths, or behavior. It is best for users who want an AI coding partner to inspect before editing, plan before implementing, and verify after changes instead of jumping directly from a vague request to code.

What problem it solves

Most coding hallucinations happen when the model assumes project structure, framework conventions, dependency versions, or undocumented behavior. zero-hallucination-coder reduces that risk by forcing a Discuss → Map → Decompose → Execute → Verify loop. The agent first clarifies the task, maps the existing code, breaks work into concrete steps, implements only grounded changes, then checks the result against the repository.

Use it when mistakes are expensive: authentication, database migrations, schema changes, API integrations, stateful flows, multi-file refactors, deployment-sensitive code, or any request where “probably correct” is not good enough.

Best-fit users and tasks

The zero-hallucination-coder skill fits teams and solo developers who already have an existing codebase and want safer AI-assisted implementation. It is especially useful when the user can provide repository access, failing tests, logs, stack traces, issue descriptions, or exact acceptance criteria.

It is less useful for trivial edits, quick formatting, throwaway scripts, or tasks where speed matters more than verification. The skill is intentionally heavier than a normal prompt, so the setup cost should be justified by the risk or complexity of the change.

Key differentiators

The important differentiator is not “writes code”; ordinary AI prompts can do that. The value is its refusal to proceed on guessed context. It emphasizes verified structure, no placeholder code, no imagined imports, and YAGNI-style deletion of unnecessary work before implementation. For install decisions, note that the repository exposes the workflow mainly through SKILL.md; there are no companion scripts, rules folders, or reference files to configure.

How to Use zero-hallucination-coder skill

zero-hallucination-coder install context

The source lives at engineering/zero-hallucination-coder/skills/zero-hallucination-coder in alirezarezvani/claude-skills. If your skill runner supports GitHub installation, use the directory’s normal GitHub skill install flow, for example:

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

Because the upstream skill does not include helper scripts or extra resource folders, the main file to inspect after install is SKILL.md. Read the frontmatter description first to understand when the agent should trigger it, then scan the workflow sections before relying on it for high-risk repository edits.

Inputs that make the skill work

For strong zero-hallucination-coder usage, give the agent enough evidence to avoid guessing. A weak prompt is: “Add password reset.” A stronger prompt is:

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

This kind of prompt aligns with the skill’s loop: discuss requirements, map real files, decompose implementation, execute, and verify.

Practical workflow for Code Generation

Start by asking the agent to run the skill explicitly: “Use zero-hallucination-coder for this task.” Then provide the task, constraints, and success criteria. In the first response, expect questions or a codebase map, not immediate code. That is a feature, not a delay.

A good workflow is:

1. Ask for a repository map related to the task.
2. Confirm the plan and files before edits.
3. Let the agent implement in small steps.
4. Require tests, type checks, lint output, or manual verification notes.
5. Review any assumptions the agent lists before merging.

For multi-file changes, ask the agent to explain why each file is touched. That keeps the skill grounded and makes code review easier.

zero-hallucination-coder skill FAQ

Is zero-hallucination-coder only for Claude?

The repository is written as a Claude skill, but the workflow is broadly useful for AI coding agents that can read repository files and follow procedural instructions. The install experience depends on your skill runtime. If your environment does not support Claude-style skills, you can still read SKILL.md and adapt the loop into a project prompt or agent instruction.

How is it different from a careful coding prompt?

A careful prompt asks the model to be cautious. zero-hallucination-coder encodes a repeatable operating procedure: clarify, inspect, decompose, implement, verify. That matters when a task spans unfamiliar code, because the agent is instructed to ground decisions in observed files rather than memory or convention. The tradeoff is overhead; for tiny edits, a shorter prompt is usually better.

When should I not use this skill?

Do not use it for typo fixes, simple comments, small documentation edits, one-off scripts, or tasks where no existing project context is involved. Also avoid it if you cannot provide repository access or enough source context for verification. The skill’s value comes from mapping and checking real code; without that, it becomes a longer version of a generic coding prompt.

How to Improve zero-hallucination-coder skill

Give zero-hallucination-coder stronger constraints

The fastest way to improve zero-hallucination-coder output is to replace vague goals with boundaries. Name the framework, runtime, package manager, test command, files that are off-limits, compatibility requirements, and what counts as done. For example: “Do not change the public API,” “Keep the migration backward-compatible,” or “Use existing repository patterns even if a newer library exists.”

Constraints reduce hallucination because the agent has fewer opportunities to invent architecture.

Watch for common failure modes

Even with this skill, review for subtle guesses: unverified dependency APIs, missing imports, new helper functions that duplicate existing utilities, tests that mock away the real behavior, or “TODO” code that looks complete. If the agent says it “assumes” something important, pause and ask it to locate evidence in the repository or request clarification.

A good review question is: “Which parts of this solution are directly supported by inspected files, and which parts required inference?”

Iterate after the first output

Treat the first result as a draft plan or implementation, not the final answer. Ask the agent to run a verification pass focused on changed files, edge cases, and unnecessary code. Useful follow-ups include:

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

This keeps the zero-hallucination-coder guide practical: less invented code, fewer skipped steps, and a clearer path from request to reviewable implementation.