The public shelf

Help me debug this. Reason through it; do not jump straight to a fix.

Language, framework, and versions: {{environment}}
What I expected to happen: {{expected}}
What happened instead: {{actual}}
What I have already tried: {{tried:nothing yet}}

Work through it in this order:
1. Explain in plain words what the error message means and which part of the system is raising it.
2. Point to the line or call where the problem most likely starts. This is often not the line the error names; say why.
3. List the two to four most likely causes, most likely first. For each, say what in my code or error output points to it.
4. For each cause, give the quickest way to confirm or rule it out: a log line to add, a value to print, a command to run.
5. Give the fix for the most likely cause, as code, and explain why it works.

Rules:
- Base this on the code and error I gave you. If you need something I have not shown (a config file, another function, the full trace), ask for it instead of guessing.
- Do not suggest things I said I already tried.
- If the real issue is a misunderstanding of how the tool or library works, explain that too, so I do not hit it again.

Error output:
{{error}}

Relevant code:
{{code}}

Write unit tests for the code below.

Language and test framework: {{framework}}

Before writing any tests, list the behaviors worth testing, grouped as:
- Normal cases: typical valid input.
- Boundaries: empty, one item, the maximum, zero, negative numbers, the first and last positions.
- Invalid input: wrong type, missing fields, malformed data.
- Failure paths: every error the code can raise or return, and what triggers it.

Then write the tests.
- One behavior per test. Name each test after the behavior it checks, so a failure explains itself.
- Arrange, act, assert, with a blank line between each part.
- Check results, not implementation details. Do not test private helpers directly.
- Mock only what crosses a boundary: network, database, clock, file system, randomness.
- Each test must be able to run alone and in any order.

Rules:
- Match the conventions of the framework I named.
- If the code has behavior that looks like a bug, do not write a test that locks it in. List it under "Possible bugs" and say what you think the correct behavior is.
- If something cannot be tested without changing the code, say what change would make it testable.

Code:
{{code}}

Write a commit message and a pull request description for the change below.

Why I made this change: {{reason}}
Anything reviewers should know (trade-offs, follow-ups, things I am unsure about): {{notes:nothing extra}}

Commit message:
- Subject line: imperative mood ("Add", "Fix", "Remove"), under 72 characters, no full stop.
- Blank line.
- Body: why the change was needed and what it does at a high level. Do not walk through the diff line by line.

Pull request description:
- Summary: what changes for a user or for the system, in two or three sentences.
- Why: the problem or need behind it.
- What changed: a short list by area, not by file.
- How to test: the steps a reviewer can follow to see it working.
- Risks: anything that could break, any migration or config change, and whether it can be rolled back.
- Review focus: the one or two places where a careful second look matters most.

Rules:
- Describe only what the diff actually does. If the diff does something my stated reason does not explain, point it out.
- Do not claim tests were added or run unless the diff shows them.
- Plain language. No "various improvements" or "minor fixes".

Diff:
{{diff}}

Review the code below as a careful senior engineer would. I care about whether it is correct and safe, not how it is formatted.

Language or framework: {{language}}
What the code is supposed to do: {{purpose}}

Look for:
1. Bugs: logic errors, off-by-one mistakes, wrong conditions, unhandled null or empty values, wrong types.
2. Edge cases: empty input, very large input, duplicates, unusual characters, time zones, two things happening at once.
3. Security: unvalidated input, injection, secrets in code, missing permission checks, unsafe handling of files or URLs.
4. Error handling: failures that are swallowed, error messages that leak internals, resources that are never released.
5. Performance, only where it would actually hurt: work repeated inside loops, queries inside loops, loading everything into memory.

For each finding give:
- Severity: critical, high, medium, or low.
- Where: the function or line.
- What goes wrong: a specific input or situation, and the wrong result.
- The fix, as a short code snippet.

Rules:
- Order findings from most to least severe.
- Skip formatting, naming, and anything a linter would catch.
- If you are not sure something is a bug, say so and say what you would check.
- If the code looks correct, say that. Do not invent problems to fill the list.

End with one line: is this safe to ship as it is, yes or no, and why.

Code:
{{code}}

Write a README for my project.

Project name: {{name}}
What it does, in my own words: {{what_it_does}}
Who it is for: {{audience:developers who have never seen this project}}

Sections, in this order:
1. Title and a one-sentence description that says what it does and for whom. No slogans.
2. Why it exists: the problem it solves, in two or three sentences.
3. Quick start: the fewest commands that take someone from nothing to seeing it work.
4. Requirements: runtime versions, system dependencies, accounts or API keys.
5. Installation and configuration: every step, and every environment variable in a table with its purpose and an example value.
6. Usage: two or three realistic examples, with the output to expect.
7. Project structure: only if it helps, and only the top level.
8. Development: how to run it locally, run the tests, and check formatting.
9. Troubleshooting: the two or three problems a newcomer is most likely to hit.
10. License and how to contribute, one or two lines each.

Rules:
- Every command must come from what I gave you. If you are not certain of a command, a version, or a variable name, write [CONFIRM: what to check] instead of guessing.
- Put commands in code blocks, one runnable command per line.
- Write for someone smart who has no context. Do not assume they know the project's internal names.
- No badges, emoji, or marketing language.

What I can tell you about the project (file list, package file, setup notes, anything else):
{{details}}

Explain the code below so I could confidently change it.

My experience level: {{level:comfortable with programming basics, new to this codebase}}
What I am trying to do with it: {{goal:understand it}}

Structure your answer like this:
1. The big picture, in two or three sentences: what this code is for and when it runs.
2. Inputs and outputs: what it takes in, what it returns or changes, and any side effects such as database writes, network calls, or files.
3. A walkthrough in the order the code runs. Group lines into steps and explain each step, not each line.
4. Anything non-obvious: language features, library calls, or patterns I may not know. Explain each in a sentence or two.
5. Why it is probably written this way, where that is not obvious.
6. Gotchas: assumptions the code makes, things that would break if changed carelessly, and anything that looks like a bug.

Rules:
- Use plain words. When you have to use a technical term, define it the first time.
- If what the code does depends on something I have not shown you, say what you are assuming.
- Do not rewrite the code unless I ask.

Code:
{{code}}