PR Description

Overview

Write PR descriptions that are short, verifiable, and reviewer-friendly. Always include the required sections in the exact order.

Required Structure

Use this structure in every PR description, in this exact order:

1. Description of what was done
2. What was changed
3. How to test
4. Breaking changes

Never omit sections. Do not add sections before these four. If optional content is not applicable, write N/A.

Output Contract (Strict)

• Use the exact section titles shown above.
• Keep the section order unchanged.
• Do not use nested bullets.
• Do not include generic placeholders like "general adjustments".

Writing Rules

• Prefer objective language and concrete behavior changes.
• Describe user and reviewer impact, not only implementation details.
• Keep bullets flat and scannable.
• Avoid vague statements without specifics.
• In How to test, include reproducible steps and expected results.
• Use simple language focused on clarity.
• Avoid unnecessary jargon, internal slang, or tool noise.
• Prioritize "what changed for users/reviewers" over implementation trivia.

Section Guidance

Description of what was done

Summarize intent and outcome in 2-4 lines. State what problem was solved and what behavior now exists. Invalid examples: "General refactor", "Various tweaks".

What was changed

List the main changes grouped by behavior or subsystem. Focus on relevant decisions and visible effects. Use 3-7 bullets. Each bullet should map to a concrete change.

How to test

Use mandatory format:

• Prerequisites
• Steps
• Expected result

Include manual and automated validation when applicable. Use numbered steps in execution order. Each expected result must be observable.

Breaking changes

Explicitly state compatibility impact:

• None
• or precise migration/action required by consumers

Use this matrix:

• If none: write None.
• If present, include:
• Impact
• Who needs to act
• Required migration
• Timing/recommendation

PR Type Variants

If PR is mostly frontend, include:

• affected navigation/routes
• UI states (loading/error/success)
• responsive and visual regression checks

If PR is mostly backend, include:

• changed endpoints/contracts
• changed business rules
• compatibility impact on consumers

If PR is mostly infrastructure, include:

• changed environment/configuration
• deploy/rollback impact
• operational risk and expected monitoring

Good vs Bad Examples

Description of what was done

Good: "Implements login with redirect to the requested route and clear temporary outage messaging." Bad: "Auth updates."

What was changed

Good: "- Extracted HTTP client into a shared layer with centralized error mapping." Bad: "- General improvements."

How to test

Good: "Numbered steps plus observable expected result for each step." Bad: "Test login and verify."

Breaking changes

Good: "None." Bad: "Might have impact."

Output Template

## Description of what was done
-

## What was changed
-

## How to test
### Prerequisites
- 

### Steps
1. 
2. 
3. 

### Expected result
- 

## Breaking changes
-

Review Checklist

Before finalizing, verify:

• All required sections exist.
• Section titles are exact and ordered.
• How to test is executable by another engineer.
• Breaking changes is explicit (never implicit).
• Language is clear, objective, and low-jargon.