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.

Breaking changes

If the change is breaking, explain in the description:

1. What breaks
2. Why it was necessary
3. 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:

Before Submitting

1. Run ./mvnw process-sources on changed modules to fix formatting
2. Run tests in Java mode (./mvnw verify -f extensions/<name>/)
3. For non-trivial changes, test in native mode (-Dnative)
4. If adding a new integration test module, register it in .github/native-tests.json
5. 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