?
What Should I Prompt?

Rubber-duck my approach before I build

Talk through your plan; get the flaws, the simpler path, and the edge cases surfaced before you write code.

claudechatgptintermediate
The prompt
Be my rubber duck. I'm about to build something — poke holes before I waste a day.

What I'm building & why: {{the goal}}
My planned approach: {{how you intend to do it}}
Constraints: {{stack, deadline, scale}}

Respond: 1) PLAY IT BACK — restate my plan so I know you understood. 2) THE FLAWS — where this breaks, gets slow, or gets painful to maintain. Rank by likelihood. 3) THE SIMPLER PATH — is there a materially easier approach I'm overcomplicating past? 4) THE EDGE CASES I haven't mentioned. 5) THE FIRST STEP if the plan holds. Push back honestly — don't just validate me.
1,287 copies
Why this works

The costliest bugs are architectural and invisible until you've built the wrong thing; a skeptical playback before you type surfaces the simpler path while changing course is still free.

Shared by Sam Kowalski Full-stack dev. Debugs out loud so you don't have to.

More like this

Coding & Dev·Beginner

Fix my bug, then teach me why

Root cause in one sentence, the minimal fix, then the misconception that caused it — so it's your last time.

You are a senior engineer doing a patient code review. Here's my error: {{paste the full error message}} Here's the relevant code: {{paste the smallest chunk that reproduces it}} Respond in exactly this order: 1. ROOT CAUSE — one sentence, no hedging. 2. THE MINIMAL FIX — smallest possible diff, shown as before/after. 3. THE MISCONCEPTION — what I likely misunderstood for this bug to exist, explained like I'm smart but new to this corner of the language. 4. THE SMELL TEST — one thing to check elsewhere in my codebase where I've probably made the same mistake. Do not refactor unrelated code. Do not add features.
5,236 copiesby Sam Kowalski
Coding & Dev·Intermediate

The pre-PR code review

A structured review of your diff before teammates see it — correctness, naming, and the question you'll get asked.

You are the most thorough reviewer on my team — kind, but nothing gets past you. Here's my diff: {{paste your diff or changed files}} Context: {{what this change is supposed to do}} Review it: 1. CORRECTNESS — bugs, edge cases, race conditions. Rank by severity; say "solid" if it's solid. 2. NAMING & CLARITY — the 3 spots a stranger would misread first. 3. THE QUESTION — what will a reviewer inevitably ask about this diff? Draft my answer. 4. TESTS — the one test that's missing and would catch a real regression. Skip style nitpicks a linter would catch.
2,542 copiesby Sam Kowalski
Coding & Dev·Intermediate

Get me out of this git mess

Describe the git situation you're stuck in; get the exact safe commands and what each one does — no data loss.

I'm stuck in git. Help me fix it without losing work. What happened / what I want: {{describe — wrong branch, bad commit, need to undo, merge conflict, detached head...}} Output of git status (and git log if relevant): {{paste}} Give me: 1) WHAT STATE I'm actually in, plainly. 2) THE SAFE FIX — exact commands in order, with what each does and why. Prefer non-destructive options; clearly flag anything that discards work before I run it. 3) HOW TO VERIFY it worked. 4) THE HABIT that prevents this next time. Assume I'll paste your commands literally — don't hand-wave.
1,456 copiesby Sam Kowalski