M11 Ecosystem
Pick and wire the right Rust crates, features, and workspace patterns when Cargo errors or integration questions block progress.
Overview
m11-ecosystem is an agent skill for the Build phase that recommends Rust crates and integration patterns for dependencies, features, workspaces, and FFI.
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill m11-ecosystemWhat is this skill?
- Integration decision table: serde, tokio, reqwest, axum, sqlx, clap, anyhow/thiserror, tracing
- Maintenance and API-stability checklist before adding dependencies
- Covers PyO3, wasm, bindgen, cbindgen, napi-rs for native and Python extension paths
- Maps common compiler errors (E0425, E0433, E0603) to ecosystem fixes
- Auto-injects current [dependencies] snippet from Cargo.toml via grep
- Integration decision table with 8+ common need rows (serialization through logging)
Adoption & trust: 710 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You hit E0425/E0433-style errors or face an integration choice and are unsure which maintained crate and feature set belongs in Cargo.toml.
Who is it for?
Rust backends and CLIs where dependency discipline and tokio/serde stack conventions matter.
Skip if: Pure frontend or non-Rust stacks, or deep algorithm design with no new crates involved.
When should I use this skill?
Integrating crates or ecosystem questions; keywords include E0425, E0433, dependency, feature flag, workspace, PyO3, wasm, which crate to use.
What do I get? / Deliverables
You align on a standard crate choice, workspace/feature layout, and integration approach that matches your app versus library error-handling needs.
- Recommended crate and feature set
- Cargo.toml integration guidance
- Maintenance checklist answers
Recommended Skills
Journey fit
How it compares
Skill playbook for crate selection—not a substitute for docs.rs or cargo-audit when you need vulnerability reports.
Common Questions / FAQ
Who is m11-ecosystem for?
Indie developers and agent users building Rust CLIs, APIs, or native extensions who want opinionated ecosystem defaults.
When should I use m11-ecosystem?
When integrating crates, editing Cargo.toml features, choosing async/HTTP/DB/logging stacks, or debugging cannot-find-crate errors during build.
Is m11-ecosystem safe to install?
Check the Security Audits panel on this page; the skill may run grep on Cargo.toml locally—no network is required by the skill text itself.
SKILL.md
READMESKILL.md - M11 Ecosystem
## Current Dependencies (Auto-Injected) !`grep -A 100 '^\[dependencies\]' Cargo.toml 2>/dev/null | head -30 || echo "No Cargo.toml found"` --- # Ecosystem Integration > **Layer 2: Design Choices** ## Core Question **What's the right crate for this job, and how should it integrate?** Before adding dependencies: - Is there a standard solution? - What's the maintenance status? - What's the API stability? --- ## Integration Decision → Implementation | Need | Choice | Crates | |------|--------|--------| | Serialization | Derive-based | serde, serde_json | | Async runtime | tokio or async-std | tokio (most popular) | | HTTP client | Ergonomic | reqwest | | HTTP server | Modern | axum, actix-web | | Database | SQL or ORM | sqlx, diesel | | CLI parsing | Derive-based | clap | | Error handling | App vs lib | anyhow, thiserror | | Logging | Facade | tracing, log | --- ## Thinking Prompt Before adding a dependency: 1. **Is it well-maintained?** - Recent commits? - Active issue response? - Breaking changes frequency? 2. **What's the scope?** - Do you need the full crate or just a feature? - Can feature flags reduce bloat? 3. **How does it integrate?** - Trait-based or concrete types? - Sync or async? - What bounds does it require? --- ## Trace Up ↑ To domain constraints (Layer 3): ``` "Which HTTP framework should I use?" ↑ Ask: What are the performance requirements? ↑ Check: domain-web (latency, throughput needs) ↑ Check: Team expertise (familiarity with framework) ``` | Question | Trace To | Ask | |----------|----------|-----| | Framework choice | domain-* | What constraints matter? | | Library vs build | domain-* | What's the deployment model? | | API design | domain-* | Who are the consumers? | --- ## Trace Down ↓ To implementation (Layer 1): ``` "Integrate external crate" ↓ m04-zero-cost: Trait bounds and generics ↓ m06-error-handling: Error type compatibility "FFI integration" ↓ unsafe-checker: Safety requirements ↓ m12-lifecycle: Resource cleanup ``` --- ## Quick Reference ### Language Interop | Integration | Crate/Tool | Use Case | |-------------|------------|----------| | C/C++ → Rust | `bindgen` | Auto-generate bindings | | Rust → C | `cbindgen` | Export C headers | | Python ↔ Rust | `pyo3` | Python extensions | | Node.js ↔ Rust | `napi-rs` | Node addons | | WebAssembly | `wasm-bindgen` | Browser/WASI | ### Cargo Features | Feature | Purpose | |---------|---------| | `[features]` | Optional functionality | | `default = [...]` | Default features | | `feature = "serde"` | Conditional deps | | `[workspace]` | Multi-crate projects | ## Error Code Reference | Error | Cause | Fix | |-------|-------|-----| | E0433 | Can't find crate | Add to Cargo.toml | | E0603 | Private item | Check crate docs | | Feature not enabled | Optional feature | Enable in `features` | | Version conflict | Incompatible deps | `cargo update` or pin | | Duplicate types | Different crate versions | Unify in workspace | --- ## Crate Selection Criteria | Criterion | Good Sign | Warning Sign | |-----------|-----------|--------------| | Maintenance | Recent commits | Years inactive | | Community | Active issues/PRs | No response | | Documentation | Examples, API docs | Minimal docs | | Stability | Semantic versioning | Frequent breaking | | Dependencies | Minimal, well-known | Heavy, obscure | --- ## Anti-Patterns | Anti-Pattern | Why Bad | Better | |--------------|---------|--------| | `extern crate` | Outdated (2018+) | Just `use` | |