Pull Request Format
When creating a pull request, use the following format for the PR body:
## What?
Briefly describe the changes introduced by this PR. Highlight the difference between the state before and after the changes. Max 2 sentences.
## Why?
Why are these changes necessary? Is there a specific stakeholder (PM, service, QA, devs, sales) who is driving the motivation for these changes?
## How?
A high level description of the implemented changes. Visual aid is always preferred (diagrams, plots, tables, etc...).
## Testing
<!-- To be filled in manually. -->
Instructions
- Use the complete diff against the base branch as the source of truth.
- Describe the impact of the change, not the implementation history.
- Focus on user-visible, behavioral, or architectural changes. Skip mechanical details unless they matter for review.
- Leave the Testing section empty with the HTML comment. Suggest relevant pre-merge validation (tests, benchmarks, screenshots, videos, manual checks, etc.) that the author can add.
Writing Style
- Be concise and precise: write only what helps the reader understand the change.
- Use simple, plain language. Avoid jargon and unnecessary formality.
- Make PRs easy to scan. Prefer tables, diagrams, and code snippets over long paragraphs when they improve clarity.
Large PRs
If the diff is large (e.g. 500+ lines changed, many unrelated files, or multiple independent features), suggest to the user that the PR should be split into smaller, focused PRs. Explain which changes could be grouped together and propose a split.
1---2name: pull-request3description: SEA.AI pull request template. Enforces a consistent PR format with What/Why/How/Testing sections. Use when creating pull requests.4license: MIT5---67# Pull Request Format89When creating a pull request, use the following format for the PR body:1011```markdown12## What?1314Briefly describe the changes introduced by this PR. Highlight the difference between the state before and after the changes. Max 2 sentences.1516## Why?1718Why are these changes necessary? Is there a specific stakeholder (PM, service, QA, devs, sales) who is driving the motivation for these changes?1920## How?2122A high level description of the implemented changes. Visual aid is always preferred (diagrams, plots, tables, etc...).2324## Testing2526<!-- To be filled in manually. -->27```2829## Instructions3031- Use the **complete diff** against the base branch as the source of truth.32- Describe the **impact of the change**, not the implementation history.33- Focus on user-visible, behavioral, or architectural changes. Skip mechanical details unless they matter for review.34- Leave the **Testing** section empty with the HTML comment. Suggest relevant **pre-merge** validation (tests, benchmarks, screenshots, videos, manual checks, etc.) that the author can add.3536## Writing Style3738- **Be concise and precise**: write only what helps the reader understand the change.39- **Use simple, plain language**. Avoid jargon and unnecessary formality.40- **Make PRs easy to scan**. Prefer tables, diagrams, and code snippets over long paragraphs when they improve clarity.4142## Large PRs4344If the diff is large (e.g. 500+ lines changed, many unrelated files, or multiple independent features), suggest to the user that the PR should be split into smaller, focused PRs. Explain which changes could be grouped together and propose a split.
SEA-AI