Request templates

Project: <stack, versions>. File: <path>.
I need a function <name>: it takes <what>, returns <what>.
Edge cases: <empty / network error / no data>.
Constraints: don't add new libraries, match the file's style.
Show only the changed fragment.

What I do: <steps>.
What I expect: <result>. What I get: <result>.
The error in full: <text with the traceback>.
Versions: <language, libraries>.
Tell me the cause first. The fix after I say yes.

Here is the code: <fragment>.
The behaviour mustn't change. I need: <what exactly to improve>.
Don't touch: <files, functions>.
Show a diff rather than the whole file, and explain each change in one line.

Explain this code line by line, to someone who knows the
basics but doesn't know this library.
Separately: what could break here and with what data.

Review this: <code>.
Look for: unhandled errors, edge cases, leaked secrets,
unnecessary dependencies, places where the behaviour isn't obvious.
Format: a list, one line per finding, with the line number.
Don't rewrite the code.

Write tests for <function/module>, pytest.
Cover: the ordinary case, the edges, empty input, an error.
No mocks where they can be avoided.
One assertion per test, and the test's name describes the case.

The task: <description>.
Don't write code. The plan first: which files you'll touch,
what changes in each, in what order.
Code after I say yes.

Before writing any code, ask me the questions whose answers
would change the solution. One at a time.
If you have no questions, say what assumptions you're making.

Change only the file <path> and only the function <name>.
Don't touch anything else. If the solution needs something
else touched, say so, but don't do it.

The idea: <two or three sentences>.
Ask me one question at a time and wait for the answer:
what it does in one sentence; what is stored; where it's stored;
who uses it and how many; what can't be lost;
external services and behaviour when they fail; what changes most;
environments and secrets; starting and restarting; how I find out it broke.
Don't write code. At the end, gather the answers into a mini-spec.

The idea: <description>. Don't write code. Break it into parts:
1) what is stored — entities with their fields
2) what happens — actions
3) what's visible from outside — screens or addresses
For each action, say which entities it touches.

Here is the project tree and the key files.
Assemble a draft brief in six blocks: what it is, stack,
structure, dependencies, where things live, what not to do.
Where you aren't sure, write "?" — don't invent.

Here is the brief and the code you wrote.
Check your code against the brief: dependencies,
file locations, the ban on new libraries.
Violations as a list.

The project builds for me but fails after installation.
List how running in development differs from the artifact
in this project: paths, environment variables, assets, versions.
One point per line.

The build fails: <error>. I want two options:
a code fix and a build-settings fix.
For each, say what will stop being checked.
I'll choose.

I'm changing <a field / a schema / an endpoint>.
Old clients don't update immediately.
What breaks for them and how do I make this change without
breaking them? Separately: which part can't be rolled back.

Draw up a shipping checklist for my project.
Stack: <list it>. Shipped to: <where>.
Split it into "once per project" and "before every release".
Only mine, no general advice.