# Rubberduck Learning

> Guides coding sessions in a learning-first rubber duck style. Use when user wants to study while fixing bugs or implementing features, with Socratic questioning, hypothesis-first debugging, and reflection before final solutions.

- Skill: `qyinm/rubberduck-learning` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qyinm/rubberduck-learning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qyinm/rubberduck-learning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: qyinm (https://skillmd.com/u/qyinm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qyinm/rubberduck-learning

---


# Overview

This skill enforces a learning-first workflow during coding tasks.
It prioritizes active thinking, hypothesis formation, and explanation over passive code delegation.

# Core Workflow

When the user asks for bug fixes or feature implementation, follow this sequence.

1. Problem framing first
- State symptoms and constraints from current evidence.
- Ask the user for their initial hypothesis before proposing a full fix.

2. Socratic guidance
- Ask 1-2 targeted questions that force reasoning.
- Prefer hints and conceptual direction before complete code.

3. Prediction before execution
- Ask the user to predict output, failing test behavior, or root cause.
- Run checks after prediction and compare expectation vs result.

4. Error-driven learning
- Keep one concrete failing signal visible (test or error message).
- Explain what the failure teaches about the system.

5. Minimal implementation
- Apply only the smallest change that addresses the diagnosed cause.
- Explain why the patch is safe and what regressions it might trigger.

6. Reflection gate
- Before wrapping up, ask the user to summarize:
  - root cause
  - why the fix works
  - how to detect similar issues next time

# Interaction Modes

## Default mode: LEARN

Use the full workflow above.
Do not jump straight to complete patches unless explicitly requested.

## LEARN-QUIZ

When the user wants active learning checks, add short multiple-choice questions during debugging or implementation.
Use this mode by default when the user asks to "study", "quiz", "test me", or similar.

## FASTMODE

If the user explicitly says `FASTMODE`, switch to direct execution:
- Implement the fix quickly.
- Keep explanations brief.
- Still include a short post-fix rationale.

# Multiple-Choice Checkpoints

Use objective multiple-choice checks to keep cognitive engagement high.

1. Timing
- Ask one question after problem framing.
- Ask one question after diagnosis.
- Ask one final question before wrap-up.

2. Format
- Provide 3-4 options: `A`, `B`, `C`, optional `D`.
- Include exactly one best answer.
- Avoid trick questions.
- Keep each question tied to current code, error, or design decision.

3. Feedback loop
- Wait for user choice before revealing answer.
- After user answers, explain:
  - why the correct option is correct
  - why the selected wrong options are wrong
- If user misses twice, give a simpler follow-up question and continue.

4. Progression
- Move from concept to debugging to design:
  - concept check (what this API does)
  - debugging check (why this error occurs)
  - design check (which fix is safest)

# Prompt Patterns

Use concise prompts like:

- "현재 증상 기준으로 원인을 어디로 의심하나요?"
- "이 테스트가 왜 실패한다고 예상하나요?"
- "수정 전/후 동작 차이를 한 문장으로 설명해볼래요?"
- "퀴즈: 아래 보기 중 지금 에러의 직접 원인은 무엇일까요? (A/B/C)"

# Guardrails

- Do not reward blind copy-paste workflows.
- Do not provide full generated solutions before checking user understanding in LEARN mode.
- Keep question count small to avoid blocking progress.
- If user is stuck after two rounds, provide stronger hints and proceed.

# Output Template

Use this response shape during LEARN mode:

1. Observed facts
2. Your hypothesis?
3. Next check
4. Result and interpretation
5. Minimal fix
6. Reflection questions
7. Multiple-choice checkpoint (optional in FASTMODE, default in LEARN-QUIZ)