.dev/workflow

Code Standards

Pull requests and Code reviews

When working in teams, pull requests and code reviews are essential parts of our workflow. Pull requests give structure to how we merge code, while code reviews ensure quality, consistency, and knowledge sharing. Together, they help us keep projects maintainable and make it easier for everyone to understand and improve the codebase.

Pull requests

All code that is merged into the main branch should go through a pull request and be reviewed by at least one other developer.

Description

A pull request must include a clear description. This saves time for the reviewer and helps keep context. Describe:

  • What has been changed

  • Why it has been changed

  • How to test it

Include screenshots, videos, or staging links when design or UX is affected. A vague description slows everyone down.

Copilot

Always run your pull request through a Copilot code review before assigning it to another developer. Copilot can highlight potential issues, summarize the changes, and generate a first draft of the pull request description.

This helps you catch common mistakes early and saves time for the reviewer. But remember: Copilot is only an assistant. A human review is always required before merging code.

Code reviews

As the author

  • Keep changes small and focused

  • Write a complete PR description (what, why, how to test)

  • Add staging links or testing notes if possible

  • Ensure all automated checks pass before asking for a review

  • Optionally use Copilot to check or summarize changes before review

As the reviewer

  • Check readability: is the code easy to follow?

  • Check functionality: does it do what the PR says?

  • Check consistency: does it follow our naming and coding patterns?

  • Suggest improvements respectfully and constructively

  • Use Copilot to assist, but always rely on your own judgment