zero-hallucination-coder

zero-hallucination-coder skill の概要

zero-hallucination-coder skill は、Claude 型のコーディングエージェント向けに設計された、規律ある Code Generation ワークフローです。実在するリポジトリを変更する際に、API、imports、file paths、挙動を勝手に作り上げないことを重視します。曖昧な依頼からいきなりコードを書くのではなく、編集前に調査し、実装前に計画し、変更後に検証する AI コーディングパートナーを求めるユーザーに向いています。

解決できる課題

コーディングにおける hallucination の多くは、モデルがプロジェクト構成、フレームワークの慣習、依存関係のバージョン、未文書化の挙動を推測してしまうことで起きます。zero-hallucination-coder は Discuss → Map → Decompose → Execute → Verify というループを強制することで、そのリスクを下げます。エージェントはまずタスクを確認し、既存コードを把握し、作業を具体的な手順に分解し、根拠のある変更だけを実装し、最後にリポジトリに照らして結果を確認します。

認証、database migrations、schema changes、API integrations、stateful flows、multi-file refactors、deployment-sensitive code など、ミスのコストが高い場面で使うのが適しています。「たぶん正しい」では不十分な依頼にも向いています。

向いているユーザーとタスク

zero-hallucination-coder skill は、すでに既存コードベースを持っていて、AI 支援による実装をより安全に進めたいチームや個人開発者に合います。特に、リポジトリへのアクセス、失敗している tests、logs、stack traces、issue descriptions、明確な acceptance criteria を提供できる場合に効果を発揮します。

一方で、些細な編集、短時間の formatting、使い捨て scripts、検証よりスピードを優先するタスクにはあまり向きません。この skill は通常の prompt より意図的に重めなので、変更のリスクや複雑さに見合う場合に導入するのがよいでしょう。

主な差別化ポイント

重要な差別化は「コードを書けること」ではありません。それは通常の AI prompts でも可能です。価値は、推測した文脈のまま進めることを拒む点にあります。確認済みの構造、placeholder code を置かないこと、想像上の imports を使わないこと、実装前に不要な作業を削る YAGNI 的な姿勢を重視します。インストール判断の観点では、このリポジトリが主に SKILL.md を通じてワークフローを提供している点に注意してください。設定すべき companion scripts、rules folders、reference files はありません。

zero-hallucination-coder skill の使い方

zero-hallucination-coder のインストール前提

ソースは alirezarezvani/claude-skills の engineering/zero-hallucination-coder/skills/zero-hallucination-coder にあります。利用している skill runner が GitHub からのインストールに対応している場合は、通常の GitHub skill install flow を使います。例:

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

上流の skill には helper scripts や追加の resource folders が含まれていないため、インストール後にまず確認すべき主要ファイルは SKILL.md です。最初に frontmatter description を読み、どのような場面でエージェントがこの skill を起動すべきかを把握してください。そのうえで、高リスクなリポジトリ編集に使う前に workflow sections を確認しておくと安心です。

skill を機能させる入力

質の高い zero-hallucination-coder usage には、エージェントが推測せずに済むだけの根拠を渡すことが重要です。弱い依頼は「Add password reset.」です。より良い依頼は次のようになります。

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

この種の prompt は、要件を確認し、実在する files をマップし、実装を分解し、実行し、検証するという skill のループと噛み合います。

Code Generation の実践ワークフロー

まずエージェントに明示的に skill を使うよう依頼します。“Use zero-hallucination-coder for this task.” のように伝えてください。その後、タスク、制約、成功条件を渡します。最初の応答では、いきなりコードではなく、質問や codebase map が返ってくることを想定してください。それは遅延ではなく、この skill の利点です。

おすすめの流れは次のとおりです。

1. タスクに関連する repository map を依頼する。
2. 編集前に plan と対象 files を確認する。
3. エージェントに小さな単位で実装させる。
4. tests、type checks、lint output、または manual verification notes を求める。
5. merge 前に、エージェントが列挙した assumptions を確認する。

複数ファイルにまたがる変更では、なぜ各 file を触るのかをエージェントに説明させるとよいです。skill の判断を現実のコードに結びつけやすくなり、code review もしやすくなります。

zero-hallucination-coder skill FAQ

zero-hallucination-coder は Claude 専用ですか？

このリポジトリは Claude skill として書かれていますが、ワークフロー自体は、リポジトリの files を読めて手順化された指示に従える AI coding agents 全般に役立ちます。インストール体験は利用している skill runtime に依存します。環境が Claude-style skills に対応していない場合でも、SKILL.md を読み、ループを project prompt や agent instruction に取り込むことは可能です。

慎重な coding prompt と何が違いますか？

慎重な prompt は、モデルに注意深く振る舞うよう依頼します。zero-hallucination-coder は、clarify、inspect、decompose、implement、verify という再現可能な operating procedure を組み込んでいます。未知のコードにまたがるタスクでは、この違いが重要です。エージェントは記憶や慣習ではなく、実際に確認した files に基づいて判断するよう指示されるからです。その代わり、手間は増えます。ごく小さな編集なら、短い prompt のほうが通常は適しています。

この skill を使わないほうがよい場面は？

typo fixes、simple comments、小さな documentation edits、one-off scripts、既存プロジェクトの文脈が不要なタスクには使わないほうがよいです。また、リポジトリへのアクセスや検証に足る source context を提供できない場合も避けてください。この skill の価値は、実際のコードをマッピングし、確認することから生まれます。それができない場合、単に長い generic coding prompt になってしまいます。

zero-hallucination-coder skill を改善する方法

zero-hallucination-coder により強い制約を与える

zero-hallucination-coder の出力を改善する最短ルートは、曖昧な目標を明確な境界条件に置き換えることです。framework、runtime、package manager、test command、触ってはいけない files、compatibility requirements、完了条件を明示してください。たとえば “Do not change the public API,” “Keep the migration backward-compatible,” “Use existing repository patterns even if a newer library exists.” のように指定します。

制約があるほど、エージェントが architecture を作り上げる余地が減るため、hallucination を抑えやすくなります。

よくある失敗パターンに注意する

この skill を使っていても、細かな推測が紛れ込んでいないか確認してください。未検証の dependency APIs、抜けている imports、既存 utilities と重複する新規 helper functions、実際の挙動を mock で覆い隠してしまう tests、完成しているように見える “TODO” code などが典型です。エージェントが重要な点について「assumes」と言った場合は、いったん止めて、リポジトリ内の根拠を示させるか、追加の確認を求めてください。

レビュー時に有効な質問は次のようなものです。“Which parts of this solution are directly supported by inspected files, and which parts required inference?”

最初の出力後に反復する

最初の結果は最終回答ではなく、draft plan または draft implementation として扱います。変更された files、edge cases、不要な code に焦点を当てて、エージェントに verification pass を実行させてください。役立つ follow-up には次のようなものがあります。

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

これにより、zero-hallucination-coder guide を実践的に使えます。作り上げた code を減らし、抜けた手順を減らし、依頼から review 可能な implementation までの道筋を明確にできます。