# Pull Requests

> Rules for preparing pull requests and commits in the Quarkus project: title conventions, description format, commit hygiene, labels, and contribution policies.

- Skill: `quarkusio/pull-requests` (Agent Skill)
- Install (CLI): `npx skillmds@latest add quarkusio/pull-requests`
- Raw SKILL.md: https://api.skillmd.com/api/skills/quarkusio/pull-requests/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: quarkusio (https://skillmd.com/u/quarkusio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/quarkusio/pull-requests

---


# 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:
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:

| 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

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