Pull Request + Merge Request Style Guide

Overview

A good pull request description is a Markdown document that tells the story of the accompanying git diff. It is intended for human consumption and should use plain language, read clearly and be easy to follow.

When to Use

Use this skill any time you are tasked with creating a pull request on GitHub. The output will be a markdown document that follows the style guide and meets the accompanying verification.

Structure

A good pull request tells the story of the change and is intended to add color and context that is not or cannot be conveyed in the source code.

It should aim to be concise and use paragraphs and prose where appropriate rather than bullet points to improve readability and tell the story. Bullet points can be used for lists when semantically appropriate.

Code examples and diagrams (using mermaid) are preferred over prose to communicate your message.

It should use the following structure and include a paragraph on each topic.

1. Detail the problem the change is solving. Reference issues, PRs or documents if relevant.
2. Explain the solution and how it solves the problem.
3. Explain how the reader can manually verify the change. e.g. give a code example or a command to run locally.
4. Document the testing strategy when applicable.
5. Document any changes to documentation or READMEs that cover the changes.
6. Document any follow up code changes required.

Any sections that are not relevant should be omitted.

Style guide

It is important to follow these rules when writing a pull request description.

At all times keep the use of language simple. Use plain English

Good: Clear

We've updated the readFile() method to support streaming data so that the caller can read a file without buffering content into memory.

Bad: Verbose and technical jargon