Editorial criteria

What makes a good entry?

Suggest an SDK when it solves a concrete developer problem and has a trustworthy source. Include the official package, repository, documentation, supported languages, and the category where a developer would expect to find it.

• Describe the job it does in plain language.
• Distinguish official SDKs from community-maintained clients.
• Link directly to evidence for runtime support and key capabilities.
• Include limitations that could change a developer's decision.
• Disclose your relationship to the project when relevant.

Write source-backed notes

Prefer primary documentation and maintained repositories over comparison articles. Link to the page that supports the claim, identify the relevant package version where necessary, and avoid turning a documented optional feature into a universal guarantee.

## SDK name

- Category:
- Official or community-maintained:
- Package / installation source:
- Repository:
- Official documentation:
- Supported runtimes (with source):

### Useful for
Describe one concrete integration.

### Capabilities and limitations
Link each technical claim to a primary source.

### Relationship to the project
Maintainer, user, or independent contributor.

Improve an existing entry

Corrections are as valuable as new listings. Point out the exact statement, explain what changed, and include the official source. Useful fixes include a renamed package, an archived repository, a changed runtime requirement, or a capability that needs a more precise description.

Editorial principles

Keep recommendations independent and useful. Popularity alone does not establish quality, and a small library can be the right fit for a specific job. Explain the fit so readers can make their own decision.

• Be accurate before being comprehensive.
• Name costs, constraints, and missing capabilities when they matter.
• Keep comparison criteria consistent across providers.
• Send readers to the provider's current docs for changing details.