About sdk-onboarding-integration-review
A skill for teams designing SDK onboarding and integration journeys. It turns questions about documentation, authentication, examples, errors, versioning, and telemetry into a plan with owners, checkpoints, metrics, and recovery steps.
Key features
- 01Maps the path to a first successful API call
- 02Defines documentation and sample needs
- 03Plans auth, sandbox, and error handling
- 04Creates journey maps and decision tables
- 05Adds metrics, owners, and recovery steps
Use cases
- 01Reviewing an SDK quickstart
- 02Planning sandbox and credential setup
- 03Improving integration error messages
- 04Preparing version changes and migration guidance
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ sylphxai/ skills --skill sdk-onboarding-integration-reviewAfter installing, type/sdk-onboarding-integration-reviewin Claude Code to confirm it loaded.
Bundled filesagents/openai.yamlreferences/sdk-onboarding-integration-patterns.md
Details
From the project READMESDK Onboarding Integration Review
Use this skill to convert a SDK onboarding, integration success, quickstarts, auth keys, examples, errors, versioning, and developer telemetry question into a concrete artifact with owners, gates, metrics, and recovery paths.
Workflow
- Identify target developer, integration job, supported languages, auth model, first success event, sandbox needs, and common failure points.
- Read
references/sdk-onboarding-integration-patterns.md. - Map path from discovery to first successful API call/webhook/event and then production readiness.
- Define docs IA, samples, environment setup, keys, mock/sandbox data, error taxonomy, observability, migration/versioning, and support handoff.
- Produce integration journey, state machine, decision table, event schema, quickstart checklist, and failure-mode fixes.
When not to use
- Do not use for generic advice the base model already handles without this skill's specific artifact contract.
Guardrails
- Do not optimize docs volume instead of time-to-first-success.
- Do not require production credentials or real money/data to complete a safe quickstart.
- Do not ship SDK errors that hide request IDs, retryability, or misconfiguration cause.
- Do not break existing integrations without versioning, changelog, migration guide, and compatibility tests.
Output format
Developer context:
Integration job / language / first success event:
SDK onboarding plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |
Docs, samples, and errors:
- <item> -> <policy, metric, edge case, support note>
Versioning and migration policy:
- <trigger> -> <action, communication, owner>
Comments
Markdown supported