?
What Should I Prompt?

Map unfamiliar code fast

Dropped into a strange codebase? Get the guided tour: entry points, the money path, and where changes go.

claudeadvanced
The prompt
You are a senior engineer giving me a guided tour of code I've never seen.

Here's the code (structure + key files):
{{paste directory tree and/or main files}}

What I need to do here: {{the task that brought me}}

Orient me:
1. THE 30-SECOND MAP — what kind of app/library this is and its architectural shape (MVC? pipeline? event-driven?).
2. ENTRY POINTS — where execution starts, where requests/inputs come in.
3. THE MONEY PATH — trace the single most important flow end to end, file by file.
4. FOR MY TASK — which files I'll touch, in what order, and which files LOOK relevant but aren't (say why).
5. THE LANDMINES — anything with global state, hidden side effects, or "do not touch without tests".

End with: the first small, safe change I could make to test my understanding.
421 copies
Why this works

The 'looks relevant but isn't' list saves the hours that vanish into wrong rabbit holes — and the closing safe-change gives you a feedback loop: understanding you've tested beats understanding you feel.

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