Skip to main content
Thanks for your interest in contributing! This page covers everything you need: getting set up, how we structure commits, and how to submit a Pull Request.
Read the Getting Started guide first — it covers installation and how to run the project locally. Come back here once you can build and run it.

Making changes

1

Fork and branch

Fork the repository and create a branch off main:
2

Make your changes

Follow the existing code style. Add or update tests where relevant.
3

Verify locally

Make sure the project builds and all checks pass before opening a PR.

Commit messages

We use Conventional Commits. A commit-msg git hook validates this automatically for every commit — see Git hook below for how to enable it. Format:
  • type — required, one of the types below.
  • scope — optional, lowercase noun in parentheses naming the affected area (e.g. auth, parser, ci).
  • ! — optional, right before the colon, flags a breaking change.
  • description — imperative mood (“add”, not “added”/“adds”), no trailing period, ideally ≤ 72 characters.
  • body — optional, explains what and why, not how.
  • footer — optional, e.g. BREAKING CHANGE: ..., Closes #123.
Avoid vague messages like fix bug or update stuff — they’re rejected by the hook and make the changelog useless.
A ready-to-use commit template is available at .gitmessage in the repo root. Enable it once per clone with:

Using an AI assistant to write commits

If you use an AI assistant (Claude, Copilot, etc.) to help draft commits, the rules above are also mirrored in llms/AGENTS.md, which most coding assistants pick up automatically — so AI-drafted commits already match this format.

Git hook

A commit-msg hook in .githooks/commit-msg checks every commit message against the format above and rejects it with an explanation if it doesn’t match. Enable it once per clone:
CI enforces the same convention independently, so a bypassed local hook (git commit --no-verify) won’t let a bad message slip into main.

Opening a Pull Request

1

Push your branch

Push your branch and open a PR against main.
2

Fill in the PR description

GitHub pre-fills the PR body from .github/PULL_REQUEST_TEMPLATE.md. Fill in:
  • Summary — what the PR does and why
  • Related issues — e.g. Closes #123
  • Changes — key bullet points
  • How was this tested?
3

Pass checks

Make sure CI passes and the commit-msg hook doesn’t flag anything.
4

Address feedback

Be ready to respond to review comments.
Keep PRs focused and reasonably small — large, mixed-purpose PRs take much longer to review and merge.

Code review

  • Keep PRs focused on a single change.
  • Respond to comments; prefer follow-up commits over force-pushing during review, unless a reviewer asks for a squash/rebase.
  • A maintainer will merge once the PR is approved and checks are green.
Thanks again for contributing! 🎉
Last modified on August 22, 2026