specgen-sdk-javalisted

Generate a detailed specification document for building a distributable Java SDK library packaged as a Multi-Release fat JAR via Maven. Targets JDK 8 baseline with JDK 11+ overlay classes (Multi-Release JAR) so a single artifact runs on every long-term JDK in production. The SDK is a thin client wrapping a remote REST API (and any additional protocols extracted from the PRD's Architecture Principle section). REST communication is implemented with OkHttp; everything else (JSON parsing, models, builders, retry, logging) is implemented with the JDK and in-house code â€” third-party dependencies are kept to the absolute minimum. Standardized input: application name (mandatory), version (mandatory), module (optional). Use this skill whenever the user asks to create a spec, specification, blueprint, or technical design document for a new Java SDK, Java client library, or REST API client wrapper. Also trigger when the user says things like "spec out a new Java SDK", "design a Java client library for my API", "write
rashidee/co2-skills · ★ 3 · Data & Documents · score 77

Install: claude install-skill rashidee/co2-skills

# Java SDK (Multi-Release Fat JAR) Specification Generator This skill generates a comprehensive specification document (Markdown) that serves as a blueprint for building a distributable Java **SDK library**. The library is published as a **Multi-Release fat JAR** built with Maven, supports JDK 8 as a baseline and uses JDK 11+ overlays where modern APIs are beneficial, and wraps a remote REST API (plus any additional protocols defined in the PRD's Architecture Principle section). The specification does NOT generate code. It produces a detailed, opinionated technical document describing every layer of the library â€” from the `pom.xml` Multi-Release configuration, to the OkHttp transport, to the model classes and high-level service facade â€” so that implementation becomes a mechanical exercise. ## Library-First Mindset This is **NOT** an application. There is no `main()` (only an optional minimal one for diagnostics), no Spring, no application server, no scheduler. The output is a JAR that downstream Java applications add to their classpath and call as a normal API. Every design decision below is biased toward: 1. **Minimum third-party footprint.** Each transitive dependency the SDK pulls in becomes a problem for every downstream consumer. The skill MUST resist adding libraries unless the JDK and OkHttp cannot reasonably cover the use case. 2. **Long-lived JDK compatibility.** Consumers may run JDK 8, 11, 17, or 21. The Multi-Release JAR layout lets the SDK ship