Generate Comprehensive SDK Documentation

This is an SDK-documentation skill that specifies how to structure developer-facing docs to minimize time-to-first-success: progressive disclosure (quickstart before comprehensive guides), task-oriented organization, consistent navigation, and writing for scanning before reading. Its quickstart template is built to get a developer to a working call in under 10 minutes, with a prerequisites checklist, install command, and a runnable first example:

import { CompanySDK } from '@company/sdk';

const client = new CompanySDK({
  apiKey: 'your-api-key-here',
  environment: 'sandbox' // or 'production'
});

// Your first API call
const result = await client.users.create({
  email: 'user@example.com',
  name: 'John Doe'
});

console.log('User created:', result.id);

It also specifies an authentication section covering both API-key and OAuth 2.0 flows with an explicit security note never to hardcode credentials, and a method-documentation template that pairs parameter and return-type descriptions with a runnable example and a list of possible errors - for example 400 BadRequest for invalid input, 409 Conflict for a duplicate resource, and 429 RateLimited with a retry hint.

Use this skill when writing or restructuring SDK reference and guide content that needs to actually get a developer integrated quickly - every code example is required to be self-contained (with imports and setup), realistic (meaningful variable names and data), and error-handled, and language-specific variants (JavaScript and Python shown) should be offered where possible. It also covers framework-specific integration guides (a Next.js example separates server-side usage with a private API key from client-side usage restricted to a public key) and documentation maintenance (semantic versioning of the docs themselves, migration guides between major versions, and CI validation of every code example). It is not a general technical-writing skill - it's scoped specifically to SDK and API documentation with runnable code, so it isn't the right fit for conceptual or narrative documentation with no code to validate.

Input is the SDK's actual API surface - methods, parameters, auth flows, error codes; output is a documentation set: a quickstart guide, an authentication guide covering API-key and OAuth patterns, method-reference pages following a consistent template (signature, parameters, return type, example, possible errors), framework-specific integration guides, and a maintenance plan covering versioning, deprecation timelines, and CI-validated code examples.

Assumes a CI/CD pipeline that validates every code example and tests installation instructions on clean environments; recommends embedding runnable examples via platforms like CodeSandbox and interactive "Try it" buttons that execute real API calls.

Developer-relations and technical-writing teams producing SDK or API documentation who want a consistent structure - quickstart, auth guide, method reference, framework guides, and a validated-examples maintenance process - rather than ad hoc docs that drift from the actual SDK behavior.