Programming Prompts

Prompts for writing, reviewing, testing and explaining code.

GRAB & GO PROMPTS

Claude

Bug Hunt From Error Message

Finds the likely cause of an error, shows the lines responsible and gives a minimal fix

You are a senior developer debugging with me. Find the cause of the error below. Keep: my code and architecture as they are. Change: only the lines that cause the problem. Never invent functions, library features or APIs you are not sure exist, and do not guess at code you cannot see. If you need more files or output, ask for them. Format: 1. Most likely cause, in two sentences. 2. The exact lines responsible and why. 3. A minimal fix in a code block. 4. Two other possible causes, ranked, with a quick check for each. 5. How to confirm the fix worked. End with a line starting "Unsure:" naming what you assumed. Language and environment: [LANGUAGE, VERSION AND FRAMEWORK] Error message and stack trace: [PASTE THE FULL ERROR] Relevant code: [PASTE THE CODE]
work
Claude

Code Review With Severity Levels

Reviews code and sorts findings into Critical, Major, Minor and Nit, each with a fix

You are a staff engineer doing a code review. Review the code below for correctness, security, readability and maintainability. Keep: my coding style and structure unless it causes a problem. Change: nothing in the code; report only. Never invent problems to fill space, and never claim a bug without naming the line and describing how it fails. Format: a three-sentence summary first. Then group findings under Critical (breaks or is unsafe), Major (likely bug or hard to maintain), Minor and Nit. For each finding give the line or function, what is wrong, why it matters, and a fix in one or two lines. Write "None found" for empty groups. End with what is done well. List anything you were unsure about, including code you could not see. What the code should do: [WHAT THIS CODE IS FOR] Code: [PASTE THE CODE]
work
ChatGPT

Unit Tests for a Function

Writes unit tests for one function, grouped by happy path, edge cases and errors

You are a test engineer. Write unit tests for the function below. Keep: the function exactly as it is. Change: nothing in it. Never invent behavior: if the intended behavior is unclear, test what the code does and flag the case. Do not mock anything you do not need to. Format: one code block with the tests, in the framework I name. Group them as happy path, edge cases (empty, null, boundary values, large input) and error handling. Name each test after the behavior it expects. Add a short comment above any non-obvious case. After the code, list the branches or cases that are not covered and why. End with a line starting "Unsure:" for any assumption about intended behavior. Language and test framework: [LANGUAGE AND TEST FRAMEWORK] Function: [PASTE THE FUNCTION]
work
Gemini

Explain Code to a Junior

Walks through a piece of code step by step in plain words for a junior developer

You are a patient senior developer explaining code to a junior colleague who knows the basics of the language but not this codebase. Keep: the code as written. Do not fix or change it while explaining. Change: nothing, but put every step into plain words. Never invent what a function from outside the snippet does; if you cannot see it, say so and say what you would check. Format: 1. One paragraph on what the code does overall. 2. A step-by-step walk-through in order, quoting the line each step refers to. 3. A short glossary of terms or patterns a junior may not know. 4. Three questions I can ask myself to check I understood. 5. Anything that looks risky or confusing. End with a line starting "Unsure:" for anything you could not confirm. Language: [LANGUAGE] Code: [PASTE THE CODE]
learning
Any AI chat

Regex Builder With Test Cases

Builds one regex with a plain-English breakdown and a table of match and non-match tests

You are a regular expression specialist. Build one regex for the job below and prove it with test cases. Keep: to the regex flavor I name. Change: nothing outside the pattern. Never use features the flavor does not support, and prefer a readable pattern over a clever one. Format: 1. The regex in a code block, with flags. 2. A plain-English breakdown of each part. 3. A table of at least 8 test strings: 4 that should match and 4 that should not, with the expected result and the reason. Include edge cases. 4. Known limits: inputs where the pattern could give the wrong answer. End with a line starting "Unsure:" for any rule in my description that was ambiguous, and how you read it. Language or regex flavor: [LANGUAGE OR FLAVOR] What it should match and what it should reject, with examples: [DESCRIBE THE RULES]
work
Any AI chat

SQL Query From Plain English

Writes one SQL query from your question and schema, with an explanation and index notes

You are a database analyst. Write one SQL query that answers my question, using only the schema I provide. Keep: table and column names exactly as in the schema. Change: nothing in the schema. Never invent tables, columns or relationships. If the schema cannot answer the question, say what is missing instead of guessing. Use the SQL dialect I name. Format: 1. The query in a code block, one clause per line. 2. A step-by-step plain-English explanation. 3. A tiny example of the result, as a table. 4. Performance notes: which columns would benefit from an index. End with a line starting "Unsure:" for any assumption about how the question maps to the data, such as how you treated nulls or duplicates. SQL dialect: [YOUR SQL DIALECT] Schema: [PASTE YOUR CREATE TABLE STATEMENTS] Question: [YOUR QUESTION IN PLAIN ENGLISH]
work
Claude

Refactor Without Changing Behavior

Cleans up code structure while keeping behavior the same, and lists every change

You are a careful refactoring engineer. Improve the readability and structure of the code below without changing what it does. Keep: public names, signatures, inputs, outputs, side effects and error behavior exactly the same. Change: internal names, structure, duplication and nesting. Never add features or dependencies, and never fix a bug silently. If you spot a bug, report it separately and leave it in place. Format: 1. The refactored code in one code block. 2. A numbered list of each change and why it is behavior-safe. 3. Bugs or risks you noticed but left unchanged. 4. Tests I should run to confirm nothing changed. End with a line starting "Unsure:" for any change where equal behavior is not certain. Language and what to improve: [LANGUAGE AND WHAT YOU WANT IMPROVED] Code: [PASTE THE CODE]
work
ChatGPT

README for a Module

Writes a README for a module from its code: setup, usage, options and limits

You are a technical writer who documents code for the next developer. Write a README for the module below. Keep: names, signatures and behavior exactly as in the code. Change: nothing in the code. Never invent features, options, config values or examples the code does not support. If something is unclear, mark it "to be confirmed" instead of guessing. Format, in Markdown: a title with a one-sentence purpose; setup; a minimal usage example that could be run; a table of public functions or options with parameters, return values and defaults; error handling and known limits; how to run the tests. Stay under 500 words and skip sections that do not apply. End with a list of what you could not determine from the code and anything you were unsure about. Module name and who will use it: [MODULE NAME AND AUDIENCE] Code: [PASTE THE CODE]
work
Any AI chat

Convert Code Between Languages

Ports code to another language and flags behavior differences you should check

You are a developer who ports code between languages. Convert the code below. Keep: behavior, public interface, comments, and structure where the target allows. Change: syntax, standard-library calls and idioms, so the result reads naturally in the target language. Never invent libraries, and never skip a part because it is hard. Mark any piece with no direct equivalent with a comment starting "PORT NOTE". Format: 1. The converted code in one code block. 2. A table of the main mappings, source construct to target construct. 3. Behavior differences that could surprise me, such as integer size, string encoding, error handling and ordering. 4. A small test I can run in both languages to compare results. End with a line starting "Unsure:" for anything you were not certain about. Source language, target language and target version: [SOURCE, TARGET AND TARGET VERSION] Code: [PASTE THE CODE]
work
Any AI chat

Commit Message From a Diff

Writes a commit message from a diff, with two alternative subject lines

You are a developer who writes clear commit messages. Write a commit message for the diff below. Keep: only what the diff shows. Never invent a reason, ticket number or behavior the diff does not show. If the reason is not visible, leave it out and tell me. Format: 1. A subject line of 72 characters or fewer, in the imperative mood, in the form "type: summary", with no full stop. 2. A blank line. 3. A body that explains what changed and why, wrapped at 72 characters, as short bullets. 4. A footer only if I give a ticket number. Then give two alternative subject lines. If the diff mixes unrelated changes, say so and suggest how to split it. End with a line starting "Unsure:" for anything you inferred. Ticket number, if any: [TICKET NUMBER OR NONE] Diff: [PASTE THE DIFF]
work
ChatGPT

API Client From Endpoint Description

Writes a small API client from an endpoint description, with error handling and an example

You are a backend developer writing a small, readable API client. Build a client for the endpoints described below. Keep: URL paths, methods, parameter names and field names exactly as described. Change: nothing about the API. Never invent endpoints, headers, auth schemes or response fields. If something is not described, add a marked TODO and ask me. Read secrets from environment variables, never hard-code them. Format: 1. The client code in one code block, one function per endpoint, with typed inputs and outputs where the language allows. 2. Clear errors for timeouts, non-success status codes, rate limits and invalid JSON. 3. A short usage example. 4. A list of the assumptions you made. End with a line starting "Unsure:" for anything the description left open. Language and HTTP library: [LANGUAGE AND HTTP LIBRARY] Endpoint description (URL, method, auth, parameters, example response): [PASTE THE ENDPOINT DOCS]
work
Claude

Rubber Duck Debugging Interview

Interviews you one question at a time to help you find a bug yourself

You are a rubber duck that asks good questions. Help me find my bug by interviewing me, not by handing me answers. Keep: one question at a time, and wait for my reply before the next. Change: your questions as you learn more, narrowing from what I expect, to what happens, to where they differ. Never offer a diagnosis before I have answered at least five questions, and never rewrite my code unless I ask. Format: each turn is one short question plus one line saying why you ask it. When I write "summary", stop and recap what we found, the most likely cause, the next experiment to try, and anything you were unsure about. Ask the first question now. What I am building and in which language: [WHAT YOU ARE BUILDING AND IN WHAT LANGUAGE] The problem in my own words: [DESCRIBE THE BUG OR UNEXPECTED BEHAVIOR]
learning