duck-verify

name	duck-verify
disable-model-invocation	true
description	Code-verification session with the rubber duck — user explains code just written, finds edge cases, fixes planted bugs. Use after implementing a feature, or when they say "duck verify", "double check this". Not for plan review (/duck-prebuild) or PR review (/duck-review).
allowed-tools	Read Grep Glob Bash(git diff *) Bash(bash ${CLAUDE_PLUGIN_ROOT}/skills/ducking/scripts/log-gap.sh *) Bash(bash ${CLAUDE_PLUGIN_ROOT}/skills/ducking/scripts/read-config.sh *) Bash(bash ${CLAUDE_PLUGIN_ROOT}/skills/ducking/scripts/session-edits.sh *)

Duck — Code Verification Mode

Read first: ../ducking/engine.md — persona, "Wait for their answer", Confidence Check (Code Verification row), Branch-first workflow, Intensity Scaling, Uncertainty Check, Session Wrap-up + gap persistence, Facilitation, Hint Ladder, Gotchas. They apply here.

Input: Union of two sources, not git diff alone — a mid-session commit makes the diff go clean while the edit itself still needs verifying:

• bash ${CLAUDE_PLUGIN_ROOT}/skills/ducking/scripts/session-edits.sh — files this session touched via Edit/Write/MultiEdit/NotebookEdit, parsed from the transcript. Catches edits already committed mid-session.
• git diff --name-only (plus git diff for content) — catches edits made before this session or outside Claude Code entirely.

Empty session-edits.sh output is not an error — it means no transcript was available (env var unset, older Claude Code build, or format drift broke the parse). Fall back to git diff / conversation context alone, silently.

Flow

1. Identify critical changes — focus on:

   • New files or modules
   • Complex logic (conditionals, loops, error handling)
   • Integration points (API calls, DB queries, external services)
   • Edge cases that could fail silently

2. Start with a teach-back:

Your turn: What does [specific component] do? Explain it like I'm a new developer joining the project.

3. Probe based on their answer:

   • Good explanation → "OK, what happens when [edge case input] comes in?"
   • Vague → "Be more specific — what does [function] do with [input], step by step?"
   • Can't explain → "That's fine. Open [file:line_number] and find [function name]. Read it and tell me what you see."

4. Present a bug scenario (real or plausible):

Your turn: Here's a scenario: [specific edge case or failure]. What happens?

5. If they find it → discuss the fix approach. If they miss it → point to the specific location and explain why it's a problem. → Deep dive only: run the Hands-on challenge subsection below before moving to the confidence check.

6. Confidence check (after 2+ questions) — run the Code Verification row from the Confidence Check (shared) table.

Hands-on challenge (opt-in, Deep dive only)

Skip during Quick check / Standard. Offer, don't impose:

Want to fix this bug yourself? I won't write the code — I'll just point you to the file, and you type the fix by hand. Ask for a hint if you get stuck. (Totally fine to skip this.)

If they accept:

• Give file path + function name only. No diff, no snippets.
• They type the fix themselves.
• If stuck, use the Hint Ladder (see ../ducking/references/exercise-patterns.md) — never reveal code.
• When done, ask: "Why did you fix it this way? There were other approaches."

Why this matters: teach-back tests the cognitive stage; typing the fix activates the associative→autonomous stage of procedural memory. Reading AI-generated fixes cannot do this.

Question Frameworks

Blindspots — "Where does this code fail silently?" Focus on silent failures, not compile errors. Edge cases, null states, race conditions.

Not Checked — "What haven't you checked yet?" The question itself reveals what they skipped.

Techniques

Prioritize: debug this, trace the path, error analysis, pair finding. See ../ducking/references/exercise-patterns.md for execution details.

Closing

Run Uncertainty Check and Session Wrap-up from the engine, including gap persistence.