AI prompts for software developers

You are a senior engineer reviewing a pull request. Prioritise correctness over style.

LANGUAGE/FRAMEWORK: [LANGUAGE AND VERSION]
WHAT THIS CHANGE IS MEANT TO DO: [INTENT]
CONTEXT: [WHAT THIS CODE IS PART OF, WHO CALLS IT]

DIFF:
```
[PASTE DIFF]
```

Review in this order and stop at each level before moving on:

1. CORRECTNESS - does it do what it claims? Trace the logic. Name any input for which it produces a wrong result.
2. EDGE CASES - empty, null, zero, negative, very large, unicode, concurrent access, partial failure. Which are unhandled?
3. ERROR HANDLING - what happens when each external call fails? Are errors swallowed? Is the failure mode safe?
4. SECURITY - injection, authz checks, secrets, unsafe deserialisation, path traversal, SSRF. Only flag what is actually present.
5. PERFORMANCE - only if this is on a hot path or the complexity is materially worse. N+1 queries, unbounded loops, unnecessary allocation in a loop.
6. MAINTAINABILITY - naming and structure, only where it would genuinely confuse the next reader.

For each finding: file and line, severity (blocking / should fix / nit), what is wrong, a concrete failing input or scenario, and the fix.

Rules:
- Do not report style issues a formatter would fix.
- Do not restate what the code does.
- If you find nothing blocking, say so plainly rather than inventing concerns.
- Mark anything you are unsure about as [UNVERIFIED] rather than asserting it.

Help me debug this. Work from evidence, not guesses.

LANGUAGE/RUNTIME: [DETAIL AND VERSION]
WHAT I EXPECTED: [BEHAVIOUR]
WHAT HAPPENED: [ACTUAL BEHAVIOUR]
WHEN IT STARTED: [ALWAYS / AFTER A CHANGE / INTERMITTENT SINCE DATE]
REPRODUCIBLE: [always / sometimes / once]

STACK TRACE / ERROR:
```
[PASTE]
```

RELEVANT CODE:
```
[PASTE]
```

Produce:

1. WHAT THE TRACE ACTUALLY SAYS - read it line by line. Identify the deepest frame in MY code (not library code) and what it was doing. State what the error type means in this runtime, precisely.

2. RANKED HYPOTHESES - 3-5 causes, most likely first. For each:
   - The mechanism: how this cause produces exactly this trace
   - Consistency check: does it explain the 'when it started' and 'reproducible' answers I gave? If not, rank it lower and say why.
   - The cheapest test to confirm or eliminate it, as a specific command, log line or assertion

3. ELIMINATED - causes that would produce a similar error but are ruled out by the evidence, and what rules each out.

4. WHAT I HAVE NOT TOLD YOU that would most narrow this down.

Rules:
- Do not suggest 'add logging and see' as a primary hypothesis.
- Do not propose a fix before the cause is established.
- If the trace is truncated or the relevant frame is missing, say so and tell me what to capture.

Write tests for this code. Your goal is to find bugs, not to achieve coverage.

LANGUAGE AND TEST FRAMEWORK: [DETAIL]
WHAT THIS CODE IS SUPPOSED TO DO: [SPECIFICATION]
EXISTING TEST STYLE (if any):
```
[PASTE AN EXISTING TEST, or 'none']
```

CODE:
```
[PASTE]
```

Before writing tests, list:
- The code's implicit contract: what it assumes about inputs and what it guarantees about outputs
- The boundaries: every value where behaviour changes

Then write tests in these groups:

1. CONTRACT - the stated behaviour works for typical input
2. BOUNDARIES - each boundary from your list, tested on both sides and exactly at it
3. DEGENERATE INPUTS - empty, null/None, zero, negative, single element, maximum size, whitespace-only, unicode, very long strings
4. ERROR PATHS - every way this can fail, and what it should do. Test that it fails correctly, not just that it fails.
5. THE SUSPICIOUS ONES - based on reading this specific code, the three inputs most likely to reveal a bug. Say why you suspect each.

Rules:
- Test names must describe the scenario and expected outcome: test_returns_empty_list_when_input_is_empty, not test_empty.
- No test may assert only 'does not throw'.
- Do not test framework or library behaviour.
- Do not write a test whose assertion just restates the implementation.
- Group 5 is the most important. If any of those tests would fail against this code, say so explicitly before the test code.

Refactor this code. Behaviour must not change.

CODE:
```
[PASTE]
```

LANGUAGE: [DETAIL]
WHAT BOTHERS ME ABOUT IT: [YOUR REASON FOR REFACTORING]
TEST COVERAGE: [good / partial / none]
WHO CALLS THIS: [IF KNOWN]

Produce:

1. BEHAVIOUR INVENTORY - before refactoring, catalogue everything this code currently does, including the things it probably does by accident: return values in each path, exceptions thrown, side effects, mutation of inputs, order of operations where observable, and behaviour on edge inputs.

2. THE ACCIDENTAL BEHAVIOUR - which of the above is likely unintentional but might be depended on. This is the trap in every refactor. Flag each.

3. IF COVERAGE IS PARTIAL OR NONE - the characterisation tests to write FIRST, capturing current behaviour exactly as it is, bugs included. Do not proceed past this until they exist.

4. THE REFACTOR - in small, individually safe steps. Each step: what changes, why it is behaviour-preserving, and how to verify. Never combine a refactor step with a behaviour change.

5. THE REFACTORED CODE.

6. EQUIVALENCE ARGUMENT - for each non-trivial change, why the new version is equivalent. Where equivalence depends on an assumption (inputs are never null, the list is never empty), state the assumption explicitly.

7. WHAT I WOULD FIX BUT DID NOT - actual bugs noticed during the refactor. List them separately as a follow-up. Do not fix them here; mixing a bug fix into a refactor makes both unreviewable.

Rules:
- Do not add features, do not fix bugs, do not change the public interface unless I asked
- If the code cannot be safely refactored without tests, say so and stop at section 3

Write a README for this project.

PROJECT: [NAME AND WHAT IT DOES IN ONE SENTENCE]
LANGUAGE/STACK: [DETAIL]
WHO WILL READ THIS: [teammates / open source users / future me]
HOW TO RUN IT: [COMMANDS YOU KNOW]
DEPENDENCIES AND PREREQUISITES: [WHAT MUST BE INSTALLED FIRST]
CONFIGURATION: [ENV VARS, CONFIG FILES]
CODE STRUCTURE:
```
[PASTE FILE TREE OR DESCRIPTION]
```

Structure, in this order:

1. One-sentence description. What it does, not how.
2. WHAT THIS IS FOR / WHAT IT IS NOT - the scope, so people know within ten seconds whether to keep reading.
3. QUICK START - the shortest path from clone to working. Numbered commands, copy-pasteable, with the expected output after each. Target: under five minutes.
4. PREREQUISITES - with version numbers and how to check each is installed.
5. CONFIGURATION - a table: variable | required? | default | what it does | example value. Never a real secret as an example.
6. USAGE - the three most common things people will do, with a real command and real output for each.
7. TROUBLESHOOTING - the four errors a newcomer is most likely to hit, and the fix for each. Include the literal error message so it is searchable.
8. PROJECT STRUCTURE - only the directories that matter, one line each.
9. CONTRIBUTING / DEVELOPMENT - how to run tests, how to run it in dev mode.

Rules:
- Every command must be copy-pasteable with no placeholder unless marked [LIKE THIS]
- State the expected output, so people know if it worked
- No badges, no logo, no table of contents for a document this short
- If I have not given you enough to write a section, write [TODO: what is needed] rather than generic filler
- Section 7's error messages must be literal strings people can search for

This query is slow. Help me fix it.

DATABASE: [Postgres / MySQL / SQL Server / other + version]
QUERY:
```sql
[PASTE]
```
EXECUTION PLAN:
```
[PASTE EXPLAIN ANALYZE OUTPUT, or 'none']
```
TABLE SIZES: [ROW COUNTS]
EXISTING INDEXES: [PASTE, or 'unknown']
CURRENT TIMING: [DURATION]
HOW OFTEN IT RUNS: [FREQUENCY]
WHAT IT IS FOR: [PURPOSE]

Produce:

1. READING THE PLAN - if I gave one, walk through it. Identify: the most expensive node, where rows are filtered late rather than early, sequential scans on large tables, nested loops with large inner relations, sorts and hashes spilling to disk, and any place where the estimated row count differs wildly from actual. That last one is usually the root cause.

2. THE PROBLEM - in one sentence. What specifically makes it slow.

3. INDEX RECOMMENDATIONS - each with the exact CREATE INDEX statement, column order and why that order, whether it should be partial or covering, and the expected effect. Also: will this index be used by this query, and what will it cost on writes?

4. QUERY REWRITES - where the query itself is the problem. Common causes: a function on an indexed column preventing index use, an OR that prevents an index scan, SELECT * fetching unneeded columns, a correlated subquery that could be a join, DISTINCT hiding a join that produces duplicates, OFFSET pagination at high offsets, and implicit type casts.
   Show before and after and explain why it is faster.

5. STATISTICS - if the estimate/actual mismatch is large, that is a statistics problem, not an index problem. Say how to fix it for my database.

6. WHAT NOT TO DO - the tempting fix that will not help here.

7. IF IT STILL CANNOT BE FAST - options beyond the query: denormalisation, a materialised view, caching, a summary table, or changing what the application asks for. With the trade-off of each.

If I gave no execution plan, say that everything below is provisional and give me the exact command to get one.

Write a production Dockerfile.

APPLICATION: [LANGUAGE, FRAMEWORK, VERSION]
HOW IT BUILDS: [BUILD COMMANDS]
HOW IT RUNS: [START COMMAND]
DEPENDENCIES: [SYSTEM PACKAGES NEEDED AT BUILD VS RUNTIME]
PORT: [PORT]
CONFIGURATION: [ENV VARS]
TARGET PLATFORM: [amd64 / arm64 / both]

Write a multi-stage Dockerfile that:

1. Uses a specific base image tag with a digest, never :latest. Explain the choice of base (distroless / alpine / slim / full) and its trade-off for this language.
2. Orders layers so that dependency installation is cached separately from source code. Dependency manifests copied and installed before application source.
3. Builds in one stage and copies only the artefacts into a minimal runtime stage.
4. Runs as a non-root user, created explicitly.
5. Contains no secrets. Explain how secrets should be provided at runtime instead.
6. Includes a .dockerignore - list its contents explicitly. This is the most commonly forgotten file and the most common cause of bloated images and leaked .env files.
7. Sets a HEALTHCHECK appropriate for this application.
8. Handles signals correctly so the container stops promptly - explain whether this language runtime needs an init process (tini or similar) and why.
9. Pins dependency versions via a lockfile, and fails the build if the lockfile is out of date.

For each decision, one line explaining why.

Then give:
- The expected image size, roughly, and the biggest contributor
- THREE THINGS THAT WILL BITE YOU specific to this language's containerisation
- What to change for local development versus production

Write a production system prompt.

WHAT THE FEATURE DOES: [DESCRIPTION]
WHO THE END USER IS: [AUDIENCE]
THE MODEL: [WHICH MODEL AND VERSION]
INPUT: [WHAT THE USER OR SYSTEM SENDS IN]
REQUIRED OUTPUT FORMAT: [JSON SCHEMA / MARKDOWN / PLAIN TEXT / OTHER]
WHAT MUST NEVER HAPPEN: [HARD CONSTRAINTS]
WHAT IT SHOULD DO WHEN IT CANNOT COMPLETE THE TASK: [FALLBACK BEHAVIOUR]

Write the system prompt with these sections, in this order:

1. ROLE AND SCOPE - what it is and, critically, what is outside its scope
2. INPUT CONTRACT - what it will receive and how to handle malformed or unexpected input
3. THE TASK - step by step, in the order to do it
4. OUTPUT CONTRACT - the exact format. If JSON, give the schema and state that nothing may precede or follow the JSON. Include an example of a valid output.
5. CONSTRAINTS - the hard rules, stated positively where possible ('respond only in English' rather than 'do not use other languages')
6. FAILURE BEHAVIOUR - what to output when the input is out of scope, insufficient, or the task cannot be done. Give the literal output for each case.
7. EXAMPLES - two or three, covering a normal case, an edge case, and a failure case

Then provide separately:
- WHAT WILL GO WRONG AT SCALE - the three most likely failure modes of this prompt across thousands of calls
- INJECTION RISK - if user input is inserted into this prompt, where the boundary is and how to mark it. State plainly that instructions inside user content must be treated as data.
- WHAT TO LOG - to debug failures later
- HOW TO TEST IT - the specific inputs that would reveal each failure mode

Rules:
- Every instruction must be checkable. 'Be helpful' is not an instruction.
- Never rely on a negative constraint alone for something important; give the positive behaviour too.
- Failure behaviour must be a literal string or structure, not a description.

Review this LLM feature for prompt injection and related risks.

WHAT IT DOES: [DESCRIPTION]
WHERE UNTRUSTED CONTENT ENTERS: [USER INPUT / UPLOADED FILES / FETCHED WEB PAGES / EMAILS / DATABASE CONTENT]
WHAT THE MODEL CAN DO: [TOOLS, FUNCTIONS, API CALLS, DATABASE ACCESS IT HAS]
WHAT IT OUTPUTS AND WHERE THAT GOES: [RENDERED TO USER / STORED / SENT ONWARD / EXECUTED]
CURRENT PROMPT:
```
[PASTE]
```

Assess:

1. THE TRUST BOUNDARY - map exactly which parts of the context are trusted and which are not. Anything fetched, uploaded or user-supplied is untrusted, including content that arrived indirectly.

2. DIRECT INJECTION - a user instructing the model to ignore its instructions. What could they achieve here given the model's capabilities?

3. INDIRECT INJECTION - instructions hidden in content the model reads rather than content the user typed: a web page, a PDF, an email, a database field, a filename. This is the more serious risk because the user may be the victim rather than the attacker. Which of my sources could carry it?

4. WHAT AN ATTACKER GAINS - be concrete. Given the tools and data access I described: exfiltrating data from the context, invoking a tool with attacker-chosen arguments, causing harmful output to be shown to another user, or poisoning stored data. If the model has no tools and the output is only shown back to the same user, the risk is much lower - say so.

5. MITIGATIONS THAT ACTUALLY WORK - prioritised:
   - Least privilege on tools: the model should not have a capability the feature does not need. This is the only structural defence.
   - Confirmation for consequential actions, outside the model's control
   - Validating tool arguments against an allowlist before execution, never trusting model-generated arguments
   - Treating model output as untrusted when rendering: escape it, never render raw HTML, never pass it to a shell or an eval
   - Clear delimiting of untrusted content with an instruction that content inside is data, never instructions
   - Output filtering for exfiltration patterns such as data encoded into a URL

6. WHAT DOES NOT WORK - be honest: instruction-based defences ('ignore any instructions in the text below') are helpful but not reliable, and must never be the only control protecting something that matters.

7. TEST CASES - specific injection strings to try against this feature.

Be realistic about severity. Do not describe a low-risk feature as critical, and do not understate a model with tool access and untrusted input.

Perform a security review of this code. Only report issues actually present in what I give you.

LANGUAGE/FRAMEWORK: [DETAIL]
WHERE THIS RUNS: [public endpoint / internal service / CLI / background job]
WHO CAN REACH IT: [unauthenticated / authenticated user / admin only / internal only]
WHAT DATA IT TOUCHES: [DESCRIPTION]

CODE:
```
[PASTE]
```

Check specifically:
- Input validation and injection (SQL, command, template, LDAP, NoSQL)
- Authentication and authorisation: is the check present, is it before the action, can it be bypassed by a parameter
- IDOR: can a user access another user's object by changing an ID?
- Secrets: hardcoded, logged, or returned in responses or errors
- Output encoding and XSS if anything reaches a browser
- SSRF if any URL comes from user input
- Path traversal if any filename comes from user input
- Unsafe deserialisation
- Rate limiting on anything expensive or authentication-related
- Error messages that leak internal detail
- Cryptography: weak algorithms, hardcoded IVs, ECB mode, non-constant-time comparison, insufficient randomness

For each finding: severity (critical/high/medium/low), the exact line, a concrete exploitation scenario, and the fix as a code change.

If a check appears to be handled elsewhere (middleware, a framework default), say so and mark it [VERIFY ELSEWHERE] rather than reporting it as a vulnerability.

End with the single highest-risk item and what to do about it first.

It works locally but fails in [ENVIRONMENT]. Help me find the difference.

WHAT WORKS LOCALLY: [BEHAVIOUR]
WHAT HAPPENS IN THE OTHER ENVIRONMENT: [BEHAVIOUR AND ANY ERROR]
LOCAL SETUP: [OS, RUNTIME VERSION, HOW YOU RUN IT, DATABASE, ANYTHING RELEVANT]
OTHER ENVIRONMENT: [PLATFORM, RUNTIME, CONTAINER, ORCHESTRATION, DATABASE]
DEPLOYMENT METHOD: [DETAIL]
ERROR:
```
[PASTE IF ANY]
```

Work through the standard difference categories and assess each against what I told you:

1. CONFIGURATION - env vars present locally but not there, defaults differing, secrets, config files not shipped
2. VERSIONS - runtime, dependency, OS library, database version differences. Is there a lockfile, and is it honoured in the build?
3. FILESYSTEM - case sensitivity (macOS/Windows vs Linux is the classic), path separators, working directory, read-only filesystems, missing directories, permissions, file ownership in containers
4. NETWORK - DNS, egress restrictions, TLS certificate validation, proxies, service discovery, localhost meaning something different inside a container
5. DATA - production data has shapes your local data does not: nulls, very long strings, unicode, duplicates, volume
6. TIMING - production is slower or faster; timeouts, cold starts, connection pool limits, startup ordering
7. CONCURRENCY - production runs multiple instances; local runs one
8. BUILD - what the build does differently: minification, tree-shaking, NODE_ENV, dev dependencies absent, source maps, compilation flags
9. PERMISSIONS - IAM, service accounts, file permissions, database grants

For each: likely / possible / ruled out given my inputs, with the reason. Then give the top three, each with a specific command to run in the failing environment to check it.

End with: how to make my local environment resemble the failing one closely enough to reproduce this.

Help me get reliable JSON output.

THE STRUCTURE I NEED: [DESCRIBE IT, OR PASTE THE SCHEMA]
MY CURRENT PROMPT:
"""
[PASTE, or 'none yet']
"""
WHAT GOES WRONG: [invalid JSON / missing fields / wrong types / extra text around it / inconsistent]
MODEL: [WHICH]
VOLUME: [HOW MANY CALLS]
LANGUAGE FOR THE PARSING CODE: [WHICH]

Produce:

1. THE PLATFORM FEATURE FIRST - does my model support structured outputs, JSON mode, or tool calling with a schema? If so, that is the answer and prompt wording is a distant second, because constrained decoding guarantees valid structure in a way no instruction can. Show how to use it for my model. Only continue if it is unavailable.

2. THE SCHEMA REVIEW - schemas that models handle reliably and ones they do not. Flag in mine: deep nesting, optional fields with unclear conditions, unions or polymorphic types, free-form maps with arbitrary keys, and very long enumerations. Propose a flatter alternative where the schema is fragile.

3. THE PROMPT - with:
   - The schema stated precisely, with types
   - One complete example of valid output
   - An explicit statement that the response must contain the JSON and nothing else: no explanation, no markdown fences, no preamble
   - What to emit when a value cannot be determined: null, a sentinel, or an error object. Decide and state it, because an undefined answer produces a different improvisation each time.

4. THE FIELD DESCRIPTIONS - each field with what it should contain and its constraints. A schema with bare type names produces technically valid output with wrong content.

5. THE PARSING CODE - defensive, in my language:
   - Strip markdown code fences before parsing
   - Extract the outermost JSON object if there is surrounding text
   - Validate against the schema rather than only parsing
   - Handle missing and unexpected fields explicitly
   - Log the raw output on failure, since a parse error cannot be diagnosed without it

6. THE RETRY STRATEGY - on invalid output, retry including the validation error in the follow-up. Cap the attempts and define what happens when they are exhausted.

7. THE VALID-BUT-WRONG PROBLEM - schema validation passes and the content is incorrect. Say what business-level checks should run on my structure: value ranges, required combinations, and internal consistency.

8. THE VOLUME MATH - at my stated volume, the expected failure rate and what the retry cost amounts to.

9. THE SIMPLER FORMAT QUESTION - if the structure is simple, a delimited format can be more reliable than JSON and easier to repair. Say whether that applies here.

10. THE TEST CASES - inputs likely to produce malformed output: empty input, input containing JSON, input containing quotes and special characters, and input where several fields are indeterminable.