Code Writing Prompt: Clean, Testable Function
Defines a contract instead of a wish: language, version, input, output, error cases and tests.
You are a senior engineer. Write code against a contract, not a description. CONTRACT - Language and version: [LANG + VERSION] - Function / class name: [NAME] - Input: [TYPES, RANGES, SHAPE] - Output: [TYPE AND SHAPE] - Error cases: [WHAT MUST THROW OR RETURN AN ERROR] - Constraints: [PERFORMANCE, NO DEPENDENCIES, STYLE] - Existing code style: [STYLE] OUTPUT 1) ASSUMPTIONS — what I did not specify and what you assumed. If an assumption is risky, say so. 2) CODE — complete, runnable, no placeholders. Comments only where the logic is non-obvious. 3) EDGE CASES HANDLED — list, one line each. 4) TESTS — unit tests covering the happy path, two edge cases and one error case. 5) USAGE EXAMPLE — a 5-line snippet that runs. 6) WHAT I WOULD CHANGE AT SCALE — one paragraph on what breaks at 10x volume. RULES - No pseudo-code. No "...". No omitted imports. - Do not add dependencies unless I allow them. - If the request is ambiguous, choose the safer interpretation and flag it in assumptions. - Prefer readable over clever.
If you cannot state the input and output types, the prompt is not ready.
02 — Variables
Fill in the brackets
The highlighted fields are the places where your own details go. You do not have to fill all of them; anything left empty is completed by the model's own assumption.
[NAME]
[TYPE AND SHAPE]
[WHAT MUST THROW OR RETURN AN ERROR]
[STYLE]
[LANG + VERSION]
Field to fill in the prompt
[TYPES, RANGES, SHAPE]
Field to fill in the prompt
[PERFORMANCE, NO DEPENDENCIES, STYLE]
Field to fill in the prompt
03 — How to use
How to use it, step by step
- 01
Name the language version — a solution for Python 3.8 fails on 3.12 syntax differences and vice versa.
- 02
Fill the error cases field; that is where most generated code silently swallows problems.
- 03
Run the tests before reading the code. If they pass, the code is probably fine.
04 — Variations
Same prompt, different result
One prompt does not solve every case. These variations ask for the same job in a different tone, length or format — pick the one that fits.
Add to existing file
Same contract, but the function must fit my existing file: show only the new code and the import changes, nothing else.
With tests first
Same contract, but write the tests first, then the minimal implementation that passes them (TDD).
05 — Tips
Notes that take the result up a level
- Vague requests produce code that compiles but does the wrong thing. The contract is the whole prompt.
- Always ask for assumptions explicitly — that is where the misunderstanding shows up.
06 — FAQ
Frequently asked about Software and Code
Why does generated code fail?
Usually missing context: the framework version, the existing types, the error convention. The contract fields exist to supply exactly that.
Should I trust the code?
Treat it as a competent colleague's first draft. Read it, run the tests, check the error paths. Never ship unreviewed.
Next
You may also find these useful
Debug Prompt: From "Why Doesn't It Work" to a Diagnosis
Converts "why doesn't it work" into a systematic diagnosis: reproduce, hypothesise, isolate, verify.
Intermediate ChatGPTClaudeRefactor Prompt: Improve Without Breaking Behaviour
Simplifies working code without changing behaviour, planned as reversible steps you can review one at a time.
Advanced ChatGPTClaudeSQL Query Prompt (Schema Included)
SQL written without the schema rarely runs; this prompt requires schema, relationships and expected output.
Intermediate ChatGPTClaudeRegex Prompt: Testable Pattern, Not a Guess
Builds regex from test cases rather than guesses: strings that must match, strings that must not, and the explanation.
IntermediateThis page was prepared by the CopyPromt editorial team, first published 25 October 2026. Prompts are written to work across models; brand names are mentioned for identification only.