bindings

Solid

Cross-language binding architecture rules: bindings as minimal glue, canonical API surface ordering (core, ABI, language), per-language test suites in CI, generated-code discipline, and error/async boundary preservation. Load when designing or reviewing polyglot language bindings for a shared core.

Data & Documents 137 stars 13 forks Updated today MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
71
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
36
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

- Bindings are minimal glue: call the core library, convert types, convert errors — no business logic. - Canonical surface: core API first, stable native ABI second, language bindings third. - Keep integrations and framework adapters outside language bindings unless they are the binding's public purpose. - Give each binding its own language-native test suite and run it in CI. - Generated binding and e2e code must not be hand-edited. Change the source schema, generator, or core API instead. - Error conversion must preserve context across every boundary: message, numeric code when available, and operation. - Async boundaries must match host runtime conventions; do not block event loops, schedulers, or UI threads.

Details

Author
Goldziher
Repository
Goldziher/ai-rulez
Created
1 years ago
Last Updated
today
Language
Go
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Solid

rust-polyglot-conventions

Rust conventions for a core that backs multiple language bindings: stable-edition tooling, typed Result errors with no panics in library paths, rustdoc with error docs, isolated unsafe, Send futures, FFI-friendly DTOs, and single-source version syncing. Load when writing or reviewing a Rust core exposed through polyglot bindings.

137 Updated today
Goldziher
AI & Automation Listed

polyglot-core-standard

Enforce a strict, drift-free, AI-navigable standard for polyglot repos built around a shared native core (typically a Rust core) consumed by host languages (Swift, Kotlin, Python, …) through generated (UniFFI/cbindgen/protobuf) or hand-written (PyO3/JNI) bindings. It governs the seams between languages — not each language's internals, which it delegates to rust/swift/python- project-standard. The non-negotiables: one canonical core owns all shared logic + the data model; the cross-language contract is declared exactly once and bindings are derived, never hand-mirrored; the FFI boundary is the typed, fallible, parse-don't-validate seam and no panic ever crosses it; generated bindings are vendored artifacts excluded from gates while hand-written binding layers are governed core code; binding freshness is drift-guarded; one composed repo-level zero-warning gate runs every sub-tree's gate; the toolchain + binding-generator matrix is pinned; the AI provider seam lives in exactly one sub-tree; and a CLAUDE.md routi

1 Updated 2 weeks ago
VoldemortGin
Data & Documents Solid

napi-rs-bindings

napi-rs conventions for exposing a Rust core to Node.js: #[napi] macros, napi::Error mapping, auto-generated .d.ts types, async Promises, and CommonJS/ESM output. Load when generating or reviewing napi-rs Node.js bindings for a Rust library.

137 Updated today
Goldziher