---
name: pull-requests
description: Use when preparing or updating a pull request: scoping the change, writing the description, adding evidence and responding to review. Makes changes small, explained and easy to verify.
---

# Pull requests

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Make every change easy to review, safe to merge and easy to understand later.

## Before you start

- Confirm the change does one thing. Split refactors from behaviour changes.
- Run the project's own checks and tests locally.

## Process

1. Keep the diff small and focused. Large changes should arrive in a reviewable sequence.
2. Write a title that says what changes, not how it was done.
3. Describe why, what changed, how it was tested and any risks or follow-ups.
4. Add evidence: screenshots or captures for visual changes, profiles for performance, steps to reproduce for fixes.
5. Call out anything the reviewer should look at closely.
6. Respond to every review comment: change the code or explain why not.
7. Keep the branch up to date and green until it merges.

## Quality bar

- A reviewer understands the change from the description alone.
- Checks pass before review is requested.
- Unrelated formatting and generated-file churn are left out.

## Output

A focused pull request with a clear description, evidence and passing checks.

## Avoid

- Mixing unrelated changes.
- "Fixed stuff" descriptions.