Below are 15 coding prompts for ChatGPT, Claude, Claude Code and Codex that cover the whole dev workflow: understanding code, debugging, tests, changing code, design, and small but frequent jobs like regex, SQL, commit messages and documentation.
How to use these prompts
Each prompt below is ready to copy into ChatGPT, Claude, Claude Code or Codex. Replace the blanks in double braces, or keep the default after the colon: {{language:TypeScript}} means TypeScript unless you change it.
Two habits matter more than any wording. First, give the model the real material: the code, the full error and stack trace, the schema, the test that fails. Models guess when they lack context, and guesses look confident. Second, ask for a fixed output shape, like "ranked causes, then the fix" or "a test file only". In an agent such as Claude Code or Codex, you can skip pasting and name the files; the agent reads them itself.
For reviewing code before it merges, see the separate code review prompts.
Understand code
1. Explain unfamiliar code
For code you inherited, a library's internals or anything you need to change but didn't write.
Explain this {{language:TypeScript}} code to a developer who is new to the
project.
1. What it does, in two or three sentences.
2. Walk through it step by step, naming the functions and variables.
3. Inputs, outputs and side effects (network, disk, global state).
4. Anything surprising, fragile or likely to break.
{{code}}
2. Map a feature across files
When a feature is spread over many files and you need the path from click to database. Works best in an agent that can read the repo.
I need to understand how {{feature:password reset}} works in this codebase,
end to end.
Trace it from the entry point ({{entry:the API route or UI action}}) to where
data is stored. List each file and function in order with one line on what
it does. Then list the places I would need to change to {{change}}.
Debug
3. Debug from a stack trace
The everyday debugging prompt. Ranking causes keeps the model from fixing the first thing it sees.
Here is an error from my {{language:TypeScript}} app, the stack trace, and the
code it points to.
Error and stack trace:
{{stack_trace}}
Code:
{{code}}
What I was doing when it happened: {{context}}
Give the three most likely causes, ranked, with the line of evidence for
each. For the top cause, show the smallest fix. Tell me what to log or check
if the fix doesn't work.
4. Bug with no error
For wrong output, missing data or "it just doesn't work". Stating expected versus actual is most of the work.
This code runs without errors but gives the wrong result.
Expected: {{expected}}
Actual: {{actual}}
Input that shows it: {{input}}
{{code}}
Trace the input through the code step by step and find where the result
first goes wrong. Explain why, then give the fix and a test case that
covers it.
Tests
5. Write unit tests
Paste the code and one existing test so the new ones match your style.
Write unit tests for the code below using {{framework:Vitest}}.
Cover: the normal case, edge cases (empty, zero, null, very large, unicode
where relevant), and error paths. One behavior per test, with a name that
says what it checks. Match the style of the example test. Don't test private
details that could change without changing behavior.
Code:
{{code}}
Example of an existing test:
{{example_test}}
6. Test for a bug before fixing it
Writing the failing test first proves the bug is real and stays fixed.
Here is a bug report and the code involved. Write a test in
{{framework:Vitest}} that fails because of this bug and will pass once it's
fixed. Don't fix the bug yet. Explain in one sentence why the test fails
today.
Bug: {{bug}}
Code:
{{code}}
Change code
7. Refactor without changing behavior
For code that works but is hard to read or change. The constraint about behavior is the important part.
Refactor this {{language:TypeScript}} code to make it easier to read and
change. Goals: {{goals:smaller functions, clearer names, less duplication}}.
Rules: do not change behavior or the public interface. Keep the same error
handling. If a change is risky, list it instead of making it.
Show the refactored code, then a short list of what changed and why.
{{code}}
8. Write a database migration
Use it for schema changes on a live database. Asking about locks and rollback catches the problems that bite in production.
Write a {{tool:PostgreSQL SQL}} migration that {{change}}.
Current schema:
{{schema}}
The table has about {{rows:1 million}} rows and the app stays live during the
migration. Include:
- The up migration
- A down (rollback) migration
- Whether any step locks the table, and how to avoid it
- Any backfill needed, done in batches
- What the application code must handle while the migration runs
9. Port code to another language
For moving a function or module between languages without losing behavior.
Convert this {{from:Python}} code to {{to:TypeScript}}. Write idiomatic
{{to:TypeScript}}, not a line-by-line copy. Keep the same behavior, including
edge cases and errors. Use the standard library where possible and list any
package you add. Point out anything that behaves differently between the two
languages, such as integer division or date handling.
{{code}}
Design
10. Design an API
Use it before you write the endpoints. Fixing a design is cheap; fixing a public API is not.
Design a {{style:REST}} API for {{feature}}.
Who calls it: {{clients:a web app and a mobile app}}
Data involved: {{data}}
Give me: the endpoints (method, path, purpose), request and response
examples in JSON, error responses with status codes, how auth works, and how
pagination works for lists. Then list two design choices you made and the
alternatives you rejected.
11. Pick a data model
For a new feature that needs tables or documents. It surfaces the questions that are hard to change later.
I'm building {{feature}} with {{database:PostgreSQL}}. Main things it stores:
{{entities}}. Most common queries: {{queries}}.
Propose a schema with tables, columns, types, keys and indexes. Explain how
each common query uses it. Flag anything that will be awkward to change
later, and any question I need to answer before building.
Small but frequent
12. Write a regex
Regex is easy to get almost right. The test cases make it right.
Write a regular expression for {{flavor:JavaScript}} that matches
{{description}}.
Should match:
{{should_match}}
Should not match:
{{should_not_match}}
Give the regex, explain each part, and show a short test that runs it against
every example above.
13. Write or fix a SQL query
Give the schema, and ask in plain language. Asking it to explain the query catches wrong joins.
Schema:
{{schema}}
Write a {{dialect:PostgreSQL}} query that {{question}}.
Explain how the query works in a few lines, note any assumptions about the
data (like nulls or duplicates), and suggest an index if the query would be
slow on a large table.
14. Commit message from a diff
For clear history without the effort. Paste the output of git diff --staged.
Write a commit message for this diff. Format: a summary line under 72
characters in the imperative mood ("Add", "Fix"), a blank line, then a short
body explaining why the change was made and anything a future reader should
know. No bullet list of every file.
{{convention:Use plain messages, not Conventional Commits.}}
{{diff}}
15. Write documentation
For a README, a module's docs or the comment block on a tricky function.
Write {{doc_type:a README section}} for the code below, for
{{audience:a developer setting this up for the first time}}.
Include: what it does in two sentences, how to install or set it up, one
working example, the options or parameters, and common errors with fixes.
Only document what the code actually does. Mark anything you're unsure about
with "Check:".
{{code}}
Make your favorite one a skill
If you run the same prompt every day, stop pasting it. Turn it into a skill, and Claude Code or Codex will use it on its own whenever the task matches. The commit message and stack trace prompts are good first candidates. Paste one into the SKILL.md generator and it becomes a valid SKILL.md, with each blank turned into an instruction like "If the framework isn't given, use 'Vitest'." For more on getting good results from an agent, see Claude Code best practices.
To keep prompts like these one keystroke away, save them in Kipt: paste to save, press ⌘K to find one, and Enter copies it. Blanks open a small fill-in form, and Kipt remembers what you typed last time, so your language and framework are already filled in. Your library lives in your own private GitHub repo, and the prompts you promote to skills install with one command.