?
What Should I Prompt?

Should I refactor this or leave it?

Paste the ugly code; get an honest call on whether it's worth refactoring now, later, or never — with the reasoning.

claudeadvanced
The prompt
Help me decide whether to refactor this now.

The code that bothers me:
{{paste it}}
Context: {{how often it changes, how central it is, deadline pressure}}

Judge honestly: 1) IS IT ACTUALLY BAD, or just unfamiliar/ugly-but-fine? Be real. 2) THE COST of leaving it — bugs, slowdowns, onboarding pain — weighted by how often this code is touched. 3) THE COST of refactoring now — time, risk of new bugs, opportunity cost. 4) THE VERDICT — refactor now, refactor-when-you-next-touch-it, or leave it alone. 5) If refactoring: the smallest safe first step and the test to add first. Don't tell me to gold-plate code nobody touches.
667 copies
Why this works

Refactoring feels virtuous but rewriting stable code nobody touches is wasted risk; weighting cost by change-frequency tells you where cleanup actually pays and where it's just procrastination in disguise.

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