Skill-Details
zero-hallucination-coder
Rigorous software engineering workflow.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: zero-hallucination-coder description: "Runs a disciplined Discuss -> Map -> Decompose -> Execute -> Verify loop that grounds code in verified structure — no invented APIs, no assumed imports, no placeholder code — with a lazy-senior-dev YAGNI ladder that deletes unnecessary code before it is written. Use when a coding task is high-stakes, complex, or spans existing code (auth, databases, migrations, multi-file features), or when the user explicitly asks to plan carefully before coding, avoid hallucinated code, or work rigorously. Not for trivial edits, typos, or throwaway one-off scripts — those do not need the full loop." --- # Zero-Hallucination Coder A disciplined, senior engineering partner. The goal is code that is correct, grounded, and complete — with zero invented APIs, zero skipped steps, and zero hallucinated behavior. ## When to invoke (opt-in discipline) This is a **deliberate, opt-in** pipeline, not the default for every edit. Reach for it when: - The task is high-stakes or hard to undo (migrations, schema/auth changes, deployments). - It spans existing code across multiple files, or touches external APIs, auth, databases, or state. - The user explicitly asks to "plan carefully," "avoid hallucinated code," or "do this rigorously." For a typo, a reformat, a docstring, or a throwaway script, skip the loop — the ceremony costs more than it saves. Anti-hallucination Rules 1-7 (below) still apply everywhere, but the five-phase loop is reserved for work that earns it. ## Credits & Inspiration This skill is a synthesis of four open-source projects. Their ideas power every phase of the loop below. | Project | Author | What It Contributes | |---------|--------|---------------------| | [Ralph](https://github.com/snarktank/ralph) | [@snarktank](https://github.com/snarktank) | PRD-driven atomic coding loop — implement one story at a time in fresh context, commit only when quality checks pass | | [GSD Core](https://github.com/open-gsd/gsd-core) | [@open-gsd](https://github.com/open-gsd) | Context-engineering discipline — Discuss → Plan → Execute → Verify → Ship phase loop, structured memory files, preventing context rot | | [Graphify](https://github.com/safishamsi/graphify) | [@safishamsi](https://github.com/safishamsi) | Knowledge-graph codebase reasoning — explicit KNOWN/INFERRED/UNKNOWN relationship tagging, grounded in real structure not guesses | | [Ponytail](https://github.com/DietrichGebert/ponytail) | [@DietrichGebert](https://github.com/DietrichGebert) | Lazy senior dev hierarchy — before writing any code, check if it needs to exist at all, producing 80–94% less code | Each project also ships its own native tooling (autonomous runners, AST graph builders, lifecycle hooks). This skill bakes their *discipline* into one loop; install the originals separately only if you want their standalone tooling. --- ## Before Starting **Check for context first:** If `project-context.md` exists in the workspace, read it before asking questions. Use that context and only ask for gaps. ## Modes - **Build from scratch** — no existing codebase. Run all five phases. - **Extend existing code** — the relevant files must be shared before Phase 2 (Map) can run. Request only the files that matter, not the whole repo. - **Debug or refactor** — abbreviated loop: Discuss → Map (read broken code) → Execute (targeted fix) → Verify. --- ## The Five-Phase Loop Every session under this skill runs all five phases in order. Skipping phases is the primary cause of hallucinated, broken, or incomplete code. ### Phase 1: DISCUSS **Goal:** Capture what is actually being built before any planning happens. Ask and fully resolve: 1. What is the end state? Describe the working thing, not the steps to get there. 2. What tech stack, language, and major libraries are in use? (Do NOT assume.) 3. Does existing code exist that this touches? If yes, share it. 4. What are the hard constraints? (Must run on X, must use Y, must not break Z.Vollständige Quelle auf GitHub lesen (öffnet externe Seite)