Generated banner for Quarkus Application Development
Generated logo for Quarkus Application Development

Quarkus Application Development

GitHubOfficialFirst committed by jduboisDistributed by GitHub

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found

From the author

Write Quarkus application code: REST with Quarkus REST, validation, exception mappers, OpenAPI, configuration, CDI (ArC), Hibernate ORM with Panache, Mutiny and virtual threads, Reactive Messaging with Kafka, OIDC security, health, metrics, OpenTelemetry, fault tolerance, REST Client, scheduler and cache. Use when implementing or changing features in an existing Quarkus project.
— the description by jdubois

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to developing application code within a Quarkus project. It covers the integration of essential extensions such as Hibernate ORM with Panache, REST services, security via OIDC, observability, and messaging with Kafka. The skill emphasizes adherence to Quarkus-specific patterns, such as build-time CDI resolution, proper configuration management, and the use of Dev Services for testing, while ensuring developers avoid common pitfalls like blocking the event loop or hard-coding secrets.

What it does

  • Guides the addition of Quarkus extensions using standard CLI commands.
  • Provides patterns for REST API development, including validation and exception handling.
  • Offers best practices for CDI bean management and configuration using @ConfigMapping.
  • Outlines implementation strategies for observability, resilience, and scheduling.
  • Ensures secure development by advising against hard-coded secrets and promoting OIDC integration.
  • Helps troubleshoot common Quarkus-specific issues like bean removal and event loop blocking.

When to use it

  • When implementing new features or modifying existing logic in a Quarkus application.
  • When integrating new infrastructure dependencies like Kafka or OIDC.
  • When configuring application properties or setting up observability and fault tolerance.
  • When debugging issues related to CDI, bean scopes, or blocking operations.

Advantages

  • Promotes consistent use of Quarkus-idiomatic code and Jakarta EE standards.
  • Reduces development time by providing verified patterns for common integration tasks.
  • Helps maintain application performance by highlighting event loop and blocking constraints.
  • Ensures project stability by leveraging build-time validation and proper configuration management.

Usage examples

“How do I add a REST endpoint that uses Hibernate Panache to fetch data from a database?”
The agent will guide you to add the quarkus-hibernate-orm-panache extension, define a PanacheEntity, and create a REST resource that injects the repository or uses the active record pattern.
“I need to add a scheduled task that runs every hour. How should I implement this?”
The agent will advise using the @Scheduled annotation on a bean method and suggest configuring the interval or cron expression via application properties.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/quarkus-application-development/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip quarkus-application-development.zip -d .agents/skills

Documentation by jdubois

Quarkus Application Development

Scope: application code inside an existing Quarkus project. Project creation is create-quarkus-project; Dev Services and tests are quarkus-dev-services-and-testing; native and container images are quarkus-native-and-container; core JPA mapping and query design can use the optional java-hibernate-jpa skill if installed (otherwise see the Hibernate ORM guide, https://quarkus.io/guides/hibernate-orm, and the Jakarta Persistence docs).

Agent rules

  1. Detect first: read pom.xml/build.gradle for quarkus.platform.version, the Java release, and the extensions already present. Keep the version; use what the project already uses (for example quarkus-resteasy* stays if present).

  2. Add extensions with quarkus extension add <name> or ./mvnw quarkus:add-extension -Dextensions=<name>; never guess artifact ids or versions by hand (the platform BOM manages them). List candidates with quarkus extension list --installable --search=<text>.

  3. Ask the user before adding Kafka, OIDC/Keycloak or any new infrastructure dependency (they start containers in dev/test and change deployment needs).

  4. Never use the Spring compatibility extensions (quarkus-spring-*) unless the project already does.

  5. Verify with dev mode (./mvnw quarkus:dev, then /q/dev-ui) and ./mvnw verify; write a @QuarkusTest per feature. Do not claim something works without running it.

  6. Use jakarta.* imports, records for DTOs, thin resources delegating to services.

  7. Never hard-code secrets or add credentials to application.properties; see references/config-cdi.md.

Quick decisions

NeedUseDetails
JSON REST APIquarkus-rest-jackson, quarkus-hibernate-validator, quarkus-smallrye-openapireferences/rest.md
Typed config@ConfigMapping; @ConfigProperty for single valuesreferences/config-cdi.md
Beans@ApplicationScoped (default), @Singleton only for plain stateless holdersreferences/config-cdi.md
Databasequarkus-hibernate-orm-panache + JDBC driver, repository patternreferences/persistence.md
Async / blockingImperative by default; @RunOnVirtualThread or Uni when neededreferences/reactive-messaging.md
Messagingquarkus-messaging-kafka (SmallRye Reactive Messaging)references/reactive-messaging.md
AuthN/AuthZquarkus-oidc, @RolesAllowedreferences/security-oidc.md
Opsquarkus-smallrye-health, quarkus-micrometer-registry-prometheus, quarkus-opentelemetry, quarkus-smallrye-fault-tolerancereferences/observability-resilience.md
Outbound HTTP, scheduling, cachingquarkus-rest-client-jackson, quarkus-scheduler, quarkus-cachereferences/observability-resilience.md

Pitfalls that cost time

  • Quarkus resolves CDI at build time: an unused bean may be removed. Beans only looked up programmatically need @Unremovable.

  • Do not read or write public fields of a normal-scoped bean (@ApplicationScoped) from another bean or test: you hit the client proxy, not the instance (verified: a counter field read through the proxy returned 0). Use methods.

  • Do not block on the event loop (@NonBlocking methods, Uni/Multi return types running on I/O threads). Remove any existing @NonBlocking from the method (combining it with @Blocking or @RunOnVirtualThread fails the build), then add @Blocking or @RunOnVirtualThread (see references/reactive-messaging.md).

  • Changes to build-time properties need a rebuild; run-time properties can be overridden by env vars (QUARKUS_DATASOURCE_JDBC_URL).

  • Do not configure URLs for databases/brokers/Keycloak in %dev/%test: that disables Dev Services.

  • drop-and-create schema management is for dev/test only; use Flyway or Liquibase for production.

Verified on Quarkus 3.40.1 and 3.27.6 (Java 21 target, Maven) with a scaffolded app and mvn verify (15 tests: REST+validation+mapper, OpenAPI, config mapping, Panache on PostgreSQL Dev Services, Kafka Dev Service round trip, Keycloak Dev Service tokens, health, metrics, fault tolerance, cache, scheduler). Re-check names against the project's version.

Files

references/config-cdi.md

Configuration and CDI (ArC)

Configuration

Sources by precedence (high to low): system properties, environment variables, .env file in the working directory (loaded for packaged apps too, so do not ship it to production; put dev-only values under %dev./%test. keys), config/application.properties next to the app, application.properties in the jar, MicroProfile defaults. Env var mapping: uppercase, non-alphanumerics become _ (greeting.max-length -> GREETING_MAX_LENGTH).

Profiles

%dev., %test., %prod. prefixes; quarkus.profile=staging or custom profiles work too. quarkus:dev is dev, tests are test, packaged apps are prod.

greeting.prefix=Hello
%dev.greeting.prefix=Dev hello
# Required in every profile (including custom ones such as staging): startup fails if API_KEY is missing
app.api-key=${API_KEY}
# Fallback only for dev and test
%dev.app.api-key=${API_KEY:dev-only-key}
%test.app.api-key=${API_KEY:dev-only-key}

Verified: with these settings a @QuarkusTest sees Hello (the %dev value is not applied in test) and dev-only-key.

Secrets

Never commit real secrets. Supply them via env vars, Kubernetes secrets mounted as env/files, or a vault extension (quarkus-vault, quarkus-kubernetes-config with quarkus.kubernetes-config.secrets). Set no default in %prod so a missing secret fails fast. Property expressions that point at other keys are fine; keep credentials out of logs.

@ConfigMapping vs @ConfigProperty
@ConfigMapping(prefix = "greeting")
public interface GreetingConfig {
    String prefix();
    @WithDefault("10") int maxLength();     // greeting.max-length
    Optional<String> suffix();
    List<String> tags();                    // greeting.tags=a,b
}

Verified: injected with @Inject GreetingConfig config, maxLength() returned the value from greeting.max-length, suffix() was empty, tags() was [a, b]. Nested groups are nested interfaces; Map<String,...> is supported. Add @Valid-style constraints with hibernate-validator on mapping methods when present; startup fails on violations.

  • Use @ConfigMapping for any group of related properties (typed, validated at startup, documented in one place).

  • Use @ConfigProperty(name = "app.api-key") String key; for a single value or when you need defaultValue. Also works on constructor params.

  • Unknown properties under a mapped prefix can fail startup; keep that validation enabled to catch typos.

  • Build-time vs run-time: quarkus.* build-time properties (marked in the config reference) are fixed at package time. Check the extension's guide before assuming an env var override works in the container.

CDI with ArC

ArC is a build-time CDI Lite-style implementation, not full CDI: no portable extensions (use build-compatible extensions or Quarkus build steps), no decorators on all paths, and some features are different.

  • Build-time resolution: injection points are validated at build; missing or ambiguous beans fail the build, not runtime.

  • Unused bean removal: beans with no injection point, no observer, no producer use, and not annotated @Unremovable are removed. If you look them up with Arc.container().instance(...) or CDI.current().select(...) by dynamic type, add @io.quarkus.arc.Unremovable. Disable globally with quarkus.arc.remove-unused-beans=none only as a last resort.

  • Scopes: @ApplicationScoped is lazy and proxied (supports interceptors, mocking, circular deps); default choice. @Singleton is not proxied (no client proxy, so no lazy init through the proxy and @InjectMock is not applicable): use it for stateless holders only. @RequestScoped per HTTP request; @Dependent is the default pseudo-scope (new instance per injection point).

  • No private injection: use package-private fields or constructors. Quarkus recommends against private injected fields because they force reflection-based access. Prefer constructor injection (@Inject optional with a single constructor).

  • Proxy pitfalls (verified): @ApplicationScoped beans are called through a subclass proxy; reading a public field of such a bean from outside returns the proxy's own (default) value. Expose state with methods. Avoid final on bean classes and methods and private no-arg constructors on normal-scoped beans.

  • Startup logic: @Startup on a bean, or void onStart(@Observes StartupEvent e). Eager beans must not do slow blocking I/O on the main thread without care.

  • Interceptors: define an @InterceptorBinding annotation and an @Interceptor with @Priority; ArC applies them at build time to bean classes only (not to arbitrary objects). ArC supports intercepted self-invocation, so a bean calling its own intercepted method (@Transactional, @Retry, @CacheResult) still triggers the interceptor.

  • Producers/events: @Produces and @Observes work as usual. @Priority only orders synchronous @Observes methods; it does not make them async. Asynchronous observers use @ObservesAsync and are notified only by Event.fireAsync(...) (which returns a CompletionStage); Event.fire(...) notifies only synchronous observers.

  • Testing: @InjectMock (quarkus-junit-mockito; quarkus-junit5-mockito on old versions) works for normal-scoped beans. See quarkus-dev-services-and-testing.

  • Debugging: the Dev UI (/q/dev-ui) ArC page lists beans, removed beans and observers.

Logging: JBoss Logging (org.jboss.logging.Logger) or @Inject Logger, configured with quarkus.log.*; do not add Logback/Log4j directly.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of jduboisjdubois
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/quarkus-application-development · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
jdubois

AutoGineer is not affiliated with or endorsed by jdubois or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download quarkus-application-development.zip