Skip to main content
AI/MLLeeJuOh

duck-review

PR/change-review session with the rubber duck — user justifies every change and predicts consequences. Use before commit/push/PR, or when they say \"duck review\", \"리뷰 전에 점검\". Not for code-level explanation (/duck-verify) or plan review (/duck-plan).

Stars
45
Source
LeeJuOh/claude-code-zero
Updated
2026-05-25
Slug
LeeJuOh--claude-code-zero--duck-review
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/LeeJuOh/claude-code-zero/HEAD/plugins/rubber-duck-tutor/skills/duck-review/SKILL.md -o .claude/skills/duck-review.md

Drops the SKILL.md into .claude/skills/duck-review.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Duck — PR / Change Review Mode

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

Input: Run git diff (or git diff --staged, or PR diff).

Flow

  1. One-sentence summary — always ground the question in the diff's scope:

Your turn: You touched [list the changed files/areas from the diff]. Summarize this entire change in one sentence — what does it do?

  1. Drill into 2-3 key changes from the diff:

Your turn: In [file:line_range], you changed [specific thing]. Why?

  1. Impact assessment:

Your turn: What existing behavior could this change break? Where should we look?

→ Then run the Temporal cost simulation subsection below before moving on.

  1. Generation vs comparison (when appropriate):

Your turn: For [the problem this code solves] — how would you have approached it?

After their answer, compare with the actual implementation. Discuss trade-offs.

  1. Confidence check — run the PR/Change Review row from the Confidence Check (shared) table.

Temporal cost simulation

Frame the change on a 6-month horizon, not just "does it work now":

Your turn: Six months from now, someone — maybe future you — has to modify this code. Where's it going to hurt first? Why?

Follow-ups depending on their answer:

  • Names a specific file/function → "Why is that spot fragile? What assumption in the current structure breaks first?"
  • "Nothing feels fragile" → "What's that confidence based on? What abstraction in this diff guarantees that?"
  • Vague ("kind of everywhere") → "Just one spot. If you commit this now, what's the first thing you'll regret?"

Question Frameworks

Assumptions — "What has to be true for this change to hold up?" Surface dependencies on other code, data formats, or system state.

Blindspots — "What could break outside this diff?" Force them to think beyond the changed files.

Techniques

Prioritize: teach-back, generation then comparison, concrete to abstract. See ../ducking/references/exercise-patterns.md for execution details.

Closing

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