Pull Requests
PR Title
Write a clear, natural-language sentence that describes the change:
- Start with an uppercase letter
- Do not prefix with
feat:, fix:, chore:, docs:, refactor:, or
any other Conventional Commits type — the Quarkus bot will flag this
- Keep it concise but descriptive
- Do not end with a period
Examples
Add multipart upload support to RESTEasy Reactive
Fix NPE when config property is unset
Update OIDC provider configuration guide
Simplify bean resolution logic in ArC
PR Description
- Explain why the change is needed, not what changed (the diff shows that)
- Keep it concise — a short paragraph is usually enough
- Do not include a "Test plan" or "Summary" section
- Do not include "Generated with Claude Code" or similar footers
- Do not include
Co-Authored-By trailers referencing an AI tool
Noteworthy features
If your PR introduces a noteworthy feature, include a single line at the end of
the description prefixed with Release note: that can be used verbatim in the
release notes. Keep it user-facing — focus on the benefit, not the implementation:
Release note: RESTEasy Reactive now supports multipart file uploads with
progress tracking via the new `@PartProgress` annotation.
Only do this for noteworthy features, not small enhancements or bug fixes
Breaking changes
If the change is breaking, explain in the description:
- What breaks
- Why it was necessary
- How users should migrate
Commits
- Commits must be atomic and semantic — each commit should represent one
logical change
- Properly squash fixup commits before the PR is ready for merge. Fixup
commits are acceptable during review, but must be squashed at the end
- Write commit messages as clear, natural-language sentences starting with an
uppercase letter — same style as the PR title
- Do not add
Co-Authored-By trailers referencing AI tools (e.g.
Co-Authored-By: Claude, Co-Authored-By: Copilot)
Labels
Apply these labels when relevant:
| Label |
When to apply |
release/noteworthy-feature |
The PR introduces a significant user-facing feature that should appear in release notes |
release/breaking-change |
The PR contains a breaking change (API removal, behavior change, config rename) |
Before Submitting
- Run
./mvnw process-sources on changed modules to fix formatting
- Run tests in Java mode (
./mvnw verify -f extensions/<name>/)
- For non-trivial changes, test in native mode (
-Dnative)
- If adding a new integration test module, register it in
.github/native-tests.json
- Update documentation in
docs/src/main/asciidoc/ when the change affects
user-facing behavior, config, or APIs
LLM / Agent Policy
- You are responsible for validating every change you submit — AI-assisted or not
- Do not submit code, tests, or descriptions copied directly from an LLM without
human review
- AI-generated tests must validate actual behavior, not just exercise code paths
- Do not use bots or agents to open PRs without human authorship and responsibility
1---2name: pull-requests3description: Rules for preparing pull requests and commits in the Quarkus project: title conventions, description format, commit hygiene, labels, and contribution policies.4---56# Pull Requests78## PR Title910Write a clear, natural-language sentence that describes the change:1112- **Start with an uppercase letter**13- Do **not** prefix with `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, or14 any other Conventional Commits type — the Quarkus bot will flag this15- Keep it concise but descriptive16- Do not end with a period1718### Examples1920```21Add multipart upload support to RESTEasy Reactive22Fix NPE when config property is unset23Update OIDC provider configuration guide24Simplify bean resolution logic in ArC25```2627## PR Description2829- Explain **why** the change is needed, not what changed (the diff shows that)30- Keep it concise — a short paragraph is usually enough31- Do **not** include a "Test plan" or "Summary" section32- Do **not** include "Generated with Claude Code" or similar footers33- Do **not** include `Co-Authored-By` trailers referencing an AI tool3435### Noteworthy features3637If your PR introduces a noteworthy feature, include a single line at the end of38the description prefixed with `Release note:` that can be used verbatim in the39release notes. Keep it user-facing — focus on the benefit, not the implementation:4041```42Release note: RESTEasy Reactive now supports multipart file uploads with43progress tracking via the new `@PartProgress` annotation.44```4546*Only* do this for noteworthy features, not small enhancements or bug fixes4748### Breaking changes4950If the change is breaking, explain in the description:511. What breaks522. Why it was necessary533. How users should migrate5455## Commits5657- Commits must be **atomic and semantic** — each commit should represent one58 logical change59- Properly **squash** fixup commits before the PR is ready for merge. Fixup60 commits are acceptable during review, but must be squashed at the end61- Write commit messages as clear, natural-language sentences starting with an62 uppercase letter — same style as the PR title63- Do **not** add `Co-Authored-By` trailers referencing AI tools (e.g.64 `Co-Authored-By: Claude`, `Co-Authored-By: Copilot`)6566## Labels6768Apply these labels when relevant:6970| Label | When to apply |71|-------|---------------|72| `release/noteworthy-feature` | The PR introduces a significant user-facing feature that should appear in release notes |73| `release/breaking-change` | The PR contains a breaking change (API removal, behavior change, config rename) |7475## Before Submitting76771. Run `./mvnw process-sources` on changed modules to fix formatting782. Run tests in Java mode (`./mvnw verify -f extensions/<name>/`)793. For non-trivial changes, test in native mode (`-Dnative`)804. If adding a new integration test module, register it in81 `.github/native-tests.json`825. Update documentation in `docs/src/main/asciidoc/` when the change affects83 user-facing behavior, config, or APIs8485## LLM / Agent Policy8687- You are responsible for validating every change you submit — AI-assisted or not88- Do not submit code, tests, or descriptions copied directly from an LLM without89 human review90- AI-generated tests must validate actual behavior, not just exercise code paths91- Do not use bots or agents to open PRs without human authorship and responsibility
quarkusio