mcpField
Q
quarkus

quarkus

github.com/b6k-devDevelopment1489 installsUpdated 33w ago
Repository

About quarkus

An entrypoint skill for agents working on Quarkus projects. Its decision tree directs tasks to domain-specific references, alongside general guidance on extensions, build-time integration, and testing.

Key features

  1. 01Route tasks to domain references
  2. 02Provide entry points for dependency injection and configuration
  3. 03Align extension versions with the Quarkus platform BOM
  4. 04Favor minimal extensions and integration tests

Use cases

  1. 01Start a task in a Quarkus project
  2. 02Find references for REST or configuration work
  3. 03Plan Quarkus extension dependencies
  4. 04Write high-level integration tests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/b6k-dev/quarkus-skill --skill quarkus

After installing, type/quarkusin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/cdi-events/
api.md
configuration.md
gotchas.md
patterns.md
README.md
references/configuration/
api.md
configuration.md
gotchas.md
patterns.md
README.md
references/data-migrations/
api.md
configuration.md
gotchas.md
patterns.md
README.md
references/data-orm-advanced/
api.md
configuration.md
gotchas.md
patterns.md
README.md
references/data-orm/
api.md
configuration.md
gotchas.md
patterns.md
README.md
references/data-panache/
api.md
configuration.md
gotchas.md
patterns.md
README.md

Details

From the project README

Quarkus

Use this as the entrypoint skill for Quarkus work in any kind of project. Use decision tree below to find the right domain, then load detailed references.

Decision Tree

What do you need?
├─ Dependency injection (CDI / ArC)
│  └─ dependency-injection
├─ Application configuration (.properties, profiles, config mapping)
│  └─ configuration
├─ REST and HTTP APIs
│  └─ web-rest
├─ Templates and server-side rendering (Qute)
│  └─ templates
├─ OpenAPI and API contract documentation
│  └─ openapi
├─ Databases, ORM, migrations, data access
│  ├─ Standard JPA / Hibernate ORM usage
│  │  └─ data-orm
│  ├─ Panache entities and repositories for simpler CRUD/data access
│  │  └─ data-panache
│  ├─ Schema migrations and database evolution with Flyway
│  │  └─ data-migrations
│  └─ Advanced Hibernate ORM features: multiple persistence units, multitenancy, caching, extension points
│     └─ data-orm-advanced
├─ Event streaming and asynchronous messaging channels
│  ├─ Is the event crossing a service/process boundary?
│  │  └─ YES -> messaging
│  └─ NO (in-process only)
│     ├─ Need clustering or non-blocking event loop behavior
│     │  └─ YES -> vertx-event-bus
│     └─ Want portability and type safety
│        └─ YES -> cdi-events
├─ Communicating with external APIs, communication between services
│  ├─ Need asynchronous delivery, replay, or broker-managed fan-out
│  │  └─ messaging
│  ├─ Need synchronous request/response calls
│  │  └─ service-communication
│  │     ├─ Shared protobuf contract and HTTP/2 streaming fit well
│  │     │  └─ service-communication-grpc
│  │     └─ Standard HTTP/JSON or simpler interoperability matters more
│  │        └─ service-communication-rest
├─ Authentication, authorization, identity providers
│  ├─ Need core Quarkus security concepts, RBAC, built-in auth mechanisms, or custom policies
│  │  └─ security-core
│  ├─ Protect endpoints with OpenID Connect
│  │  ├─ Inbound bearer tokens, browser login redirects, or hybrid OIDC apps
│  │  │  └─ security-oidc
│  │  └─ Outbound token acquisition, refresh, exchange, or propagation to downstream services
│  │     └─ security-oidc-client
│  ├─ Need JWT verification or token building without full OIDC integration
│  │  └─ security-jwt
│  ├─ Need username/password identity stores backed by JPA, JDBC, or LDAP
│  │  └─ security-identity-providers
│  ├─ Need passkeys or WebAuthn flows
│  │  └─ security-webauthn
│  └─ Need to test secured applications
│     └─ security-testing
├─ Logging, health, metrics, traces
│  ├─ Need help choosing signals, management exposure, or local observability stack
│  │  └─ observability
│  ├─ Logging configuration, JSON logs, MDC, and log shipping
│  │  └─ observability-logging
│  ├─ Liveness/readiness/startup probes and Health UI
│  │  └─ observability-health
│  ├─ Metrics, Micrometer registries, and Prometheus/OTLP export
│  │  └─ observability-metrics
│  └─ Distributed tracing, propagation, and OpenTelemetry
│     └─ observability-tracing
├─ Native image, jars, and container packaging
│  └─ native-and-packaging
│     ├─ Need a native build, closed-world metadata, native SSL, or native-only runtime behavior
│     │  └─ native-image
│     ├─ Need JVM artifact shape decisions: `fast-jar`, `uber-jar`, `mutable-jar`, layout, or re-augmentation
│     │  └─ packaging-jars
│     └─ Need container image packaging: Jib, Docker, Podman, OpenShift, Buildpacks, tags, push, or base images
│        └─ packaging-containers
├─ Testing 
│  └─ Start with the feature module you are testing (for example `security-testing` or `native-image`)
└─ Dev mode, CLI, build plugins
   └─ tooling

General guidelines

  • Quarkus resolves much of its framework wiring at build time, so expect many integration mistakes to fail during build or startup rather than deep at runtime.
  • Align all extension versions through the Quarkus platform BOM.
  • Start with the smallest extension set, then add only what the feature needs.
  • Never skip writing high-level integration tests and prefer them opposed to unit testing individual components. Only write unit tests when they are actually beneficial, e.g. implementing methods with complex logic

Comments

Markdown supported