← agent skills / rubber-duck

rubber-duck

A thinking partner that guides you to your own answer — listens first, reflects back your assumptions, and only sharpens into pointed questions when you're stuck.

install · cli
$ curl -fsSL https://raw.githubusercontent.com/Osipchuk/agent-skills/main/install.sh | sh -s -- rubber-duck

One line, works with any agent — installs just this skill into ~/.claude/skills/. Needs only curl; it fetches uv and the askill CLI if they're missing.

Installs skills/rubber-duck/SKILL.md into ~/.claude/skills/rubber-duck/; Claude reads it on the next session start. The plugin tab pulls the whole library instead.

Fires when the user wants to reason something out — "help me think through this", "rubber duck this with me", "I'm stuck on this bug" — not when they want a direct answer. It opens passively and escalates to diagnostic questions only if they're spinning, with an explicit escape hatch when they ask for the answer outright or it's an emergency.

# skills/rubber-duck/SKILL.md — frontmatter
name: rubber-duck
description: A thinking partner that helps you reach your OWN answer instead of handing you one. Use this when the user wants to reason something out: "help me think through this", "rubber duck this with me", "I'm stuck on this bug", "talk me through this design", "let me think out loud", "be my sounding board", "am I missing something here". Do NOT fire when the user wants a direct answer — "just tell me the fix", "give me the answer", "what's the bug" — that intent gets a straight reply, not questions. Also not for factual lookups, time-pressured incidents where speed beats learning, or requests to write code.
  • Passive-first, teeth-on-demand: a real duck listens; this one only sharpens into questions when you're stuck.
  • Reflects back your implicit assumptions — often that alone surfaces the answer.
  • One question per turn, never a solution dump, never smug.
  • Escape hatch: drops the method and answers when you ask twice or it's urgent — withholding past usefulness is the failure, not the goal.
example · Stuck on a flaky test 2 turns · 240 tok
input
user
Rubber duck this with me — my integration test passes locally but fails in CI and I can't figure out why.
↓ skill fires
skill
[rubber-duck] reasoning-out intent, opening at Gear 0
output
assistant
So: same test, green locally, red in CI, and nothing obvious changed. The assumption baked into that is that local and CI run the same thing — same env, same clock, same ordering. Walk me through one concrete difference: what does the failure actually say in CI, and is it the same assertion failing every run or a different one each time?
An engineer is stuck; the skill reflects the problem back and asks one narrow diagnostic question instead of guessing the fix.