zero-hallucination-coder

zero-hallucination-coder skill 概覽

zero-hallucination-coder skill 是一套有紀律的 Code Generation 工作流程，適合需要修改真實 repository、但不能憑空捏造 API、imports、file paths 或行為的 Claude 類型 coding agents。它最適合希望 AI coding partner 先檢查再編輯、先規劃再實作、修改後再驗證的使用者，而不是從一個模糊需求直接跳到寫 code。

它解決什麼問題

多數 coding hallucinations 都發生在模型假設了 project structure、framework conventions、dependency versions 或未記錄的行為。zero-hallucination-coder 透過強制執行 Discuss → Map → Decompose → Execute → Verify 迴圈來降低這種風險。Agent 會先釐清任務、對既有 code 做 mapping、把工作拆成具體步驟、只實作有依據的變更，最後再依照 repository 驗證結果。

當錯誤代價很高時特別適合使用：authentication、database migrations、schema changes、API integrations、stateful flows、multi-file refactors、deployment-sensitive code，或任何「大概正確」還不夠的需求。

最適合的使用者與任務

zero-hallucination-coder skill 適合已有既有 codebase、並希望更安全地導入 AI-assisted implementation 的團隊與個人開發者。當使用者能提供 repository access、failing tests、logs、stack traces、issue descriptions 或明確 acceptance criteria 時，效果尤其好。

它不太適合極小修改、快速格式調整、一次性 scripts，或速度比驗證更重要的任務。這個 skill 刻意比一般 prompt 更「重」，因此 setup 成本應該要由變更的風險或複雜度來支撐。

關鍵差異

重要的差異不是「會寫 code」；一般 AI prompts 也做得到。它的價值在於拒絕基於猜測的 context 繼續前進。它強調已驗證的 structure、不寫 placeholder code、不想像 imports，並在實作前以 YAGNI 方式刪除不必要的工作。若你是為了安裝決策而評估，請注意這個 repository 主要透過 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 installation，請使用該 directory 一般的 GitHub skill install flow，例如：

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

由於 upstream skill 不包含 helper scripts 或額外 resource folders，安裝後主要要檢查的檔案是 SKILL.md。請先閱讀 frontmatter description，了解 agent 何時應該觸發它；接著再掃過 workflow sections，然後才把它用在高風險 repository edits 上。

讓這個 skill 發揮作用的輸入

若要有穩定的 zero-hallucination-coder usage，請提供足夠證據讓 agent 不需要猜。薄弱的 prompt 是：「Add password reset。」更好的 prompt 是：

• “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 會對齊 skill 的迴圈：討論需求、map 真實 files、拆解實作、執行，並驗證。

Code Generation 的實務工作流程

一開始請明確要求 agent 執行這個 skill：“Use zero-hallucination-coder for this task.” 接著提供任務、限制條件與 success criteria。第一則回覆中，預期會看到問題或 codebase map，而不是立即產生 code。這是功能，不是拖延。

建議流程如下：

1. 要求 agent 產生與任務相關的 repository map。
2. 在編輯前確認 plan 與將修改的 files。
3. 讓 agent 以小步驟實作。
4. 要求 tests、type checks、lint output，或 manual verification notes。
5. 在 merge 前檢視 agent 列出的任何 assumptions。

對於 multi-file changes，請要求 agent 說明為什麼每個 file 需要被修改。這能讓 skill 保持 grounded，也讓 code review 更容易。

zero-hallucination-coder skill FAQ

zero-hallucination-coder 只能用於 Claude 嗎？

這個 repository 是以 Claude skill 的形式撰寫，但其工作流程對於能讀取 repository 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。當任務橫跨不熟悉的 code 時，這一點很重要，因為 agent 被要求根據實際檢查到的 files 做決策，而不是依賴記憶或慣例。代價是額外負擔；對很小的修改來說，較短的 prompt 通常更合適。

什麼時候不該使用這個 skill？

不要把它用在 typo fixes、簡單 comments、小型 documentation edits、one-off scripts，或不涉及既有 project context 的任務上。如果你無法提供 repository access 或足夠的 source context 來驗證，也應避免使用。這個 skill 的價值來自 mapping 與檢查真實 code；如果沒有這些，它只會變成比較長的通用 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.”

限制能降低 hallucination，因為 agent 能自行發明架構的空間更少。

留意常見失敗模式

即使使用這個 skill，仍要檢查細微的猜測：未驗證的 dependency APIs、遺漏 imports、新增了與既有 utilities 重複的 helper functions、用 mocks 避開真實行為的 tests，或看起來完成但其實只是 “TODO” 的 code。如果 agent 表示它「assumes」了某個重要事項，請先暫停，要求它在 repository 中找出證據，或請它提出澄清問題。

一個好的 review 問題是：“Which parts of this solution are directly supported by inspected files, and which parts required inference?”

在第一版輸出後持續迭代

把第一版結果視為 draft plan 或 implementation，而不是最終答案。請要求 agent 針對 changed files、edge cases 與不必要的 code 做一次 verification pass。實用的追問包括：

• “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 之間的路徑更清楚。