
The m11-ecosystem skill helps developers select appropriate Rust crates and manage dependencies by providing decision matrices, evaluation criteria, and integration patterns for common use cases like serialization, async runtimes, HTTP frameworks, and language interoperability. It's designed for Rust developers and maintainers who need to make informed choices about adding external dependencies, assessing crate quality and maintenance status, and understanding how new crates integrate with existing code architecture. The skill solves the problem of decision paralysis when choosing between multiple crate options and ensures selections align with project constraints and team expertise.
$ npx -y skills add zhanghandong/rust-skills --skill m11-ecosystem --agent claude-codeInstalls into .claude/skills of the current project.
!grep -A 100 '^\[dependencies\]' Cargo.toml 2>/dev/null | head -30 || echo "No Cargo.toml found"
Layer 2: Design Choices
What's the right crate for this job, and how should it integrate?
Before adding dependencies:
| 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 |
Before adding a dependency:
Is it well-maintained?
What's the scope?
How does it integrate?
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? |
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
| 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 |
| Feature | Purpose |
|---|---|
[features] | Optional functionality |
default = [...] | Default features |
feature = "serde" | Conditional deps |
[workspace] | Multi-crate projects |
| 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 |
| 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-Pattern | Why Bad | Better |
|---|---|---|
extern crate | Outdated (2018+) | Just use |
#[macro_use] | Global pollution | Explicit import |
Wildcard deps * | Unpredictable | Specific versions |
| Too many deps | Supply chain risk | Evaluate necessity |
| Vendoring everything | Maintenance burden | Trust crates.io |
| When | See |
|---|---|
| Error type design | m06-error-handling |
| Trait integration | m04-zero-cost |
| FFI safety | unsafe-checker |
| Resource management | m12-lifecycle |
Sponsors