Menu
WannaBuild debugging implementation entrypoint for reproducing, diagnosing, fixing, and verifying bugs within the full loop.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when starting any conversation that touches software work — establishes how to find and use WannaBuild skills, requiring skill invocation before ANY response including clarifying questions.
Automatic repo-native WannaBuild full-loop workflow for natural "I want to build/add/change..." prompts and any WannaBuild phase skill entrypoint.
WannaBuild implementation phase entrypoint for implementing a concrete plan or task with focused verification and adaptive delegation.
WannaBuild discovery phase entrypoint that grills the user — one question at a time, each with a recommended answer — to clarify vision, audience, flows, constraints, scope, and success signals before continuing the full loop. Also triggers on "grill me" or "grill this idea".
WannaBuild planning phase entrypoint for turning a brief or concrete task into architecture direction, implementation slices, and verification expectations.
WannaBuild QA phase entrypoint for validating acceptance criteria, integration behavior, and release readiness evidence.
| name | wb-debug |
| description | WannaBuild debugging implementation entrypoint for reproducing, diagnosing, fixing, and verifying bugs within the full loop. |
This prompt follows docs/contract-standard.md and inherits the four mandates in
skills/internal/build/references/doctrine.md; where this file is silent, the doctrine governs.
Shared contract: purpose, inputs, process, hard gates, evidence, output, handoff, forbidden actions.
Runtime gates fail closed and cannot be rationalized past. Specialist judgment stays advisory; a gate or acceptance criterion always wins.
Use this phase skill when the user wants a bug investigated or fixed. A wb-debug or wannabuild:wb-debug invocation runs the full WannaBuild loop — discovery, plan, implement, review, QA, summary. It stops short of QA only if the user, in this session, explicitly said "debug only"; confirm that exit before stopping, and even then discovery and the reproduction/verification gates below still apply.
Before any debugging phase work, in order:
scripts/wannabuild-workspace.sh --json and continue inside the reported workspace_path.Move from symptom to a reproduced failure, to a verified cause, to a minimal fix proven by re-running the reproduction.
Discovery fires on every bug, including one-line fixes; never skip it because the bug "looks trivial". Grill the user one question at a time, each with a recommended answer and its reasoning, until you have: exact symptoms, expected vs actual behavior, concrete reproduction steps, environment/version/data shape, and what changed recently. Resolve a question by reading the codebase, logs, or live runtime instead of asking whenever the answer is there, and cite it. The user confirms, redirects, or overrides — they never invent the answer from scratch. Capturing any of these by assumption is forbidden.
Discovery does not pass until .wannabuild/spec/requirements.md records the symptom, the expected behavior, and at least one concrete, checkable acceptance criterion describing what "fixed" means. The assert-discovery-ready gate fails closed until that exists.
Before you write "cannot reproduce", "no environment", "missing dependency", "no access", or "cannot test", you MUST exhaust real acquisition and report exactly what you tried:
create_branch, Neon create_branch) and seed it; never declare "no database".Auto-acquire anything safe, local, and reversible without asking. Stop and ask the user only for billable, outward-facing, or destructive acquisition (paid provisioning, deploys, production data, external sends) — present the specific resource and why. Every unmet need you claim blocks you requires an entry in .wannabuild/outputs/acquisition-log.json recording what was needed, which tools/connectors/CLIs were attempted, and the result. The assert-acquisition-attempted gate rejects any blocked status with no logged attempt.
total > 0, failed == 0, errored == 0), and every acceptance criterion is covered. A code re-read, a description, or "should pass" is a FAIL. A FAIL here blocks progress and cannot be overridden.After the Verification Gate passes, continue to QA and the terminal integration hard gate, which validates execution evidence (not text markers) and whose FAIL cannot be overridden.
Use sub-agents to parallelize independent hypotheses, log streams, environments, or risk areas; they do not narrow the verification surface.
Hard-stop at every public phase boundary (Discover → Plan → Implement → Review → QA → Summary): present what the phase produced, name the next phase, and wait for an explicit approval word ("go", "proceed", "approved", "continue", "next", "lgtm", "do it"). A vague acknowledgment ("ok", "sure") continues the current phase; it never crosses a boundary. Within a phase, run to completion exhaustively — do not pause mid-work for checkpoints and do not stop early on review or QA burden.
Report: the confirmed root cause; the changed files; the reproduction evidence (command, exit code, failing output before the fix) and verification evidence (the same reproduction now passing plus the regression checks that ran, with their output); any resource acquisition performed; and any residual risk. Naming "verification evidence" without showing the executed commands and their output does not satisfy this.