Swipe right for a newer agent. Swipe left for an older agent, Release Notes from Commits.
Issue 43 · 17 Oct 2026 · Easy · Free
Prompt Debugger
Your prompt mostly works, then gives you the same wrong answer every third run. You keep adding IMPORTANT in caps and it gets worse.
Paste a prompt that keeps giving you bad answers, plus one bad answer. Get the exact lines causing it and a fixed prompt.
- Category
- Learning
- Runs in
- ChatGPT
- Claude
- Gemini
- Cursor
What you put in and what you get out
Sample you can paste
MY PROMPT:
You are a helpful support assistant. Summarize this support ticket for the
on-call engineer. Be concise but make sure you cover everything the customer
said. IMPORTANT: always be friendly and empathetic!! Output JSON.
{ticket}
WHAT I WANTED:
A JSON object with severity, product area, one-line summary, and steps to
reproduce. The engineer reads it on their phone at 2am.
ONE BAD ANSWER IT GAVE:
"Hi there! I'm so sorry to hear about the trouble you're having with exports.
It sounds really frustrating. Here's a summary of everything the customer
mentioned..." (four paragraphs, no JSON, no severity)
MODEL: GPT in the API, temperature 0.7. Fails about 1 run in 3.Share this agent
Prompt Debugger — You put in MY PROMPT:. You get out Fixed prompt. Free from One Agent a Day.
30-second demo
0:00
The evidence
Support ticket prompt. Wanted JSON for the on-call engineer. Got four friendly paragraphs and no severity.
How it works
Most broken prompts are not broken everywhere. They work twice, then do something weird on the third run, and the usual fix is to add another line in caps. That usually makes it worse, because now two rules are shouting at each other.
This agent treats it like a bug report. You give it the prompt, what you wanted, and one answer that went wrong. It finds the lines that caused that answer and fixes those. It does not hand you a shiny new prompt that throws away the parts that already worked.
What to paste
The full prompt, word for word. System prompt too, if there is one. Leave template variables like {ticket} in place. Then one bad answer, copied, not described. Add what a good answer looks like and who reads it. Model name, temperature, and failure rate are optional, but they help it tell a prompt bug from plain randomness.
What you get back
A short list of bugs. Each one quotes the line from your prompt that causes it and points at the part of the bad answer it produced. The usual suspects: two rules that can't both be true, a vague ask like "be concise", a format with no example, tone instructions that beat the format, and the model being told who it is but not who reads the answer.
Then the fixed prompt, with your structure kept. Under it, a change list that maps each edit to a bug, so you can undo one if it turns out you needed it. Last, two or three test inputs worth running, picked to hit the edge cases that broke.
If the prompt looks fine and the failure is probably sampling noise, it says so and suggests lowering the temperature or adding an example. It won't make up a bug so it has something to fix.
Use it
Step 1
Collect the evidence
Copy the full prompt exactly as the model sees it, including the system prompt and any template variables. Then grab one bad answer. One real failure tells the agent more than a description of it.
Step 2
Say what good looks like
Write two or three lines about the answer you wanted and who reads it. Add the model, the temperature, and how often it fails if you know them.
Step 3
Paste the prompt
New chat in ChatGPT, Claude, Gemini, or Cursor. Paste the debugger prompt, then your evidence. If it rewrites everything from scratch, reply: keep my structure, change only the broken lines.
Step 4
Test the fix five times
Run the fixed prompt against the input that failed, five times or more. A prompt that fails 1 in 3 can pass once by luck. If it still breaks, paste the new bad answer back in for round two.
Prompt
prompt-debugger.prompt.txt
You debug prompts. You are practical and specific. You treat a bad model answer like a bug report: find the line in the prompt that caused it, fix that line, and leave working parts alone.
INPUT
- The prompt exactly as the model sees it (system prompt included if given). Template variables like {ticket} stay as placeholders.
- What a good answer looks like and who reads it.
- One or more bad answers the prompt produced.
- Optional: model, temperature, how often it fails.
HOW TO WORK
1. Read the bad answer first. List what it got wrong compared with the stated goal.
2. For each problem, find the line or missing piece in the prompt that most likely caused it. Quote the line exactly. If the cause is something missing, say what is missing.
3. Check for these common causes: instructions that conflict; vague asks ("be concise", "make it good"); an output format with no schema or example; tone or persona rules that outrank the format; no named reader; examples that contradict the rules; important rules buried at the end of a long prompt; ALL CAPS or "IMPORTANT" used on several rules at once.
4. If nothing in the prompt explains the failure and it only happens sometimes, say it is probably sampling noise. Suggest lower temperature or one worked example. Do not invent a bug.
5. Fix only what is broken. Keep the user's structure, wording, and any parts that already work.
RULES
- Every bug must quote the prompt line (or name the missing piece) and point to the part of the bad answer it caused.
- No generic advice like "be more specific" without the specific replacement text.
- Do not add a persona, chain-of-thought instructions, or a long preamble unless a bug needs it.
- Keep the fixed prompt about the same length as the original, or shorter, unless an example or schema has to be added.
- If the goal itself is unclear, ask up to three questions instead of guessing, then stop.
OUTPUT
## Bugs found
Numbered. Each: the line quoted from the prompt, what it caused in the bad answer, and why. One to three sentences each.
## Fixed prompt
The full revised prompt in one code block, ready to paste.
## What changed
Bullets. Each change tied to a bug number. Say what to revert if the user needed the old behavior.
## Test it with
Two or three short test inputs or conditions that would have triggered the original bugs. Tell the user to run each one at least five times.Related agents
Swipe sideways
Learning12 Sep 2026 · #08Explain Like I'm ShippingLearn a concept by making the model explain the smallest version you could ship this week, then quiz the gap.InConcept: idempotency keys on a POST that creates an invoice.OutThe quizEasy Preview this drop
- 0:00 The constraintA TypeScript billing API, Postgres already there, one afternoon, no consensus lecture.
- 0:08 The tiny versionA unique key column on invoices, the client sends it, a retry with the same key returns the same invoice row.
- 0:16 Left outNo new queue, no vendor, no lecture about exactly-once delivery in the abstract.
- 0:24 The quizThree questions: where the key is stored, what a second POST returns, and what you do if the key arrives empty.
No daily video for this drop yet. The in and out lines above are the preview.
Coding & Vibe Coding15 Oct 2026 · #41Session HandoffPaste the mess from a coding session. Get a handoff note: what shipped, what is broken, and the exact prompt to paste tomorrow.InBranch: feat/billing-uiOutTomorrow's first promptEasy Preview this drop
- 0:00 The swampBranch feat/billing-ui. Auth works. Billing page half done. Stripe webhook returns 400. Receipt email never fires.
- 0:08 What actually shippedLogin on staging, pricing table render, stripe package installed. Plan change is still a stub. PayPal left alone on purpose.
- 0:16 What is brokenWebhook 400, missing signature check, BillingForm customerId null, receipt email not wired. Ranked by what blocks the rest.
- 0:24 Tomorrow's first promptA paste-ready prompt that starts at the webhook 400, forbids touching PayPal, and asks for a signature check plus a failing test.
No daily video for this drop yet. The in and out lines above are the preview.
Coding & Vibe Coding29 Sep 2026 · #25Env Var AuditorPaste .env.example and the code that reads it. Get missing keys, unused keys, and names that look like live secrets.In.env.exampleOutThe fixMedium Preview this drop
- 0:00 The driftPORT and DATABASE_URL are read. DATABASE_URL is required. FLY_REGION is read and missing from the example.
- 0:08 UnusedNothing in the example is unread. FLY_REGION is the gap, the other way.
- 0:16 The live-looking valueSTRIPE_SECRET_KEY's example starts with sk_live_. That prefix does not belong in an example even if they say it is fake.
- 0:24 The fixAdd FLY_REGION=local. Change the Stripe example to a sk_test_ placeholder. Do not print a real key.
No daily video for this drop yet. The in and out lines above are the preview.
Tomorrow's drop
Get tomorrow's agent in your inbox
One email when the drop goes up. No digest, no course. Unsubscribe from the beehiiv email whenever you want.
Pro and custom
€9/month when Pro opens
Early look at the next drop, a better archive, and the occasional agent that does not fit the public mix. The daily agent stays free. A custom build is €49–199. Nothing is charged from this form.
Join the Pro waitlist