---
title: "Quarkus feature builder"
type: "skill"
url: "https://useaiblocks.com/skills/build-a-quarkus-application-feature"
updated: "2026-10-28"
first_published: "2026-10-25"
job: "Build and ship software"
tested: true
licence: "MIT"
source: "https://github.com/github/awesome-copilot/tree/613efc8c21d9b3ce642dff361d17006cd9967e28/skills/quarkus-application-development"
instructions: "https://useaiblocks.com/skills/build-a-quarkus-application-feature/SKILL.md"
---

# Quarkus feature builder

> Share a Quarkus project and feature brief. Get scoped code changes and an honest check report.

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

Free skill for the job "Build and ship software" · Level: intermediate · Thinking: medium · Tested · Updated 2026-10-28

## Links

- Page: https://useaiblocks.com/skills/build-a-quarkus-application-feature
- Instructions (SKILL.md): https://useaiblocks.com/skills/build-a-quarkus-application-feature/SKILL.md
- All files (zip): https://useaiblocks.com/skills/build-a-quarkus-application-feature.zip
- JSON version: https://useaiblocks.com/skills/build-a-quarkus-application-feature.json
- In your AI: connect https://useaiblocks.com/mcp and ask "Use AI Blocks to get build-a-quarkus-application-feature"

## 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 you give it

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

## What you get

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

## Example: what goes in and what comes out

### What goes in

- Your existing Quarkus project (its build file and code)
- A short brief of the feature: what it should do and any limits
- Your Quarkus and Java versions (optional, your AI can read them from the build file)

### Before you start

- An AI that can read your project files and run commands such as ./mvnw verify
- Docker running, if the feature uses a database, Kafka or Keycloak in dev and test

### What comes out

- **Code changes**: A small, scoped change to your project: resource, service, config and any new extensions, in the style you already use.
- **Configuration**: New settings added to application.properties, with secrets kept out of source and set by environment variables.
- **Tests**: A @QuarkusTest for the new feature, written to match the behavior in your brief.
- **Verification report**: Each check that ran with pass or fail, then each check not run and why, such as no Docker.

## Use it when

- You want to build a Quarkus application feature.

## Skip it when

- You need a brand new project: use create-quarkus-project, or generate one at code.quarkus.io.
- You want to set up Dev Services or write tests only: use quarkus-dev-services-and-testing.
- You want native builds or container images: use quarkus-native-and-container.

## How to use it

1. 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.
2. Add the skill, or paste its instructions into the chat.
3. Describe the feature: what it should do and any limits. Example: add a POST endpoint that checks its input and saves a record.
4. Say yes or no when your AI asks about new extensions. It must ask before adding Kafka, OIDC or Keycloak.
5. Read the changed files and the verification report. Check which tests ran and which did not.
6. Run ./mvnw verify yourself if the report says a check was skipped.

## What to do next

- [Pull request writer](https://useaiblocks.com/skills/pull-request-writer): Build it
- [Slack agent message router builder](https://useaiblocks.com/skills/how-messages-reach-your-agent-implementation-planner): Build it
- [API spec writer](https://useaiblocks.com/skills/api-spec-writer): Build it
- [Code change test coverage reviewer](https://useaiblocks.com/skills/test-gap-finder): Code change test coverage reviewer
- [Bug root cause finder](https://useaiblocks.com/skills/bug-root-cause-finder): Bug root cause finder

## Sources and credits

- From github: https://github.com/github/awesome-copilot/tree/613efc8c21d9b3ce642dff361d17006cd9967e28/skills/quarkus-application-development, shared under the MIT licence (original name: quarkus-application-development).
- [quarkus-application-development skill](https://github.com/github/awesome-copilot/tree/613efc8c21d9b3ce642dff361d17006cd9967e28/skills/quarkus-application-development), github: Original instructions and supporting files, with attribution and the MIT licence. Display copy describes the task.

## Instructions (SKILL.md)

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

<!-- needs: written by tools/add-needs.mjs for AI Blocks; not part of the original skill. Edit that tool, not this section. -->
### 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.
<!-- /needs -->

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

| Need | Use | Details |
|---|---|---|
| JSON REST API | `quarkus-rest-jackson`, `quarkus-hibernate-validator`, `quarkus-smallrye-openapi` | `references/rest.md` |
| Typed config | `@ConfigMapping`; `@ConfigProperty` for single values | `references/config-cdi.md` |
| Beans | `@ApplicationScoped` (default), `@Singleton` only for plain stateless holders | `references/config-cdi.md` |
| Database | `quarkus-hibernate-orm-panache` + JDBC driver, repository pattern | `references/persistence.md` |
| Async / blocking | Imperative by default; `@RunOnVirtualThread` or `Uni` when needed | `references/reactive-messaging.md` |
| Messaging | `quarkus-messaging-kafka` (SmallRye Reactive Messaging) | `references/reactive-messaging.md` |
| AuthN/AuthZ | `quarkus-oidc`, `@RolesAllowed` | `references/security-oidc.md` |
| Ops | `quarkus-smallrye-health`, `quarkus-micrometer-registry-prometheus`, `quarkus-opentelemetry`, `quarkus-smallrye-fault-tolerance` | `references/observability-resilience.md` |
| Outbound HTTP, scheduling, caching | `quarkus-rest-client-jackson`, `quarkus-scheduler`, `quarkus-cache` | `references/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.

<!-- next: written by tools/add-needs.mjs for AI Blocks; not part of the original skill. Edit that tool, not this section. -->
### 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](https://useaiblocks.com/skills/pull-request-writer). It takes the test report and code change.
- The [Slack agent message router builder](https://useaiblocks.com/skills/how-messages-reach-your-agent-implementation-planner). It takes the code change.
- The [API spec writer](https://useaiblocks.com/skills/api-spec-writer). It takes the test report.
- The [Code change test coverage reviewer](https://useaiblocks.com/skills/test-gap-finder). It takes the test report and code change.
- The [Bug root cause finder](https://useaiblocks.com/skills/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.
<!-- /next -->
