sdk-publishing

Extracts internal modules into reusable Spring Boot starter libraries with auto-configuration and semantic versioning.

Updated Jun 25, 2026
One-click install
npx skills add https://github.com/oriddd/ai-toolkit --skill sdk-publishing-oriddd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdk-publishing
Source: https://github.com/oriddd/ai-toolkit/tree/main/copilot/public/skills/sdk-publishing
Command: npx skills add https://github.com/oriddd/ai-toolkit --skill sdk-publishing-oriddd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams duplicating the same code across multiple services face maintenance drift and inconsistent behavior. This Skill guides the extraction of shared code into a versioned Spring Boot library or starter that consumers can depend on without surprises. ## Core Features & Use Cases - Auto-configuration patterns: Build starters where every bean is @ConditionalOnMissingBean and guarded by @ConditionalOnClass, so consumers can override any default. - Minimal public API surface: Enforce interfaces and records in an api/ package with package-private implementations in internal/, optionally sealed via JPMS. - Versioning and deprecation policy: Apply SemVer, a two-minor-release deprecation window, and wire-compatibility rules for DTOs and configuration keys. - Use Case: Three services each contain a near-identical client for an internal Foo API. Use this Skill to extract a foo-spring-boot-starter with auto-configuration, IDE configuration metadata, and ApplicationContextRunner tests proving the lego-brick contract. ## Quick Start Apply the sdk-publishing skill to turn this duplicated module into a Spring Boot starter with auto-configuration and a semantic versioning policy.

Frequently Asked Questions about sdk-publishing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a custom Spring Boot starter?

Create a jar module with an @AutoConfiguration class registered in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. Guard every bean with @ConditionalOnMissingBean and @ConditionalOnClass, and depend only on spring-boot-autoconfigure with provided scope.

When should I extract shared code into a library?

Extract only when the same code appears in at least three services, has a stable contract unchanged across two minor releases, has its own tests, and has an owner team. Extracting earlier creates worse coupling than duplication.

How do I make Spring Boot starter beans overridable by consumers?

Annotate every library bean with @ConditionalOnMissingBean so a consumer's same-type bean takes precedence. Verify the behavior with ApplicationContextRunner tests that assert the library backs off when a custom bean exists.

How do I add IDE autocomplete for custom Spring configuration properties?

Add the spring-boot-configuration-processor as an optional dependency to generate spring-configuration-metadata.json at compile time. Provide descriptions and defaults in a hand-written additional-spring-configuration-metadata.json under META-INF.

What versioning rules apply to an internal Spring library?

Use semantic versioning: major for breaking changes, minor for additive changes, patch for fixes. Keep a two-minor-release deprecation window, never change DTO wire shape in non-major bumps, and never rename configuration keys without a deprecated replacement.

Should a Spring Boot library depend on spring-boot-starter-web?

No. A library must never package any starter as a transitive dependency because the consumer chooses its own web stack. Depend only on spring-boot-autoconfigure with provided scope.