菜单
Always load this skill when working on a Quarkus project, when the quarkus-maven-plugin is present in pom.xml, or when project setup has already chosen Quarkus before the pom.xml exists yet. It provides Quarkus-specific patterns and gotchas that complement the java and maven skills.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | quarkus |
| description | Always load this skill when working on a Quarkus project, when the quarkus-maven-plugin is present in pom.xml, or when project setup has already chosen Quarkus before the pom.xml exists yet. It provides Quarkus-specific patterns and gotchas that complement the java and maven skills. |
| version | 0.1.0 |
Quarkus-specific conventions and patterns.
Language- and build-tool-specific conventions are covered by the java and maven skills.
Quarkus-specific setup is not generic build-file work.
When adding a Quarkus capability, do not start by hand-writing pom.xml or build.gradle changes.
Use this decision ladder:
quarkus CLI next. Before editing build files by hand, check whether the quarkus CLI can create or apply the required setup.If you find yourself adding io.quarkus:* dependencies, BOM entries, or quarkus-maven-plugin configuration by hand, stop and check whether this should be done through Quarkus-aware tooling or the quarkus CLI instead.
Load the referenced file when the situation matches.
| Situation | File |
|---|---|
Adding dev-only code (seeders, fake services, dev helpers): src/dev/java pattern or @IfBuildProfile | dev-mode.md |
Orchestrator role in the Unfolding Specs process. Launches the PO, forwards unsolicited Sensei guidance, handles genuine commissioner issues, and resumes the workflow through the platform-specific live task mechanism.
Always load this skill when a pom.xml file exists in the project, when creating or editing a pom.xml, or when setting up Maven project structure in a new project. It provides Maven-specific conventions for running tests, building, managing dependencies, and project structure.
This skill should be used when starting work on any project that uses tdder. It establishes interaction style, commit conventions, documentation discipline, and skill-trust principles. Invoke automatically alongside other tdder skills.
Always load this skill when writing, modifying, creating, or moving Java or Kotlin source code, or when project setup has already chosen Java/Kotlin as the implementation language.
This skill should be used when the user asks to "add a feature using TDD", "fix a bug with TDD", "do TDD", "red-green-refactor", "write a failing test first", "use test-driven development", "start TDD", "test first approach", "TDD loop", "TDD cycle", or mentions TDD workflow, baby steps, guessing game, or red-green-refactor cycles. Not applicable for pure refactoring without new tests.
Requirements grilling session with a Product Owner (or anyone in that role). Challenges plans against the existing domain model, sharpens terminology, and updates documentation (bounded-context files, Gherkin features, DMDs (Domain Model Decisions)) inline as decisions crystallise. Use when the user wants to discuss and capture requirements, stress-test a plan against the project's language, or refine feature scope.