Claude-skill-registry cui-java-cdi

CDI and Quarkus development standards for CUI projects, including CDI aspects, container configuration, testing, and native optimization

install

source · Clone the upstream repo

git clone https://github.com/majiayu000/claude-skill-registry

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/cui-java-cdi" ~/.claude/skills/majiayu000-claude-skill-registry-cui-java-cdi && rm -rf "$T"

manifest: skills/data/cui-java-cdi/SKILL.md

CUI Java CDI Skill

Standards and patterns for CDI and Quarkus development in CUI projects. This skill provides comprehensive guidance on CDI dependency injection, Quarkus container configuration, testing practices, and native image optimization.

Workflow

Step 1: Load Foundational Java Patterns

CRITICAL: Load foundational Java development patterns first.

Skill: cui-java-core

The cui-java-core skill provides essential foundational patterns that CDI builds upon, including constructor injection, dependency management, null safety, immutability, exception handling, and modern Java features. These core Java patterns are prerequisites for CDI-specific development.

Step 2: Load Applicable CDI Standards

CRITICAL: Load current CDI standards to use as enforcement criteria.

Always load foundational CDI standards:

Read: standards/cdi-aspects.md
Read: standards/cdi-container.md

These provide core CDI patterns and container configuration always needed for development.

Conditional loading based on context:

If writing CDI unit tests:

Read: standards/cdi-testing.md

If writing integration tests or setting up integration test infrastructure:

Read: standards/integration-testing.md

If working with reflection registration patterns and native image requirements:

Read: standards/quarkus-reflection.md

If performing native optimization or systematic reflection optimization:

Read: standards/quarkus-native.md

If implementing security features or security testing:

Read: standards/cdi-security.md

Extract key requirements from all loaded standards
Store in working memory for use during task execution

Step 3: Analyze Existing CDI Code

When to Execute: After loading standards

What to Analyze:

Dependency Injection Patterns:
- Verify constructor injection usage (field injection is prohibited)
- Check for proper
```
@Inject
```
  annotation usage
- Validate CDI bean scopes (
```
@ApplicationScoped
```
  ,
```
@RequestScoped
```
  , etc.)
- Review producer methods and their scope configurations
CDI Component Structure:
- Identify CDI beans and their dependencies
- Check for circular dependencies
- Verify proper use of
```
Instance<T>
```
  for optional dependencies
- Review qualifier usage and ambiguous dependency resolution
Container Configuration (if applicable):
- Review Dockerfile and base image selection
- Verify security hardening (OWASP compliance)
- Check certificate management approach (PEM vs PKCS12)
- Validate health check implementation
Testing Configuration (if testing context):
- Review
```
@QuarkusTest
```
  vs
```
@QuarkusIntegrationTest
```
  usage
- Check JaCoCo coverage configuration
- Verify test profiles and configuration overrides
- Validate test resource configuration
Integration Testing Setup (if integration test context):
- Verify script-based lifecycle management (start/stop scripts)
- Check Maven profile configuration for native builds
- Review Docker Compose configuration
- Validate HTTPS and certificate setup
- Ensure API-only testing (no CDI injection in integration tests)
Native Optimization (if native context):
- Analyze reflection registration patterns
- Review
```
@RegisterForReflection
```
  annotations
- Check deployment processor configurations (ReflectiveClassBuildItem)
- Verify AdditionalBeanBuildItem usage for CDI beans
- Identify optimization opportunities
Security Configuration (if security context):
- Verify secure dependency injection patterns
- Check security configuration validation at startup
- Review secure logging practices (no sensitive data logging)
- Validate security testing coverage
- Ensure runtime security hardening (OWASP compliance)

Step 4: Apply CDI Standards to Development Task

When to Execute: During implementation or code review

What to Apply:

Constructor Injection Standard:
- Convert any field injection to constructor injection
- Make injected fields
```
final
```
- Remove unnecessary
```
@Inject
```
  for single-constructor beans
- Add
```
@Inject
```
  to correct constructor when multiple exist
CDI Scope Selection:
- Apply
```
@ApplicationScoped
```
  for stateless services
- Use
```
@RequestScoped
```
  for request-specific data
- Avoid
```
@Singleton
```
  unless eager initialization required
- Validate scope matches lifecycle requirements
Producer Method Patterns:
- Use
```
@Dependent
```
  scope for producers that may return null
- Ensure normal-scoped producers never return null
- Prefer
```
Instance<T>
```
  over
```
Optional<T>
```
  in producers
- Implement Null Object pattern when appropriate
Container Security (if container context):
- Use distroless base image for production
- Implement internal health checks (no curl/wget)
- Configure OWASP security hardening
- Set up PEM certificates with proper permissions
Testing Practices (if testing context):
- Configure JaCoCo for Quarkus correctly
- Use
```
@QuarkusTest
```
  for CDI injection tests
- Ensure
```
@{argLine}
```
  in Surefire configuration
- Implement test profiles for different scenarios
Integration Testing Setup (if integration test context):
- Configure Maven profile with single execution (avoid duplicate builds)
- Implement script-based lifecycle (start/stop containers)
- Use API-only testing with RestAssured (no
```
@Inject
```
  )
- Configure HTTPS with self-signed certificates
- Set up external port mapping (10443:8443)
- Ensure production-equivalent Docker Compose configuration
Native Optimization (if native context):
- Use
```
@RegisterForReflection
```
  for application-level classes
- Use
```
ReflectiveClassBuildItem
```
  for infrastructure classes
- Use
```
AdditionalBeanBuildItem
```
  for CDI beans (not reflection)
- Minimize reflection scope to actual needs
- Use type-safe class references (not strings)
- Avoid double registration (annotation + build step)
Security Implementation (if security context):
- Implement secure configuration validation at startup
- Use constructor injection for security dependencies
- Implement secure logging (mask sensitive data)
- Add security unit and integration tests
- Validate HTTPS-only enforcement
- Configure runtime security hardening

Step 5: Verify Implementation Quality

When to Execute: After applying standards

Quality Checks:

CDI Pattern Verification:
- All dependencies use constructor injection
- All injected fields are
```
final
```
- Proper CDI scopes applied
- No field or setter injection present
- Producer methods follow scope rules
Testing Verification (if testing context):
- JaCoCo properly configured
- Test coverage collected successfully
- Test profiles configured correctly
- All CDI components tested
Integration Testing Verification (if integration test context):
- Maven profile configured with single execution
- Script-based lifecycle scripts exist and work
- Docker Compose uses production-equivalent configuration
- Tests use API-only approach (no CDI injection)
- HTTPS configured with certificates
- Port mapping correct (external 10443, internal 8443)
Container Verification (if container context):
- Distroless base image used
- Security hardening applied
- Health checks implemented correctly
- Certificates configured with proper permissions
Native Optimization Verification (if native context):
- Reflection registration optimized and selective
- No double registration (annotation + build step)
- CDI beans use AdditionalBeanBuildItem
- Type-safe class references used
- Native compilation succeeds
- Tests pass in native mode
- Performance metrics maintained or improved
Security Verification (if security context):
- Secure configuration validation at startup
- No sensitive data logged
- Security tests implemented with 100% coverage
- HTTPS-only enforcement verified
- Runtime security hardening applied

Compilation and Build:

# Compile the module
Task:
  subagent_type: maven-builder
  description: Compile module
  prompt: |
    Compile module to verify changes.

    Parameters:
    - command: clean compile
    - module: [module-name]

    CRITICAL: Wait for completion. Fix any compilation errors.

# Run tests
Task:
  subagent_type: maven-builder
  description: Run tests
  prompt: |
    Run module tests.

    Parameters:
    - command: clean test
    - module: [module-name]

    CRITICAL: Wait for completion. Fix any test failures.

# Quality verification
Task:
  subagent_type: maven-builder
  description: Quality verification
  prompt: |
    Run pre-commit quality checks.

    Parameters:
    - command: -Ppre-commit clean verify -DskipTests
    - module: [module-name]

    CRITICAL: Wait for completion. Fix all quality issues.

# Final verification
Task:
  subagent_type: maven-builder
  description: Final verification
  prompt: |
    Run final build and install.

    Parameters:
    - command: clean install
    - module: [module-name]

    CRITICAL: Wait for completion. Ensure all tests and quality checks pass.

Native Build (if native context):

# Native compilation
Task:
  subagent_type: maven-builder
  description: Native build
  prompt: |
    Build native executable.

    Parameters:
    - command: clean package -Dnative
    - module: [module-name]

    CRITICAL: Wait for completion (may take several minutes).
    Record build time and executable size.

Step 6: Document Changes and Commit

When to Execute: After verification passes

Documentation Updates:

Update module README if CDI architecture changed
Document any special configuration requirements
Note any deviations from standards with rationale
Include performance metrics if applicable

Commit Standards:

Follow standard commit message format
Reference related issues or tasks
Include "Zero information loss verified" if migrating code
Add co-authored-by line for Claude Code

Common Patterns and Error Prevention

For detailed CDI patterns and troubleshooting, see the loaded standards files:

CDI Patterns: Constructor injection, optional dependencies, producer methods - see
```
standards/cdi-aspects.md
```
CDI Testing: JaCoCo configuration, test profiles, coverage requirements - see
```
standards/cdi-testing.md
```
Integration Testing: API-only testing, script-based lifecycle, Maven profiles - see
```
standards/integration-testing.md
```
Container Configuration: Docker, health checks, certificates, OWASP security - see
```
standards/cdi-container.md
```
Reflection Standards: Registration patterns, AdditionalBeanBuildItem, auto-registration - see
```
standards/quarkus-reflection.md
```
Native Optimization Process: Systematic optimization workflow, phases, verification - see
```
standards/quarkus-native.md
```
Security Patterns: Secure configuration, secure logging, security testing - see
```
standards/cdi-security.md
```

Quality Verification

All changes must pass:

Constructor injection used exclusively
All injected fields are
```
final
```
Proper CDI scopes applied
Producer methods follow scope rules
Tests pass with coverage collected
Integration tests use API-only approach (if applicable)
Reflection registration optimized (if applicable)
Security validation at startup (if applicable)
No sensitive data logged (always)
Quality checks pass (
```
-Ppre-commit
```
)
Native compilation succeeds (if applicable)

References