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`](../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.

**Paths** for engine.md's commands: `<scripts>` is `${CLAUDE_PLUGIN_ROOT}/skills/ducking/scripts`, `<data-dir>` is `${CLAUDE_PLUGIN_DATA}`.

**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)](../ducking/engine.md#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](../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](../ducking/references/exercise-patterns.md) for execution details.

## Closing

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