{"version":"1.1.0","schema":"https://oneagentaday.com/api/schema.json","agent":{"title":"Prompt Debugger","slug":"prompt-debugger","date":"2026-10-17","issue":43,"category":"learning","categoryLabel":"Learning","tags":["prompting","prompt-engineering","debugging","vibe-coding"],"difficulty":"easy","runtimes":["ChatGPT","Claude","Gemini","Cursor"],"excerpt":"Paste a prompt that keeps giving you bad answers, plus one bad answer. Get the exact lines causing it and a fixed prompt.","problem":"Your prompt mostly works, then gives you the same wrong answer every third run. You keep adding IMPORTANT in caps and it gets worse.","videoUrl":null,"url":"https://oneagentaday.com/agents/prompt-debugger","apiUrl":"https://oneagentaday.com/api/agents/prompt-debugger.json","promptUrl":"https://oneagentaday.com/agents/prompt-debugger/prompt.txt","configUrl":null,"configFilename":null,"license":"CC-BY-4.0","howItWorks":"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.\n\nThis 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.\n\n## What to paste\n\nThe 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.\n\n## What you get back\n\nA 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.\n\nThen 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.\n\nIf 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.","steps":[{"name":"Collect the evidence","text":"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."},{"name":"Say what good looks like","text":"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."},{"name":"Paste the prompt","text":"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."},{"name":"Test the fix five times","text":"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."}],"demo":[{"second":0,"label":"The evidence","detail":"Support ticket prompt. Wanted JSON for the on-call engineer. Got four friendly paragraphs and no severity."},{"second":8,"label":"Bug 1: rules that fight","detail":"'Be concise' vs 'cover everything the customer said'. The model picks 'everything' and writes four paragraphs."},{"second":16,"label":"Bug 2 and 3","detail":"'Always be friendly!!' outranks the format, so it writes to the customer. 'Output JSON' has no schema and no example."},{"second":24,"label":"Fixed prompt","detail":"Reader named, friendliness rule cut, JSON schema with one filled example, and a 'no prose outside the JSON' line. Each change tied to a bug."}],"sampleInput":"MY PROMPT:\nYou are a helpful support assistant. Summarize this support ticket for the\non-call engineer. Be concise but make sure you cover everything the customer\nsaid. IMPORTANT: always be friendly and empathetic!! Output JSON.\n\n{ticket}\n\nWHAT I WANTED:\nA JSON object with severity, product area, one-line summary, and steps to\nreproduce. The engineer reads it on their phone at 2am.\n\nONE BAD ANSWER IT GAVE:\n\"Hi there! I'm so sorry to hear about the trouble you're having with exports.\nIt sounds really frustrating. Here's a summary of everything the customer\nmentioned...\" (four paragraphs, no JSON, no severity)\n\nMODEL: GPT in the API, temperature 0.7. Fails about 1 run in 3.\n","prompt":"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.\n\nINPUT\n- The prompt exactly as the model sees it (system prompt included if given). Template variables like {ticket} stay as placeholders.\n- What a good answer looks like and who reads it.\n- One or more bad answers the prompt produced.\n- Optional: model, temperature, how often it fails.\n\nHOW TO WORK\n1. Read the bad answer first. List what it got wrong compared with the stated goal.\n2. 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.\n3. 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.\n4. 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.\n5. Fix only what is broken. Keep the user's structure, wording, and any parts that already work.\n\nRULES\n- Every bug must quote the prompt line (or name the missing piece) and point to the part of the bad answer it caused.\n- No generic advice like \"be more specific\" without the specific replacement text.\n- Do not add a persona, chain-of-thought instructions, or a long preamble unless a bug needs it.\n- Keep the fixed prompt about the same length as the original, or shorter, unless an example or schema has to be added.\n- If the goal itself is unclear, ask up to three questions instead of guessing, then stop.\n\nOUTPUT\n## Bugs found\nNumbered. Each: the line quoted from the prompt, what it caused in the bad answer, and why. One to three sentences each.\n\n## Fixed prompt\nThe full revised prompt in one code block, ready to paste.\n\n## What changed\nBullets. Each change tied to a bug number. Say what to revert if the user needed the old behavior.\n\n## Test it with\nTwo 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.","config":null}}