Skip to main content
rule official · GitHub

quarkus — GitHub Copilot rule: what it does, how to install

Sets coding conventions for Quarkus applications in GitHub Copilot. Guides dependency injection, REST stack selection, and database testing.

Install into GitHub Copilot · Manually: put the files in place All methods and platforms ↓
.github/instructions/quarkus.instructions.md
Open on GitHub

What quarkus does

The rule triggers on Java files, build descriptors, and application properties whenever io.quarkus dependencies are detected. It instructs the assistant to use constructor injection and @ApplicationScoped beans. Code generation relies strictly on jakarta.* packages and Java records for DTO structures.

REST handling strictly separates Quarkus REST from RESTEasy Classic. Mixing both extensions breaks the build immediately, so the rule prevents accidental crossover in legacy projects. Persistence focuses on Hibernate ORM with Panache, database migrations using Flyway or Liquibase, and zero-config Dev Services instead of hardcoded hostnames.

Testing standards mandate @QuarkusTest paired with RestAssured, as well as mock replacement via @InjectMock. Integration test suites require running ./mvnw verify -DskipITs=false. For native compilation targets, reflection-heavy libraries must be registered explicitly using @RegisterForReflection.

What it helps with

  • enforce constructor injection and jakarta packages in Quarkus CDI
  • stop build failures caused by mixing Quarkus REST and RESTEasy Classic
  • configure Panache repositories and Dev Services for local development
  • run integration tests using RestAssured and proper Maven verify flags

Example prompts for the agent

  • Create a Panache repository with paginated queries for active users
  • Add an authenticated REST endpoint validated with Hibernate Validator
  • Write a Quarkus integration test using RestAssured and @InjectMock

How to install quarkus

Manually: put the files in place

.github/instructions/quarkus.instructions.md

The applyTo field sets which files it applies to

Step by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use

Questions about quarkus

How to install quarkus in GitHub Copilot?

Save the instruction file to .github/instructions/quarkus.instructions.md in the repository root. GitHub Copilot loads these guidelines automatically when editing matching Java and build files.

What does the quarkus rule do?

It guides the AI to use current Quarkus idioms, including typed configuration with @ConfigMapping, non-blocking event loops, and Panache persistence patterns.

Why does the rule restrict REST extensions?

Quarkus REST and RESTEasy Classic cannot coexist within the same application build. The rule instructs the assistant to detect the active stack and prevent incompatible extension pairs.

Source text

quarkus.instructions.md · MIT
---
applyTo: '**/*.java, **/application*.properties, **/application*.yml, **/application*.yaml, **/pom.xml, **/build.gradle, **/build.gradle.kts'
description: 'Quarkus development standards and instructions'
---

- Apply these instructions only when the project uses Quarkus (`io.quarkus` dependencies or the Quarkus Maven/Gradle plugin).
- Check the project's existing Quarkus and Java versions (pom.xml, build.gradle, `quarkus.platform.version`) before suggesting changes; keep them unless asked to upgrade. For new projects target the recommended stream from https://code.quarkus.io/api/streams (3.40 at the time of testing; 4.0 is still beta) and Java 21+ (Java 17 minimum). Never hard-code a patch version in advice; use the Quarkus BOM.

## Dependencies and build

- Add features through Quarkus extensions (`./mvnw quarkus:add-extension -Dextensions=...` or `quarkus extension add`), versions managed by the platform BOM.
- Use Quarkus REST (`quarkus-rest`, `quarkus-rest-jackson`) for new projects and explicit migrations. In an existing RESTEasy Classic (`quarkus-resteasy*`) project keep that stack: the two are incompatible and mixing them fails the build.
- Use `./mvnw quarkus:dev` (or `./gradlew quarkusDev`) for development; keep the Maven/Gradle wrapper.

## CDI and code

- Use constructor injection; `@Inject` is optional on a single constructor. Avoid field injection in production code.
- Prefer `@ApplicationScoped` beans; use `jakarta.*` imports only.
- Use records for DTOs. Keep REST resources thin and delegate to services.
- Use `@ConfigMapping` interfaces for grouped, typed configuration; `@ConfigProperty` for single values. Never hard-code secrets; use env vars or a secret store, and profiles (`%dev`, `%test`, `%prod`).
- Use `quarkus.log.*` and JBoss Logging (or SLF4J) for logging.

## REST and validation

- Return explicit status codes and map errors centrally rather than try/catch in each resource. In Quarkus REST projects use `RestResponse`/`Response`, `@ResponseStatus` and `@ServerExceptionMapper`; in RESTEasy Classic projects these are unavailable, so use Jakarta REST `Response` and an `ExceptionMapper` annotated `@Provider`.
- Validate input with Hibernate Validator (`quarkus-hibernate-validator`, `@Valid`).
- Add `quarkus-smallrye-health` and metrics (`quarkus-micrometer-registry-prometheus`, or another Micrometer registry extension; `quarkus-micrometer` alone exports nothing) for production services; expose them only to trusted networks.

## Data

- Use Hibernate ORM with Panache (`quarkus-hibernate-orm-panache`); prefer the repository pattern (`PanacheRepository<T>`) for non-trivial domains, active record for simple ones.
- Put `@Transactional` on service or resource methods that modify data; paginate list queries.
- Manage schema with Flyway or Liquibase in production, not `drop-and-create`.
- Rely on Dev Services for databases and brokers in dev/test; do not configure URLs for them in `%dev`/`%test`.

## Security

- Use `quarkus-oidc` (or `quarkus-smallrye-jwt`) for authentication, and `@RolesAllowed`/`quarkus.http.auth.permission.*` for authorization. Secure endpoints by default.

## Testing

- Use `@QuarkusTest` with RestAssured for application tests, `@QuarkusIntegrationTest` for packaged jar/native/container tests, and `@InjectMock` for CDI mocks.
- Use Dev Services and `QuarkusTestResourceLifecycleManager` for external dependencies; use continuous testing in dev mode.
- Run `*IT` tests with `./mvnw verify -DskipITs=false` (Failsafe; the generated pom sets `skipITs=true`), not `test`. Test artifacts are `quarkus-junit` (3.31+) or `quarkus-junit5` (older); keep what the project uses.

## Avoid

- Reflection-heavy libraries without `@RegisterForReflection` when targeting native.
- Blocking calls on the event loop (use `@Blocking` or virtual threads with `@RunOnVirtualThread`).
- Swallowing exceptions or hard-coding configuration values.

Upgrading Quarkus: run `quarkus update` (<https://quarkus.io/guides/update-quarkus>) and read the version's migration guide at <https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.20> (change the version) before editing.

© github · MIT · github/awesome-copilot

Similar IDE rules

All IDE rules for Backend and APIs →

From the same set928

The whole set →
rust-mcp-server A Copilot rule that guides the agent when you build MCP servers in Rust with the official rmcp SDK. Useful when the project is Rust and you need a custom MCP server. ★ 40,418repo stars ruby-on-rails Sets Rails architecture guidelines for GitHub Copilot across all Ruby files. It enforces thin controllers, service objects, and safe query patterns. ★ 40,418repo stars ruby-mcp-server This rule sets patterns for Ruby MCP servers built with the official mcp gem. Use it when adding tools, resources, prompts, or transports. ★ 40,418repo stars r Tells Copilot how to write R: follow the file's style, avoid unsafe calls, keep paths project-relative. Useful when a repo has .R, .Rmd or .qmd files. ★ 40,418repo stars quarkus-mcp-server-sse This rule guides development of Quarkus MCP servers, from tool methods to project structure. Use it in Java projects with a Quarkus MCP Server extension. ★ 40,418repo stars qa-engineering-best-practices A GitHub Copilot instruction file covering test strategy, the test pyramid, naming, assertions and bug reports. Useful when Copilot writes or reviews tests in your repo. ★ 40,418repo stars python-mcp-server Instructions for GitHub Copilot to build Model Context Protocol servers using Python SDK v2. Keeps generation aligned with the 2026-07-28 protocol spec. ★ 40,418repo stars powershell A GitHub Copilot rule that pushes it toward idiomatic PowerShell scripts following Microsoft's cmdlet guidelines. Useful when your repo has .ps1 and .psm1 files. ★ 40,418repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor