Engineering

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.

Download LobstackRead the file

In Lobstack: Skills › Library › Add

For your agents

What your agent will do.

A branch is ready for review and needs a description, or the one it has only restates the branch name.

  1. 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.

  2. 02

    Title under 72 characters, saying what the change does for someone using it.

  3. 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.
  4. 04

    Add a screenshot or output for any visible change.

  5. 05

    Skip the file-by-file tour. The diff is already one.

  6. 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

The whole SKILL.md: 35 lines of Markdown.

Add it in the app from Skills › Library, or copy it and paste it into Skills › Add a skill.

pr-description/SKILL.md35 lines
---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.
Agents that start with it

Ready-made agents that follow this skill.

All agents.

More skills

More for your agents, from Engineering first.

All skills, on their shelves.