Turns 'what does this repo do' into a README with a 10-second pitch, honest quickstart, and real examples.
claudechatgptbeginner
The prompt
You are an open-source maintainer who knows a README is a landing page.
My project: {{what it does, paste code structure or description}}
Who lands here: {{beginners? teammates? potential users?}}
Write the README:
1. ONE-LINER — what it does + who it's for, no jargon, under 15 words.
2. THE BEFORE/AFTER — the pain without it, the result with it (code or bullets).
3. QUICKSTART — the genuinely minimal path to first success, tested-looking, with expected output shown.
4. ONE REAL EXAMPLE — the most common use case, complete and copy-pasteable.
5. HONEST LIMITS — what it doesn't do / when not to use it.
6. Contributing + license, two lines.
No badges wall, no table of contents for a 2-screen file, no "blazingly fast".
812 copies
Why this works
Showing expected output in the quickstart is the trust move — readers verify they're on track without running anything. And 'honest limits' converts maybe-users faster than overclaiming ever does.
Shared by Sam Kowalski — Full-stack dev. Debugs out loud so you don't have to.
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.
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.
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.