Microsoft Pull Request Conventions
Branch discipline
- Never commit to
maindirectly. 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.