Standardize git changes before opening a pull request
Describe one finished change, generate a Conventional Commit and branch name, then use the same evidence for the pull request description. Review repo instructions before the PR when the change adds new commands, boundaries, or operating rules.
The chain
- 01
Name the completed change
Describe the behavior, affected scope, and whether it is a feature, fix, refactor, test, or documentation change.
You get: A Conventional Commit subject and body based on the actual work.
- 02
Create the branch name
Use the same scope and outcome to generate a short branch name.
You get: A branch name that matches the commit intent.
- 03
Write the pull request description
Add the changed behavior, test evidence, risks, and rollout notes.
You get: A review-ready PR description grounded in the diff and checks.
- 04
Check repository instructions
Review CLAUDE.md or AGENTS.md if the change adds commands, file boundaries, or new operating rules.
You get: Repository instructions that match the shipped workflow.
The prompt for the thinking step
Prepare one evidence-backed PR summary
Paste the diff summary and test output. Do not use plans or intended work as proof.
Write a pull request summary from the evidence below. Return Markdown only. <change_summary> [PASTE THE DIFF OR CHANGE SUMMARY HERE] </change_summary> <verification> [PASTE THE TEST AND BUILD RESULTS HERE] </verification> Use these sections: ## What changed ## Why ## Verification ## Risks and limits Rules: - Describe completed behavior, not planned work. - Name failed or skipped checks plainly. - Do not claim deployment, browser coverage, or production verification unless the evidence shows it. - Keep the summary short enough for a reviewer to scan before opening the diff.
Run it now
Describe your change in plain English, get a Conventional Commits message with the right type, scope, subject, and release signal. Includes commitlint and semantic-release examples. Free, no login.
Generate the commit messageQuestions people ask
Should I create the commit before the branch name?
The order is flexible. Use the same concise change description for both so the branch and commit communicate one logical unit.
Does the PR description tool read my git repository?
No. Paste the change summary and verification evidence yourself. The tool does not inspect GitHub or your local files.
When should repo instructions change with a PR?
Update them when the change adds a required command, a new file boundary, a test or deploy step, or a durable rule agents must follow.
More tools for “Standardize commits and PRs”
Make every commit message, branch name, PR description, and agent instruction file follow the same rules.