10 coding prompts

Implementation, refactoring, review, test generation and debugging — prompts for each stage of development. Written for ChatGPT, Claude, Cursor, GitHub Copilot. Square brackets mark what you fill in; everything else can be pasted as it stands.

Read this code and explain it in this order:

1. What problem it exists to solve, in one sentence
2. The path a typical input takes through it
3. The cases it handles that a naive implementation would not
4. Anything that looks like it was added to fix a specific bug

Do not restate what each line does. If something is unclear from the code alone, say what you would need to see.

<code>
[paste the code]
</code>

Write documentation for the module below, aimed at an engineer who joins the team in a year.

Cover:
- What it is responsible for, and what it deliberately is not
- The one thing someone will get wrong the first time they change it
- Any non-obvious decision and the reason for it, if the reason is visible in the code

Skip anything derivable from the function signatures. Mark with [?] anything you inferred rather than read.

<code>
[paste the module]
</code>

Review the following diff. Ignore naming and formatting entirely — I only want failure modes.

For each issue, give me:
- The specific input or state that triggers it
- What goes wrong as a result
- The smallest change that fixes it

Rank by how likely the trigger is in production. If you find nothing above "theoretically possible", say so rather than filling the list.

<diff>
[paste the diff]
</diff>

Write tests for the function below using [test framework].

Rules:
- Test observable behaviour only. Do not assert on internal calls or private state
- One test per behaviour, named so a failure tells me what broke
- Include the boundary cases: empty input, maximum size, null, and the error path
- Do not test the language or the standard library

List any behaviour you could not test and why.

<code>
[paste the function]
</code>

Here is an error and the surrounding code. Before suggesting a fix:

1. State what the error actually means, mechanically
2. List every condition that could produce it, most likely first
3. For each, tell me the single cheapest thing I can check to rule it in or out

Do not propose a fix until I tell you which check came back positive.

<error>
[paste the error and stack trace]
</error>
<code>
[paste the relevant code]
</code>

Here is a ticket. Turn it into something I can implement.

Produce:
- The behaviour in one sentence, stated as what the user will be able to do
- The cases that must work, as a bulleted list
- The cases that are explicitly out of scope
- Every question whose answer changes the implementation

Do not invent requirements. If the ticket does not say, put it in the questions list.

<ticket>
[paste the ticket]
</ticket>

I am about to change [function or endpoint]. Here is the code and its callers.

Tell me:
- Everything that calls this, directly and indirectly
- Which callers depend on behaviour I am about to change, rather than just the signature
- What would fail silently rather than loudly

Be explicit about what you cannot see. If the call graph is incomplete, say which part.

<code>
[paste the code and callers]
</code>

I want to refactor the code below from [current shape] to [target shape].

Give me a sequence of steps where every step:
- Leaves the code compiling and the tests passing
- Can be reviewed as its own pull request of under 200 lines
- Is described by what it does, not by which lines change

For each step, state what could break and which existing test would catch it. If a step has no test covering it, say so and tell me what to add first.

<code>
[paste the code]
</code>

I am choosing between two approaches for [problem]:

A: [approach A]
B: [approach B]

Compare them on:
- What has to be true for each to be the right choice
- What it costs to switch away from each one in six months
- Which failure is louder — which one breaks visibly versus quietly

End with the condition that would make you change your recommendation. Do not give a balanced summary; pick one.

Write a database migration for [change] on [database].

Requirements:
- Forward and backward migration, both tested against existing data
- Safe to run while the application is serving traffic — state explicitly if it is not
- Note any step that takes a lock, and for how long on a table of [row count] rows

If the change cannot be made safely in one migration, split it into a sequence and say what has to be deployed between the steps.