Add copilot-sdk-supercharged to community SDK listing (17 additional languages)

[jeremiahjordanisaacson]

Hi team! I maintain copilot-sdk-supercharged, a fork of this repo that extends the SDK to 17 additional programming languages beyond the official 5.

Additional languages supported: Rust, Ruby, PHP, Swift, Kotlin, C++, C, Dart, Scala, R, Perl, Lua, Shell/Bash, Elixir, Haskell, Clojure, and more.

Each SDK follows the same JSON-RPC architecture as the official SDKs and includes:

• Full session management (create, resume, disconnect)
• Tool registration (DefineTool pattern)
• Permission handling
• Streaming support
• v2.0 features: SessionFs, idle timeout, skills, session metadata, commands/elicitation

The SDKs are published to their respective package registries (npm, PyPI, NuGet, crates.io, RubyGems, Maven Central, Hex.pm, Clojars, LuaRocks) with 15,000+ total downloads.

Per the CONTRIBUTING.md guidance on community SDKs, I'd love to be listed in the \Unofficial, Community-maintained SDKs\ table in the README. Happy to discuss any questions!

I'll follow up with a small PR adding the entry.

[github-actions]

Thanks for the report! This issue has been labeled documentation since it relates to the Unofficial, Community-maintained SDKs table in README.md.

Documentation Gap Summary

What is affected:

• README.md — "Unofficial, Community-maintained SDKs" section (lines ~132–144)
• CONTRIBUTING.md — the paragraph describing how "SDKs for other languages" may be linked

What is missing or unclear:

1. No explicit criteria for inclusion — CONTRIBUTING.md says the team "may offer to link" to community SDKs, but there are no documented criteria for what qualifies a community SDK for listing (e.g., protocol compatibility requirements, maintenance expectations, package registry publication, minimum adoption thresholds).

2. No documented process for requesting a listing — The CONTRIBUTING.md guidance implies the team will reach out, but doesn't describe a path for community SDK maintainers to proactively request inclusion.

3. Table structure assumes one-entry-per-language — The current table lists individual language SDKs (Rust, Clojure, C++). A multi-language fork like copilot-sdk-supercharged that bundles 17 languages doesn't fit neatly into this format, and the README provides no guidance on how such projects should be represented.

Suggested Documentation Improvements

• Add a short "How to get your SDK listed" subsection under the community SDKs table (or in CONTRIBUTING.md) that describes the criteria and process — e.g., link to the issue tracker with a specific label or template.
• Clarify whether the table is intended for individual-language SDKs only, or if multi-language community projects are also in scope.
• Consider adding a note about the expected level of protocol compatibility (which JSON-RPC methods/events must be supported) so community maintainers can self-assess readiness before requesting a listing.

Generated by Documentation Handler for issue #1154 · ● 194K · ◷

[SteveSandersonMS]

@jeremiahjordanisaacson Thanks for the suggestion but I don't think we should link to this repo. Most of those SDKs don't look right (they don't actually codegen full support for all the RPC methods, so for example you couldn't actually use things like SessionFs, and they don't have proper E2E test suites - many have no tests at all).

If you're interested in creating an SDK for an individual language that you have a speciality in, and it will fully support all APIs, have a true E2E test suite, and most importantly you will support with ongoing updates and responses to community questions, then we could certainly consider linking to it!

Hope that seems OK.