component-and-release-boundarieslisted

Deciding what becomes an independently releasable component — a Maven module, a JPMS module, a published library — and what that costs: the tension between reusing code and being able to release it, why a shared jar couples every service depending on it, breaking cycles between components, and judging whether a component is stable enough to depend on. Use when a `common` or `shared` module is proposed or has grown, when extracting code into a library so two services can reuse it, when a dependency cycle appears between Maven modules, when upgrading one library forces a coordinated release of several services, or when services are independently deployable in theory but always ship together. Does not cover cohesion and coupling at class and package level (java-cohesion-coupling), whether a component should become a separate process (distribution-boundaries), the API compatibility of a published type (java-api-design), or wire contract versioning (rpc-and-api-contracts).
robsonkades/agent-skills · ★ 2 · Web & Frontend · score 68

Install: claude install-skill robsonkades/agent-skills

# Component and Release Boundaries ## Purpose This skill uses **release component** for a unit published or deployed on its own schedule and consumed through a versioned contract. Internal Maven or JPMS modules can still be meaningful encapsulation/build components; they simply do not acquire the same external compatibility and release obligations. State which meaning applies before using component metrics. Prevent shared-library changes from unnecessarily forcing fleet-wide upgrades, and avoid publication boundaries whose compatibility and release costs exceed their value. A shared jar or shared version number alone does not establish either failure. Inspect the project's JDK/compiler release, Maven/Gradle configuration, resolved dependency graph, module path versus classpath, publication policy and deployed consumer versions. This skill does not mandate a Java baseline: JPMS requires Java 9+, records Java 16+ and sealed types Java 17+ without preview. Examples are partial illustrations; do not upgrade the project or add modules/dependencies just to reproduce their syntax. ## Workflow Start from the outcome at risk: consumer upgrade burden, delivery delay, compatibility or ownership. Reuse supplied release histories, consumer inventories and accepted decisions. Distinguish binding release/approval policy and its owner from habitual batching; technical compatibility does not authorize bypassing that policy. Ask only for missing constraints that could change the recommen