The goal of this project is to automate and minimize the effort of maintaining high-quality .NET SDKs generated based on OpenAPI and AsyncAPI specifications, mainly to strengthen the AI ecosystem within .NET. The code generated by this library is also actively used in dozens of our various SDKs of varying complexity levels and in the LangChain.NET project, which ensures that it is tested in various scenarios and is ready for them.
Inspired by NSwag ❤️.
- Detects your TargetFramework and generates optimal code for it (including net6.0/net7.0/net8.0 improvements)
- Supports .Net Framework/.Net Standard
- Supports OpenAPI 3.1 specs via compatibility normalization (nullability, examples, const,
unevaluatedProperties, tuple-style arrays, and string content keywords) - Does not contain dependencies for modern versions of dotnet.
- Only System.Text.Json dependency for .Net Framework/.Net Standard
- Any generated methods provide the ability to pass a CancellationToken
- Allows partial generation (models only) or end points filtering
- Available under MIT license for general users and most organizations
- Uses https://github.com/microsoft/OpenAPI.NET for parsing OpenAPI specification
- Supports nullable enable/trimming/native AOT compilation/CLS compliance
- Tested on GitHub 220k lines OpenAPI specification
- Supports OneOf/AnyOf/AllOf/Not schemas
- Supports Enums for System.Text.Json
- Supports AsyncAPI specs for WebSocket client generation (send/receive methods, cross-namespace schema referencing)
- Supports SSE (Server-Sent Events) through the
application/x-ndjsoncontent type - Uses Incremental Source Generators for efficient generation and caching.
- Efficient O(n) implementation, fully suitable for large/super large OpenAPI specifications
- Used in 10+ real SDKs and adapted to solve various problems
You can use the CLI to generate the code.
dotnet tool install --global autosdk.cli --prerelease
rm -rf Generated
autosdk generate openapi.yaml \
--namespace Namespace \
--clientClassName YourApi \
--targetFramework net8.0 \
--output GeneratedIt will generate the code in the "Generated" subdirectory.
It also will include polyfills for .Net Framework/.Net Standard TargetFrameworks.
autosdk http emits executable request files for regular OpenAPI path operations. It also surfaces response links and callbacks as commented documentation blocks next to the owning operation, and writes root-level OpenAPI webhooks to webhooks.http as inbound contract documentation instead of outbound client calls.
AutoSDK normalizes the OpenAPI 3.1 / JSON Schema 2020-12 keywords it can translate cleanly into the current generation pipeline, including unevaluatedProperties, prefixItems, unevaluatedItems, contentEncoding, and contentMediaType.
Keywords that are still not representable in the current .NET model pipeline, such as patternProperties and contains/minContains/maxContains, now fail fast with a targeted error instead of being silently ignored.
Fast-moving APIs can return fields that are not present in the OpenAPI schema yet. Enable --generate-raw-model-data in the CLI, or set <AutoSDK_GenerateRawModelData>true</AutoSDK_GenerateRawModelData> for the source generator, to emit typed raw JSON extension data on generated models.
With System.Text.Json, unknown fields are preserved as JsonElement values in AdditionalProperties, and generated models also expose FromRawUnchecked(...) / ToRawJson(...) helper aliases. This mode is useful for SDK repos where provider docs or live responses move faster than the checked-in spec, while the default lightweight model shape remains unchanged.
OpenAPI does not standardize receiver-side webhook signing metadata, so webhook verification helpers are opt-in. Enable --generate-webhook-verifier in the CLI, or set <AutoSDK_GenerateWebhookVerifier>true</AutoSDK_GenerateWebhookVerifier> for the source generator, to emit a Replicate/Svix-style HMAC SHA-256 verifier.
The generated verifier validates webhook-id, webhook-timestamp, and webhook-signature by default, rejects stale timestamps, supports multiple versioned signatures such as v1,<base64>, decodes Replicate/Svix-style whsec_<base64> secrets, and uses constant-time signature comparison. Header names, verifier class name, signature version, and timestamp tolerance can be configured through the AutoSDK_Webhook* properties or matching CLI flags.
Some ingestion APIs derive multipart part names from trace/run ids and attachment keys instead of fixed OpenAPI schema properties. Enable --generate-dynamic-multipart-helpers in the CLI, or set <AutoSDK_GenerateDynamicMultipartHelpers>true</AutoSDK_GenerateDynamicMultipartHelpers> for the source generator, to emit a DynamicMultipartContentBuilder helper.
The generated builder adds byte, stream, text, and external URL attachments, preserves run id/key relationships, computes part names like run_123.image, carries content type and filename metadata, and returns MultipartFormDataContent for raw generated endpoints. The helper class name can be configured with --dynamic-multipart-helper-class-name or <AutoSDK_DynamicMultipartHelperClassName>.
Prompt/version APIs often need a small manager layer for resolving templates, rendering variables, and caching versions. Enable --generate-prompt-template-helpers in the CLI, or set <AutoSDK_GeneratePromptTemplateHelpers>true</AutoSDK_GeneratePromptTemplateHelpers> for the source generator, to emit a PromptTemplateManager helper.
The generated manager accepts a resolver delegate that can call raw generated prompt endpoints, caches resolved prompt versions with a configurable TTL, renders {{variable}} placeholders for string and chat-message prompts, supports {{>partial}} composition, and reports missing variables with PromptTemplateRenderException. The helper class name can be configured with --prompt-template-helper-class-name or <AutoSDK_PromptTemplateHelperClassName>.
Trace, log, span, score, and feedback ingestion APIs often need lifecycle behavior around raw batch endpoints. Enable --generate-observability-lifecycle-helpers in the CLI, or set <AutoSDK_GenerateObservabilityLifecycleHelpers>true</AutoSDK_GenerateObservabilityLifecycleHelpers> for the source generator, to emit an ObservabilityIngestionLifecycle helper.
The generated lifecycle helper accepts a raw batch-ingest delegate, reads common env-backed options such as API key, endpoint, project, sampling rate, batch size, queue size, and flush interval, then provides bounded enqueueing, drop/error hooks, FlushAsync, ShutdownAsync, and IAsyncDisposable/IDisposable behavior. The helper class name can be configured with --observability-lifecycle-helper-class-name or <AutoSDK_ObservabilityLifecycleHelperClassName>.
Prediction, job, and actor-run APIs often need a provider-style create, wait, poll, cancel, and result-projection layer over raw generated endpoints. Enable --generate-prediction-workflow-helpers in the CLI, or set <AutoSDK_GeneratePredictionWorkflowHelpers>true</AutoSDK_GeneratePredictionWorkflowHelpers> for the source generator, to emit a PredictionWorkflowRunner helper.
The generated runner composes raw create, reload, optional cancel, status selector, and result selector delegates. It supports configurable success/failure/canceled terminal states, timeout and poll interval handling, best-effort cancellation-link invocation when the caller cancels, metadata for Replicate-style Prefer: wait and Apify-style waitForFinish workflows, and result projection such as returning output while preserving the final envelope. The helper class name can be configured with --prediction-workflow-helper-class-name or <AutoSDK_PredictionWorkflowHelperClassName>.
x-speakeasy-polling annotations are not present in most public OpenAPI specs, but the same shape — a GET-by-id endpoint whose response is a oneOf discriminated by status (or a flat object with a status enum) and at least one terminal-success state (succeeded, completed, done, finished) — is common. Enable --auto-detect-status-polling in the CLI, or set <AutoSDK_AutoDetectStatusPolling>true</AutoSDK_AutoDetectStatusPolling> for the source generator, to synthesize a <Method>WaitAsync helper for every such endpoint without editing the spec. Detected failure terminals (failed, error, errored, cancelled, canceled, aborted) become failure criteria so the helper throws an AutoSDKPollingException instead of polling forever.
When a sibling non-GET operation in the same client group returns 2XX with a Location header — the common Apify/Replicate "create with 202 Accepted + Location: /resource/{id}" pattern — AutoSDK also emits a <CreateMethod>WaitAsync companion on the create endpoint. That companion calls the original create, extracts the resource id from the response Location header, and dispatches to the sibling's polling helper, so consumers get a single-call create-and-wait API instead of writing the Location-extraction glue per resource.
Dataset-backed evaluation APIs usually need an experiment loop around raw dataset, trace, score, and feedback endpoints. Enable --generate-evaluation-workflow-helpers in the CLI, or set <AutoSDK_GenerateEvaluationWorkflowHelpers>true</AutoSDK_GenerateEvaluationWorkflowHelpers> for the source generator, to emit a DatasetEvaluationRunner helper.
The generated runner accepts dataset items, an async task delegate, scorer delegates, optional experiment creation, and optional batch publishing for experiment items, scores, or feedback. It supports bounded concurrency, cancellation, trace/span/run id preservation, item-level failure capture, aggregate score/exception summaries, and batch-size controls while keeping raw endpoint methods intact. The helper class name can be configured with --evaluation-workflow-helper-class-name or <AutoSDK_EvaluationWorkflowHelperClassName>.
Singleton SDK clients that resolve credentials per call (for key rotation, multi-tenant routing, or session-scoped tokens) used to either bypass the generated auth pipeline with a DelegatingHandler or race on the shared Authorizations list. The generated AutoSDKClientOptions now exposes IAutoSDKAuthorizationProvider plus a built-in AutoSDKAuthorizationProviderHook. Implement the provider once, register it with client.Options.UseAuthorizationProvider(provider), and the hook resolves a fresh value per request — without mutating shared client state.
The provider returns IReadOnlyList<AutoSDKAuthorizationValue> (use AutoSDKAuthorizationValue.Bearer(token) or AutoSDKAuthorizationValue.ApiKeyHeader(name, value) factories) and can read from any per-call source: IServiceProvider, secret stores, async token caches, etc. Existing constructor-based Authorizations continue to work for callers that don't need per-request resolution.
For one-off "act-as" / multi-tenant routing scenarios, AutoSDKRequestOptions.Authorizations accepts a per-call list of AutoSDKAuthorizationValue. When non-empty, the hook applies those values directly and skips the client-level provider. The precedence order is per-request Authorizations → client AuthorizationProvider → constructor-time Authorizations list — the first non-empty source wins for a given outgoing request.
When GenerateDependencyInjection is enabled, the generated DependencyInjectionExtensions class also emits Add<Client>AuthorizationProvider<TProvider>() (typed) and Add<Client>AuthorizationProvider(resolver) (delegate) extension methods. Both register an IAutoSDKAuthorizationProvider in the DI container; the typed AddRunwayClient(...) / AddRunwayClient(configuration, ...) helpers automatically resolve and wire it via Options.UseAuthorizationProvider(provider) so consumers don't have to chain configuration.
Consumers commonly wrap HttpClient with a rotation-aware DelegatingHandler that stamps the current account-level credential per request — the canonical pattern when credentials live in Azure Key Vault, AWS STS, or any source that refreshes on cadence. Such handlers run after AutoSDK's send pipeline, so without coordination they'd clobber the per-request value the hook just resolved.
AutoSDK now stamps a marker on the outgoing HttpRequestMessage whenever the resolved Authorization is call-scoped (per-request RequestOptions.Authorizations or a client-level IAutoSDKAuthorizationProvider). The constructor-time Authorizations list — the account default — is NOT marked, so rotation handlers may freely overwrite it. The marker is exposed via AutoSDKHttpRequestOptions:
// In your DelegatingHandler:
protected override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
if (!RunwayApi.AutoSDKHttpRequestOptions.HasAuthorizationOverride(request))
{
request.Headers.Authorization = new AuthenticationHeaderValue(
"Bearer", _rotatingTokenSource.GetCurrent());
}
return base.SendAsync(request, cancellationToken);
}The helper uses HttpRequestMessage.Options on .NET 5+ and falls back to the legacy Properties bag on older targets, so a single SDK build works for both. Hand-written SDK extensions that set a non-default Authorization header (e.g. a session-scoped bearer returned by an upstream poll) should call AutoSDKHttpRequestOptions.StampAuthorizationOverride(request) so downstream rotation handlers know to skip the overwrite.
Operations whose OpenAPI security block overrides the document-level scheme — e.g. an endpoint that needs a session-scoped bearer distinct from the client-level account key — get the marker stamped automatically inside the generated method's request builder, so SDK authors don't have to remember the helper call for every override op. The marker is stamped after the Prepare<Method>Request partial hook runs, so authors customizing the request via PrepareRequest see the same final state a DelegatingHandler would.
When the OpenAPI security model can't express the distinction — e.g. two endpoints share the same scheme reference but expect different runtime credentials at call time — set x-call-scoped-auth: true on the operation to force the marker without restructuring its security block. Auto-detection treats the vendor extension as an explicit opt-in even when the structural security check would have returned false.
Cloud-hosted APIs often describe only bearer or API-key auth in OpenAPI even when official clients require request signing. Enable --generate-cloud-signing-helpers in the CLI, or set <AutoSDK_GenerateCloudSigningHelpers>true</AutoSDK_GenerateCloudSigningHelpers> for the source generator, to emit a CloudRequestSigner helper factory.
The generated helper includes provider metadata, environment-backed cloud credentials, AWS SigV4 signing with region/service/session-token support, Azure API-key and bearer-token signers that can be backed by TokenCredential, Tencent TC3-HMAC-SHA256 signing, and an AutoSDKHook adapter for signing after request serialization and before send. These helpers mutate HttpRequestMessage without replacing existing generated bearer/API-key constructors for providers that do not opt in. The helper class name can be configured with --cloud-signing-helper-class-name or <AutoSDK_CloudSigningHelperClassName>.
Many list endpoints follow offset (page / page_number + array-of-items response) or cursor (cursor / after + next_page_token / has_more) pagination patterns, and consumers end up writing the same per-resource paging loop in every SDK. Enable --generate-pageable-helpers in the CLI, or set <AutoSDK_GeneratePageableHelpers>true</AutoSDK_GeneratePageableHelpers> for the source generator, to emit an AutoSDKPager runtime helper plus auto-detected <Method>AutoPagingAsync companions.
The generated AutoSDKPager.OffsetAsync<TPage, TItem>(...) overload takes a fetch-page delegate, an item extractor, and an optional has_more predicate; AutoSDKPager.CursorAsync<TPage, TItem>(...) takes a fetch-by-cursor delegate plus a next-cursor extractor. Both expose results through IAsyncEnumerable<TItem> and respect EnumeratorCancellation. Auto-detection covers two pagination shapes:
- Offset style: a
page/page_number/pageNumber/pageIndexquery parameter plus a response with a single array property. Generates<Method>AutoPagingAsync(...page_number = 1)backed byAutoSDKPager.OffsetAsync. When the response also exposes a booleanhas_more/has_next/has_next_page(ormore) property, the detector wires it into the pager'shasMorepredicate so paging stops on an explicit "no more pages" signal rather than waiting for an empty page. - Cursor style: a
cursor/after/page_token/next_page/next_page_token/pagination_tokenquery parameter plus a response with a single array property AND a string-typed next-cursor field (next_cursor/next_page/next_page_token/next_page_cursor/after/last_id). Generates<Method>AutoPagingAsync(...cursor = null)backed byAutoSDKPager.CursorAsync.
Offset takes precedence when both shapes match. Detection is conservative: skips multi-array responses, ambiguous next-cursor candidates, and any non-GET shape.
For RFC 5988 Link-header pagination (GitHub, Apify, etc.) the runtime helper exposes two overloads of AutoSDKPager.LinkHeaderAsync<TPage, TItem>(...):
- A general form that takes
extractLinkHeader: Func<TPage, IEnumerable<string>?>so callers can pull the header from any response shape. - A convenience overload where the fetch returns
AutoSDKHttpResponse<TPage>and the helper auto-readsHeaders["Link"]— removing theextractLinkHeaderlambda boilerplate for the common case.
Both parse Link: <url>; rel="next" from the supplied header values, handling comma-separated multi-link headers (bracket-aware scoping) and space-separated rel tokens per RFC 8288, then thread the next URL through to the next fetch. The exposed ParseLinkHeaderRel(linkHeaderValues, linkRel) is public so consumers can use the same parser without going through the full pager. Codegen-level auto-detection for Link pagination isn't wired because the spec rarely encodes which parameter corresponds to the link target — consumers wire fetchPage to call <Method>AsResponseAsync(...) on the first iteration and dispatch by URL afterwards.
Bedrock-style APIs return chunked binary frames with application/vnd.amazon.eventstream content type — distinct from SSE or NDJSON. AutoSDK now detects this mime type alongside the existing SSE/NDJSON paths and generates an IAsyncEnumerable<TEvent> method backed by a generated AutoSDKAwsEventStreamReader frame parser. The reader exposes prelude/header/payload decoding for the AWS EventStream binary protocol (string, byte-array, bool, byte, short, int, long, timestamp, UUID header value types) without referencing the AWS SDK packages, so the path stays trim/AOT-friendly.
Each decoded AutoSDKAwsEventStreamFrame exposes the standard :message-type, :event-type, :content-type headers plus :exception-type / :error-code / :error-message headers. Exception or error frames raise AutoSDKAwsEventStreamException (with the offending frame attached) before the consumer enumerates further, matching how the AWS SDKs surface modeled exceptions inline. The existing <Method>AsStreamAsync raw-stream method is preserved for callers who want to layer the AWS SDK's own EventStream decoder for CRC validation or unknown frame inspection.
When AutoSDK_UseExtensionNaming or --use-extension-naming is enabled, AutoSDK consumes a curated set of third-party SDK metadata instead of treating every vendor extension as noise.
| Concern | Supported today | Intentionally ignored for now |
|---|---|---|
| Naming and grouping | x-fern-sdk-method-name, x-fern-sdk-group-name, x-fern-type-name, x-oaiMeta.name, x-speakeasy-name-override, x-speakeasy-group, x-stainless-naming for .NET / csharp names |
x-speakeasy-model-namespace, non-.NET x-stainless-naming blocks |
| Filtering and deprecation | x-fern-ignore, x-hidden, x-speakeasy-ignore, x-stainless-skip when it explicitly targets .NET, x-speakeasy-deprecation-message, x-stainless-deprecation-message |
language skips for other ecosystems |
| Enum metadata | x-enum-varnames, x-enum-descriptions, x-fern-enum, x-speakeasy-enums, x-speakeasy-enum-descriptions |
x-speakeasy-enum-format |
| Examples and docs | x-codeSamples, x-displayName, x-label |
language-specific doc overlays such as x-speakeasy-docs |
| Runtime behavior | x-stainless-const, x-call-scoped-auth (stamps AutoSDKHttpRequestOptions.AuthorizationOverride on operations whose runtime credential is per-call) |
pagination, retries, globals, server selection, the rest of the auth/runtime hints, and liblab config-only metadata |
That split is deliberate: AutoSDK consumes metadata that directly improves generated .NET names, docs, deprecations, and enum surfaces today, while broader runtime features stay tracked as separate issues instead of being silently half-implemented.
- Install the package
dotnet add package AutoSDK.SourceGenerators- Add the following optional settings to your csproj file to customize generation. You can check all settings here:
<ItemGroup Label="AutoSDK">
<AdditionalFiles Include="$(MSBuildThisFileDirectory)../../../docs/openapi.yaml" AutoSDK_OpenApiSpecification="true" />
</ItemGroup>
<!-- All settings optional -->
<PropertyGroup Label="AutoSDK">
<AutoSDK_Namespace>Ollama</AutoSDK_Namespace>
<AutoSDK_ClassName>OllamaApi</AutoSDK_ClassName>
<!-- By default, it generates all models/methods. You can disable this behavior using these properties -->
<AutoSDK_GenerateSdk>false</AutoSDK_GenerateSdk>
<AutoSDK_GenerateModels>true</AutoSDK_GenerateModels>
<AutoSDK_GenerateMethods>true</AutoSDK_GenerateMethods>
<AutoSDK_GenerateConstructors>true</AutoSDK_GenerateConstructors>
<AutoSDK_IncludeOperationIds>getPet;deletePet</AutoSDK_IncludeOperationIds>
<AutoSDK_ExcludeOperationIds>getPet;deletePet</AutoSDK_ExcludeOperationIds>
<AutoSDK_IncludeModels>Pet;Model</AutoSDK_IncludeModels>
<AutoSDK_ExcludeModels>Pet;Model</AutoSDK_ExcludeModels>
</PropertyGroup>- It's all! Now you can build your project and use the generated code. You also can use IDE to see the generated code in any moment, this is a example for Rider:
CLI generates Trimming/NativeAOT compatible code by default.
Since there are two source generators involved, we will have to create a second project so that the generator for the JsonSerializerContext will “see” our models
- Create new project for your models. And disable methods/constructors generation:
<PropertyGroup Label="AutoSDK">
<AutoSDK_GenerateSdk>false</AutoSDK_GenerateSdk>
<AutoSDK_GenerateModels>true</AutoSDK_GenerateModels>
<AutoSDK_GenerateJsonSerializerContextTypes>true</AutoSDK_GenerateJsonSerializerContextTypes>
</PropertyGroup>- Reference this project in your main project.
- Add
SourceGenerationContext.csfile to your main project with the following content:
using System.Text.Json.Serialization;
namespace Namespace;
[JsonSourceGenerationOptions(DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull)]
[JsonSerializable(typeof(AutoSDKTrimmableSupport))]
internal sealed partial class SourceGenerationContext : JsonSerializerContext;- Add the following settings to your main csproj file:
<PropertyGroup Label="AutoSDK">
<AutoSDK_GenerateSdk>false</AutoSDK_GenerateSdk>
<AutoSDK_GenerateMethods>true</AutoSDK_GenerateMethods>
<AutoSDK_GenerateConstructors>true</AutoSDK_GenerateConstructors>
<AutoSDK_JsonSerializerContext>Namespace.SourceGenerationContext</AutoSDK_JsonSerializerContext>
</PropertyGroup>- Add these settings to your new and main csproj file to enable trimming(or use Directory.Build.props file):
<PropertyGroup Label="Trimmable" Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net6.0'))">
<IsAotCompatible>true</IsAotCompatible>
<EnableTrimAnalyzer>true</EnableTrimAnalyzer>
<IsTrimmable>true</IsTrimmable>
<SuppressTrimAnalysisWarnings>false</SuppressTrimAnalysisWarnings>
<TrimmerSingleWarn>false</TrimmerSingleWarn>
</PropertyGroup>- It's all! Now you can build your project and use the generated code with full trimming/nativeAOT support.
This error happens if the generated file path is too long. This happens if you didn't activated long path support on windows. To enable it follow the offical docs: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#registry-setting-to-enable-long-paths
AutoSDK can generate typed WebSocket clients from AsyncAPI 3.0 specifications, producing send/receive methods for each channel operation.
autosdk generate asyncapi.yaml \
--namespace MyApi.Realtime \
--websocket-class-name MyRealtimeClient \
--output GeneratedThis generates:
- A WebSocket client class with connect/disconnect lifecycle
- Typed
Send*methods for publish operations - Typed
Receive*methods (via event callbacks) for subscribe operations - All associated models, enums, and JSON converters
When an API has both REST (OpenAPI) and WebSocket (AsyncAPI) specs that share model types, you can generate them into separate namespaces while avoiding model duplication:
# Step 1: Generate REST API (models + HTTP client) in main namespace
autosdk generate openapi.yaml \
--namespace MyApi \
--clientClassName MyApiClient \
--output Generated
# Step 2: Generate WebSocket client referencing existing REST types
autosdk generate asyncapi.yaml \
--namespace MyApi.Realtime \
--websocket-class-name MyRealtimeClient \
--types-namespace MyApi \
--generate-models false \
--json-serializer-context MyApi.SourceGenerationContext \
--output GeneratedKey options:
--types-namespace <ns>— Generated WebSocket client usesglobal::<ns>.{TypeName}references instead of its own namespace--generate-models false— Skips model/enum/converter generation (they already exist in the types namespace)--json-serializer-context <ctx>— References an existingJsonSerializerContextfrom the types namespace--websocket-class-name <name>— Overrides the generated WebSocket client class name
Note: AsyncAPI schema names must match the target namespace's type names. If they differ (e.g., OpenAI where AsyncAPI uses different names), use separate namespaces with full model generation instead.
- tryAGI/OpenAI — REST API + Realtime WebSocket API
- tryAGI/ElevenLabs — REST API + Realtime Speech-to-Text WebSocket API
- tryAGI/Xai — REST API + Realtime Voice Agent WebSocket API
AutoSDK is available as a Claude Code skill via skills.sh, enabling AI-assisted SDK generation directly from your terminal.
npx skills add tryAGI/AutoSDK@generating-dotnet-sdksOnce installed, you can use natural language prompts in Claude Code like:
- "Generate a C# SDK from this OpenAPI spec"
- "Scaffold a new AutoSDK project for the Stripe API"
- "Help me customize the generated client with streaming support"
Claude Code will use the skill's knowledge of AutoSDK CLI options, project conventions, and customization patterns to produce correct commands and code.
The skill provides Claude Code with detailed knowledge of:
- CLI commands and all their options (
generate,init,http,docs,convert,simplify,trim) - Standard project structure and the
generate.shregeneration pattern - AsyncAPI / WebSocket client generation and cross-namespace schema referencing
- Post-generation customization (partial classes, client hooks, trimming support)
- Troubleshooting common issues
Skill source: skills/generating-dotnet-sdks/
- https://github.com/tryAGI/OpenAI — REST + WebSocket (AsyncAPI)
- https://github.com/tryAGI/ElevenLabs — REST + WebSocket (AsyncAPI)
- https://github.com/tryAGI/Xai — REST + WebSocket (AsyncAPI)
- https://github.com/tryAGI/Ollama
- https://github.com/tryAGI/Anthropic
- https://github.com/tryAGI/LangSmith
- https://github.com/tryAGI/Replicate
- https://github.com/tryAGI/DeepInfra
- https://github.com/tryAGI/Leonardo
- https://github.com/HavenDV/GitHub.NET
