# Pull Requests

Describes how to write pull/merge requests.

- Repository: https://github.com/cloudflare/computer (9770 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-10-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add cloudflare/computer --skill pull-requests -g -a claude-code -y`
Codex: `npx skills add cloudflare/computer --skill pull-requests -g -a codex -y`
Cursor: `npx skills add cloudflare/computer --skill pull-requests -g -a cursor -y`
Gemini CLI: `npx skills add cloudflare/computer --skill pull-requests -g -a gemini-cli -y`

## Description

Describes how to write pull/merge requests. Use when asked to write or edit a pull request or merge request description. This skill is not relevant to commit messages.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/cloudflare/computer/blob/HEAD/.agents/skills/pull-requests/SKILL.md