pr

name	pr
description	Guidance for branch naming, commit messages, and PR titles.

Pull Request Conventions

Branch discipline

• Never commit to main directly. Create a branch: <user>/<short-description> (e.g. mmansour/optimize-handler-allocs).
• One logical change per commit. Write imperative messages: "Add …" not "Added …".

PR title format

PR titles must use a Conventional Commits prefix:

Prefix	When to use	Example
feat:	New feature or capability	feat: add HTTP/2 support to hyper example
fix:	Bug fix	fix: render missing signals as empty
perf:	Speed or memory improvement, measured	perf: reduce allocations on hot paths
chore:	Maintenance, refactoring, CI, docs, dependencies	chore: move shared files to examples/app

The prefix is lowercase, followed by a colon and a space, then a short imperative description.

A perf: PR must report before/after numbers in its description - see the perf skill for how to measure.

Linking PRs to issues

When a PR is meant to close a GitHub issue, include the keyword Closes followed by the issue number in the PR description body (not the title):

Closes #42

For multiple issues, use one per line:

Closes #42
Closes #43

Note: Issue-linking keywords only work when the PR targets the repository's default branch. See GitHub docs: linking a pull request to an issue for the full reference.

PR description

Remove the Co-author-by line from the PR description. If you want to credit a co-author, add them as a reviewer instead. And check all the changes from its merge-base to get a detailed summary for the commit.

Framework change PRs

For PRs touching core framework code (handler, parser, protocol, router, CLI runtime, FFI), apply the code-review skill checklist before opening the PR. It covers correctness, concurrency, performance, design, and style checks that complement the automated quality gate.