Quarkus feature builder

What it does

Share your Quarkus code and feature brief. Check versions, make a scoped change and run tests when the tools are available.

What goes in and out

You give it

• An existing Quarkus project and the feature’s required behavior and constraints.

You get

• Scoped application changes with configuration, relevant tests and an honest verification report.

How the task works

• Inspect versions and extensions. Read the build files and preserve the project’s platform, Java target and existing conventions.
• Implement the feature. Select documented REST, configuration, persistence or integration patterns and keep secrets outside source.
• Verify behavior. Run the applicable project checks when available and report missing infrastructure or unexecuted checks.

Full instructions

• Open your AI tool in a way that lets it read your Quarkus project files. It also needs to run commands for the test step.
• Add the skill, or paste its instructions into the chat.
• Describe the feature: what it should do and any limits. Example: add a POST endpoint that checks its input and saves a record.
• Say yes or no when your AI asks about new extensions. It must ask before adding Kafka, OIDC or Keycloak.
• Read the changed files and the verification report. Check which tests ran and which did not.
• Run ./mvnw verify yourself if the report says a check was skipped.

Full instruction file

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).

Before you start

Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.

What you need (use your own material or the linked skill):

• A codebase (yours): a project's code, in a folder or repo the AI can open.
• Your question (yours): the decision or problem, and what a good outcome looks like.

How to start:

1. Look first. Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
2. Check what's missing. Look for a codebase, your question. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
3. Do the job. Follow the skill below with the facts and tools you have. Mark each gap with MISSING: where it belongs and never invent a fact to fill it.

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

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.

After this

When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:

• The Pull request writer. It takes the test report and code change.
• The Slack agent message router builder. It takes the code change.
• The API spec writer. It takes the test report.
• The Code change test coverage reviewer. It takes the test report and code change.
• The Bug root cause finder. It takes the test report and code change. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.