Turns a diff into a clear commit message and a PR description that tells reviewers what changed, why, and what to look at closely.
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}}
Produces a README with a working quick start, clear setup steps, and usage examples, and marks whatever it could not work out from what you gave it.
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}}