Engineering
Commit message from a diff
Write a commit message from a diff: a subject line that states what was found, then prose explaining why the change was made.
Add in the app
Engineering · For your bots
Pull request description
Write a pull request description from the diff: why it exists, what changed, how it was tested, and where a reviewer should look first.
In Lobstack: Skills › Library › Add
Download LobstackWhen to use it
A branch is ready for review and needs a description, or the one it has only restates the branch name.
What your bot will do
- 01
Read the full diff against the base branch, and the linked issue if there is one. Describe the change that is there, not the one that was planned.
- 02
Title under 72 characters, saying what the change does for someone using it.
- 03
Body, in these sections:
- Why: the problem in two or three sentences, linked to the issue or report.
- What changed: the approach, and any choice a reviewer might question with the alternative you rejected.
- Testing: commands run and their result, plus manual steps. If it was not tested, say so.
- Review first: the one or two files where a mistake would hurt most.
- Risk: migrations, config, deploy steps, and how to roll it back.
- 04
Add a screenshot or output for any visible change.
- 05
Skip the file-by-file tour. The diff is already one.
- 06
Show the description before opening or editing the pull request — that is a write to a shared repository.
If the diff mixes unrelated changes, say so and suggest the split instead of describing both as one.
The file
---name: pr-descriptiondescription: "Write a pull request description from the diff: why it exists, what changed, how it was tested, and where a reviewer should look first."metadata: title: "Pull request description" category: engineering tags: [git, review]--- ## When to use this A branch is ready for review and needs a description, or the one it has onlyrestates the branch name. ## How 1. Read the full diff against the base branch, and the linked issue if there is one. Describe the change that is there, not the one that was planned.2. Title under 72 characters, saying what the change does for someone using it.3. Body, in these sections: - Why: the problem in two or three sentences, linked to the issue or report. - What changed: the approach, and any choice a reviewer might question with the alternative you rejected. - Testing: commands run and their result, plus manual steps. If it was not tested, say so. - Review first: the one or two files where a mistake would hurt most. - Risk: migrations, config, deploy steps, and how to roll it back.4. Add a screenshot or output for any visible change.5. Skip the file-by-file tour. The diff is already one.6. Show the description before opening or editing the pull request -- that is a write to a shared repository. If the diff mixes unrelated changes, say so and suggest the split instead ofdescribing both as one.