8 packs, one for each part of the job

You are a senior [LANGUAGE] engineer. Write [FUNCTION OR MODULE] that does the following:
[REQUIREMENTS]

Rules:
- Idiomatic [LANGUAGE]. Small single-purpose functions and descriptive names.
- Validate inputs at the boundary and fail with clear error messages.
- No placeholder code, no TODOs, no unused imports.
- Type annotations and a one-line docstring on every public function.

Return, in this order:
1. The code.
2. Three edge cases it handles and how.
3. One assumption you made that I should confirm.

Act as my debugging partner. Do not propose a fix yet.

What happens: [ACTUAL BEHAVIOUR]
What should happen: [EXPECTED BEHAVIOUR]
Stack trace or logs: [PASTE]
Relevant code: [PASTE]

Step 1. List the three most likely root causes, ranked, with the evidence for each.
Step 2. For the top cause, give the smallest experiment that confirms or rules it out.
Step 3. Wait for my result. Only then write the minimal fix and a regression test.

If the evidence is not enough to rank the causes, say what you need to see.

I want to build: [ONE-PARAGRAPH IDEA]
Stack: [STACK, OR "RECOMMEND ONE AND SAY WHY"]
Time I have: [HOURS OR DAYS]

Produce a build plan with:
1. The smallest version worth shipping, as five user stories at most.
2. The data model: tables or collections, fields and relations.
3. The routes or screens, each with its inputs and outputs.
4. Build order as numbered steps, each one runnable and testable on its own.
5. What you deliberately left out, and why.

Ask me up to three questions first if an answer would change the plan.

Here is a git diff: [PASTE DIFF]

Write:
1. A conventional commit message. Subject under 60 characters, body explains why.
2. A pull request description with these sections: What changed, Why, How to test,
   Risks.
3. A checklist of anything in the diff that looks unfinished or untested.

Describe only what the diff shows. If the reason for a change is not clear from the
code, write "Reason not stated" instead of guessing.

Review this code as a senior engineer who will have to maintain it: [PASTE CODE]
Context: [WHAT IT DOES AND WHERE IT RUNS]

Report findings in three groups:
- Must fix: bugs, security issues, data loss risks.
- Should fix: unclear naming, duplication, missing error handling.
- Consider: style and structure suggestions.

For each finding give the line, the problem in one sentence and the corrected code.
Do not rewrite the whole file. If the code is fine, say so.

Follow this specification exactly: [PASTE SPEC]

Before you answer:
1. Restate the task in one sentence.
2. List anything the spec leaves undefined. Do not fill gaps with assumptions.

When you answer:
- Use only the libraries, versions and APIs named in the spec.
- If you are not certain an API exists, say so instead of inventing it.
- Output in this format and nothing else: [FORMAT]

Finish with a line that starts "Checked against spec:" and lists each requirement
with pass or fail.

I am designing: [SYSTEM IN ONE PARAGRAPH]
Constraints: [TRAFFIC, TEAM SIZE, BUDGET, DEADLINE]
My current plan: [DESCRIBE OR PASTE]

Act as a principal engineer reviewing this design.
1. Name the two decisions in my plan that will be hardest to reverse later.
2. For each one, give two alternatives with the trade-off in one line each.
3. List what breaks first at ten times the load, and the cheapest fix.
4. Recommend one design and say what would change your mind.

Stay within my constraints. Do not suggest tools I did not ask about unless one
removes a real risk, and say which risk.

Write tests for this code: [PASTE CODE]
Test framework: [FRAMEWORK]

First, list the behaviours worth testing as one line each, grouped into:
- Normal use
- Edge cases: empty, zero, very large, wrong type
- Failure paths: what should raise or return an error

Then write the tests. One behaviour per test, named after the behaviour.
Do not test implementation details or private helpers.
If part of the code cannot be tested without a change, say what change and why.