Code review prompts

Review this diff as a senior engineer who cares about correctness first, then clarity.

```diff
{{diff}}
```
Context: {{what_the_change_does}}

Output:
1. **Blocking issues** (bugs, security, data loss, race conditions) with line references and a suggested fix.
2. **Should fix** (error handling, edge cases, missing tests).
3. **Nits** (naming, style): max 5.
4. What's good about the change (1-2 lines).
If you're unsure whether something is a bug, say so and explain what would confirm it. Don't invent issues to fill sections.

Review this diff as a senior engineer who cares about correctness first, then clarity. ```diff {{diff}} ``` Context: {{what_the_change_does}} Output: 1. **Blocking issues** (bugs, security, data loss, race conditions) with line references and a suggested fix. 2. **Should fix** (error handling, edge cases, missing tests). 3. **Nits** (naming, style): max 5. 4. What's good about the change (1-2 lines). If you're unsure whether something is a bug, say so and explain what would confirm it. Don't invent issues to fill sections.

Do a focused security review of this code for a {{app_type}} app:

```
{{code}}
```

Check specifically for: injection (SQL, command, template), XSS, auth/authorisation gaps (IDOR), secrets in code, unsafe deserialisation, SSRF, path traversal, missing rate limits, insecure defaults, and dependency risks you can see.
For each finding: severity (high/med/low), exploit scenario in one sentence, and the fix. If nothing is found in a category, say "none found" rather than speculating.

Do a focused security review of this code for a {{app_type}} app: ``` {{code}} ``` Check specifically for: injection (SQL, command, template), XSS, auth/authorisation gaps (IDOR), secrets in code, unsafe deserialisation, SSRF, path traversal, missing rate limits, insecure defaults, and dependency risks you can see. For each finding: severity (high/med/low), exploit scenario in one sentence, and the fix. If nothing is found in a category, say "none found" rather than speculating.

This code was written by an AI assistant. Review it with that in mind:

```
{{code}}
```

Look for typical AI-code problems: invented APIs or library functions that don't exist, outdated syntax, silently swallowed errors, over-engineering, duplicated helpers that already exist in the codebase, tests that don't really test anything, hard-coded values, and comments that don't match the code.
List each problem with the fix. Then rate: merge / merge after fixes / rewrite.

This code was written by an AI assistant. Review it with that in mind: ``` {{code}} ``` Look for typical AI-code problems: invented APIs or library functions that don't exist, outdated syntax, silently swallowed errors, over-engineering, duplicated helpers that already exist in the codebase, tests that don't really test anything, hard-coded values, and comments that don't match the code. List each problem with the fix. Then rate: merge / merge after fixes / rewrite.

Write tests for this {{language}} code using {{test_framework}}:

```
{{code}}
```

- Cover: happy path, edge cases (empty, null, boundaries, large inputs), and error paths.
- One behaviour per test, descriptive names ("returns X when Y").
- Mock only external I/O; don't mock the code under test.
- After the tests, list any behaviour that looks like a bug: write a failing test for it and flag it rather than "fixing" the expectation.

Write tests for this {{language}} code using {{test_framework}}: ``` {{code}} ``` - Cover: happy path, edge cases (empty, null, boundaries, large inputs), and error paths. - One behaviour per test, descriptive names ("returns X when Y"). - Mock only external I/O; don't mock the code under test. - After the tests, list any behaviour that looks like a bug: write a failing test for it and flag it rather than "fixing" the expectation.

Refactor this code for readability without changing behaviour:

```
{{code}}
```

Constraints: same public interface, same outputs, no new dependencies. Explain each change in one line. If a change could alter behaviour in an edge case, call it out explicitly. Suggest tests that would prove behaviour is unchanged.

Refactor this code for readability without changing behaviour: ``` {{code}} ``` Constraints: same public interface, same outputs, no new dependencies. Explain each change in one line. If a change could alter behaviour in an edge case, call it out explicitly. Suggest tests that would prove behaviour is unchanged.

Write a pull request description from this diff:

```diff
{{diff}}
```

Format: **Summary** (2-3 sentences, the why), **Changes** (bullets), **How to test** (numbered steps), **Risks / rollout notes**, **Screenshots** (placeholder if UI changed). Be factual; don't describe changes that aren't in the diff.

Write a pull request description from this diff: ```diff {{diff}} ``` Format: **Summary** (2-3 sentences, the why), **Changes** (bullets), **How to test** (numbered steps), **Risks / rollout notes**, **Screenshots** (placeholder if UI changed). Be factual; don't describe changes that aren't in the diff.

I'm upgrading {{package}} from {{old_version}} to {{new_version}} in a {{stack}} project.

1. List the breaking changes between these versions you know of (say if unsure about any; your knowledge may be outdated, so tell me where to verify).
2. Show me how to search my codebase for affected usages (grep patterns).
3. Give an upgrade plan with a rollback step.

I'm upgrading {{package}} from {{old_version}} to {{new_version}} in a {{stack}} project. 1. List the breaking changes between these versions you know of (say if unsure about any; your knowledge may be outdated, so tell me where to verify). 2. Show me how to search my codebase for affected usages (grep patterns). 3. Give an upgrade plan with a rollback step.