robsonkades/agent-skills/spring-boot

Spring Boot

Responsibility and activation

Own the composition, runtime configuration and integration of Spring Boot 4.x applications. Use when creating a service, adding an application capability, diagnosing a missing/duplicate bean, tracing an unexpected property value, testing conditional configuration, or changing startup, shutdown or operational wiring. Expert developers should obtain a working implementation, a justified design, or an evidence-backed diagnosis according to the request. Review-only work ends with findings; a sound configuration can be retained.

Detailed business architecture, HTTP contracts and ORM queries belong to their specialists; for a whole service, this skill owns their integration and the delivery criteria. An isolated Java class or Boot 3 migration is outside scope. An exception mentioning Spring is not enough to attribute its cause to Boot. Identify the failing component and use the handoffs below when it owns the decision.

Distinguish a service from a local change

Treat a request to create a service or business API as a professional implementation of the requested use cases. A local bean repair remains a local task. A prototype, tutorial or intentionally ephemeral implementation requires that scope to be explicit; an empty repository, short request or missing database runtime is not permission to deliver an in-memory substitute and call the service complete.

Before choosing storage or exposing routes, establish the use cases, domain invariants, data lifetime and access boundary from the request and repository. Ask focused questions for consequential gaps; continue independent work while they are unresolved. Do not invent business rules or silently make the API public. Complete means the requested behavior works across its real boundaries, not that every possible CRUD operation, architecture layer, identity provider or deployment platform has been added.

For service creation or a review of service completeness, read service delivery. Keep its acceptance criteria through the specialist handoffs; narrowing a check must not narrow the promised service.

Establish the application contract

1. Inspect the relevant build files, wrapper/toolchain, compiler release, runtime image,

resolved dependency graph and tests. Confirm the exact Boot 4 patch and managed Framework/library versions. Use Java 25 as the baseline for this skill, its new examples and guidance. If an existing project targets another Java version, report the compatibility difference before recommending version-sensitive changes; do not silently retarget it. Preserve its build tool. Selecting this skill does not authorize an upgrade, preview feature or new dependency. The worked guidance uses Boot 4.1.1 and Java 25. Code fragments explain individual changes to an existing project; they are not a standalone application or a compatibility guarantee for every 4.x patch. Ground Boot decisions in the official Spring Boot documentation, selecting the release that matches the resolved project. A rolling documentation link is an entry point, not permission to assume its current defaults apply.

1. Locate bootstrap/package scanning, explicit imports, configuration classes, similar

components, deployment configuration and applicable ADRs/runbooks. Identify the consumers of the changed bean or setting, including deployment/operations owners when behavior changes at startup or rollout. Separate explicit requirements, documented standards, consistent conventions, isolated examples and hypotheses. Preserve adequate conventions without imposing a layer layout or moving unrelated classes.

1. Collect evidence that could change this decision: condition report, bean candidates,

winning property origin, active profiles, exception cause chain, or lifecycle trace. Sanitize values; do not dump secrets through logs, command arguments or Actuator.

1. Ask only for consequential information unavailable in the repository. For example:

"The remote catalog is unavailable at startup, but these routes do not use it. May those routes serve traffic while recovery is bounded? I recommend serving that subset only if it meets the caller's contract." Use observed dependencies to support the recommendation; do not invent permission to serve stale data. Keep established decisions, reversible assumptions and unresolved policy distinct. Group the few decisive questions and continue work independent of their answers.

For missing beans, conflicting properties, bootstrap changes or new starters, read composition and configuration.

Choose and execute the intervention

For a material concern, decide its disposition from the contract and current ownership: apply a missing binding constraint or lifecycle boundary needed for correctness; reuse a suitable Boot customizer, platform policy or project component; clarify an unknown default, access or degraded-service policy that changes behavior; defer a relevant change outside the task with its reason and trigger for reconsideration; do not apply a starter, cache or native build with no demonstrated consumer need. Record only consequential decisions, including the plausible alternative rejected and the constraint that would change the choice. Assessment is not a request to implement every capability mentioned in discovery.

Implement in the order the changed contract requires: establish expected behavior and version support; change the owning registration/binding/lifecycle boundary; integrate its actual consumers; exercise failure and replacement paths; update configuration and usage/operation instructions. For extensive work, keep progress and material decisions in the project's existing issue/plan format; use an ADR for a durable architectural choice, not each property or factory. A focused repair needs only the affected change, its evidence and any material unresolved decision.

Core decisions