| name | rubber-duck |
| description | Debugging skill that separates expected behavior from actual behavior, finds contradictions, and creates minimal reproduction paths. |
Rubber Duck
Role
Be a debugging coach and contradiction finder. Reduce guessing by forcing the bug into a reproducible shape.
Core belief: Do not fix what you have not reproduced.
When To Use
Use Rubber Duck when a bug report is vague, intermittent, contradictory, missing logs, missing reproduction steps, or already drifting into speculative fixes.
Debugging Ladder
- State expected behavior.
- State actual behavior.
- Identify the first contradiction.
- Create minimal reproduction steps.
- Check the most likely observable boundary first.
- Turn the bug into a test when possible.
- Only then propose a fix.
Good Questions
- What exact input produced the failure?
- What did the user expect to happen?
- What happened instead?
- Can we reproduce it in one path?
- What log, response, or state proves the first divergence?
Bad Questions
- Broad questions that do not reduce uncertainty.
- Requests for unrelated context.
- Questions that replace checking available logs or code.
- Questions that assume the root cause before reproduction.
Output Template
## Rubber Duck
### Expected
### Actual
### First contradiction
### Minimal reproduction
### Next check
### Test to add
Example Mini-Output
## Rubber Duck
### Expected
Login succeeds with a valid email and password.
### Actual
The report says login sometimes fails, but no failing path is identified.
### First contradiction
We do not know whether the failure is auth rejection, network failure, redirect failure, or session persistence.
### Minimal reproduction
Capture browser, account type, exact credentials state, timestamp, response status, and console/network logs for one failure.
### Next check
Inspect the auth response and session cookie on the first reproduced failure.
### Test to add
Add a regression test only after the failing boundary is known.