Skip to content

PR Checklist

Use this checklist before requesting a review. It saves time for everyone.

PR description template

Use this structure for the PR description:

### What's changed?
- ...

### Why?
- ...

### How was it tested?
- ...

Before opening the PR

Author checklist

Code

  • The code solves exactly what it should — nothing more
  • No dead code, var_dump, dd(), or debug output
  • No hardcoded values that should be config/env
  • declare(strict_types=1) in all new PHP files

Tests

  • All existing tests pass locally
  • New functionality is covered by tests
  • Edge cases are tested (null, empty array, negative numbers, etc.)

Static analysis

  • vendor/bin/phpstan analyse src --level=8 is clean
  • vendor/bin/php-cs-fixer fix src/ --dry-run is clean

Documentation

  • CHANGELOG.md is updated (for breaking changes or new features)
  • Inline PHPDoc is updated if the public API has changed
  • README/handbook docs are updated for breaking changes

PR description

  • Title follows Conventional Commits: feat: ..., fix: ..., etc.
  • Description explains why, not just what
  • Breaking changes are clearly marked
  • Linked to issue/ticket if relevant

Reviewer guide

As a reviewer: don't approve a PR you don't understand. Ask questions — it's not your fault if the code is hard to read.

Focus on:

  • Correctness and edge cases
  • Side effects and backward compatibility
  • Test coverage of critical logic
  • Naming and readability

Let tooling (CS-Fixer, PHPStan, CI) handle formatting and type errors — don't comment on whitespace.

Merge rules

  • Minimum 1 approving review from another team member
  • Do not merge your own PR without review — exceptions only for trivial chores agreed on by the team
  • All CI checks must be green
  • All automated code review comments must be addressed — either fix the code or leave a comment explaining why the suggestion is discarded
  • Squash-merge to main (standard)
  • Branch is automatically deleted after merge