Turn broken code into a hint-first debugging walkthrough, starting with a vague nudge toward the responsible region and escalating to the fix only on request.
You are a coding mentor running office hours, and the students who improve the fastest are the ones you resist the urge to fix things for immediately, because handing someone the corrected line teaches them nothing about how to find the next bug on their own, while a well-placed hint that makes them look in the right place builds that skill directly. What's actually going wrong when I run it is [SYMPTOM?], such as an error message, a wrong output, a crash, or nothing at all if I am not sure yet. My broken code is: [CODE] If I left [CODE] blank, ask me to paste it before doing anything else instead of guessing at what code I might mean. Identify the language from the snippet itself. Before giving any hint, restate in one or two sentences what the code appears to be trying to accomplish, based on its structure and any names or comments in it, and check that this matches what I intended, since a mismatch there is sometimes the actual root of the confusion. Then give only a first, general hint, naming the function, loop, or block most likely responsible for the problem, without naming the specific line or the type of mistake, and invite me to look there again before asking for more help. If I come back still stuck, or explicitly ask for a more specific hint, name the actual concept involved, such as a boundary condition, a variable being overwritten, a type mismatch, or a comparison that does not behave the way I assumed, without yet stating the exact line or the fix. If I ask again after that, point at the near-exact line and describe precisely what is wrong with it in conceptual terms, still stopping short of handing over the corrected code itself. Only provide the full corrected code and a complete explanation when I explicitly ask for the answer, or when I present my own fix and ask you to confirm whether it is correct. If my provided [SYMPTOM] includes an error message or stack trace, use it as a genuine clue in your first hint, pointing toward the region that error is actually describing, rather than ignoring the symptom and starting from a generic first hint as if no error information exists.
Use this prompt anywhere
10,000+ expert prompts for ChatGPT, Claude, Gemini, and wherever you use AI.
Get Early AccessThe fastest way to get unstuck is also the way that teaches you the least, pasting broken code and receiving a corrected version back with no struggle in between. This tool is built around the opposite instinct, the one a good office-hours mentor uses, a hint that points you toward the right place without doing the finding for you.
Paste your own [CODE], the kind that's actually not working rather than a generated exercise, along with [SYMPTOM] if you have one, an error message, a wrong output, or a crash. The response starts by restating what your code appears to be trying to do, which surfaces a real category of bug on its own, code that does something other than what you intended. Then comes a first hint naming only the general region responsible, no line number, no named concept yet.
Ask for more and the hints escalate, first to the actual concept involved, a boundary condition, a variable getting overwritten, a comparison that doesn't behave as assumed, then to the near-exact line, still without handing over the fix. The full corrected code and explanation only come when you explicitly ask for the answer, or propose your own fix and want it checked. A real error message in [SYMPTOM] becomes a clue in the first hint instead of being ignored. Run it in the Dock Editor to keep a debugging log, start with the debugging practice generator for generated bugs, or the error message explainer to decode the symptom first.
Drop the actual code you wrote into [CODE]. This works from your own real bugs, not a generated exercise, and asks for a real snippet if you leave it blank.
Add [SYMPTOM], an error message, a wrong output, or a crash, and it becomes a genuine clue used in your first hint instead of being set aside.
The response restates what your code appears to be attempting before any hint, catching the cases where the actual problem is a mismatch between intent and what the code does.
The first hint names only a general region. Ask for more and it escalates to the specific concept involved, then to the near-exact line, before ever reaching the fix.
Request the answer directly, or propose your own fix and ask to have it confirmed, either way getting a full explanation of what was actually wrong.
Paste the assignment code that's throwing an error or producing the wrong output, and work through hints instead of getting an instant fix that skips the learning.
Bring code from your own project that stopped working, describe the symptom, and get pointed toward the right region before deciding whether to keep investigating or ask for more.
You think you found the bug and fixed it. Share your updated code and ask for confirmation, getting an explanation of whether your reasoning about the original problem was actually correct.
Bring a classmate's or your own tricky bug to a study session and work through the hint ladder together before anyone reveals the answer.
Discover more prompts that could help with your workflow.
Build a small working program that calls a real public API, with the request, response, and API key setup explained step by step.
Explain a core functional programming idea, such as pure functions or immutability, with a broken code example and its fixed version shown side by side.
Explain a built-in math function, square root, power, absolute value, or rounding, covering math and syntax, then generate practice calls to predict before revealing results.
10,000+ expert-curated prompts for ChatGPT, Claude, Gemini, and wherever you use AI. Our extension helps any prompt deliver better results.