What this prompt does
This prompt turns an OpenAPI specification into production-quality client SDKs across several languages at once. It walks the AI through six ordered steps: analyzing the [api_name] spec at [spec_path], designing a consistent architecture, generating the auth layer, building the HTTP layer with retries, producing type-safe request/response models, and wiring up docs and a publishing pipeline. Because everything is driven from the spec, the SDKs stay honest as the API evolves, and the same source of truth feeds every target language.
The variables are what make the output specific instead of generic. [language_count] and [target_languages] decide how many idiomatic SDKs get designed, [spec_version] tells the model which OpenAPI dialect to parse, and [auth_methods] plus [http_client] shape the auth and transport layers per language. [retry_strategy], [max_retries], [connect_timeout], and [read_timeout] pin down resilience behavior, while [package_registries] defines where the finished SDKs publish. Adjusting any one of these reshapes a whole step of the output rather than a single line, which is why filling them thoughtfully pays off.
When to use it
- You maintain an API and want first-class SDKs your integrators actually enjoy using.
- You already have an OpenAPI document and want to avoid hand-writing clients per language.
- You need typed clients that catch enum and nullable mistakes at compile time.
- You want auth, token refresh, and retry logic baked in rather than left to each consumer.
- You want SDK regeneration tied to spec changes through CI instead of manual updates.
- You are standardizing client conventions across
[target_languages]so they feel consistent.
Example output
The response is a multi-part deliverable rather than a single file. Expect a spec analysis with flagged issues (missing descriptions, inconsistent naming), an architecture description covering Client, Resource, model, and Error classes, then per-language code for the auth and HTTP layers, generated request builders and response models, plus a quickstart guide and a CI pipeline definition for [package_registries]. Because it spans [language_count] languages, the output is organized into clearly separated sections so each language's idioms stay intact.
Pro tips
- Fix spec problems first. Set
[spec_path]to a clean[spec_version]document; missing descriptions and vague error schemas produce weak SDKs. - Keep
[language_count]and[target_languages]aligned, and let the model follow each language's idioms rather than forcing one pattern everywhere. - Match
[http_client]to libraries your team already trusts so the generated transport code is maintainable. - Be explicit about
[auth_methods]; OAuth2 refresh and API-key injection differ enough that vague input yields incomplete auth code. - Tune
[retry_strategy],[max_retries], and the timeout values to your API's real rate limits instead of accepting defaults blindly. - Run the SDK generation per language in separate passes if the combined output gets truncated, then assemble them into one repository per registry.
