actionbook/rust-skills
Use when integrating crates or ecosystem questions.
npx skills add actionbook/rust-skills --skill m11-ecosystem
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
INVOKE FIRST for any LangChain / LangGraph / Deep Agents agent building project before consulti…
5K installsBuild and scale developer-led adoption through ecosystem programs. Use when deciding open vs cu…
1.6K installsOther skills from actionbook/rust-skills · top by installs.
npx skills add actionbook/rust-skills
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Alternate registries and mirrors of this skill.
npx skills add smithery/13eholder --skill m11-ecosystem
main
Files included with this skill beyond the listing page.
SKILL.md
4,504 B
SUMMARY.md
432 B
!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:
- Recent commits? - Active issue response? - Breaking changes frequency?
- Do you need the full crate or just a feature? - Can feature flags reduce bloat?
- Trait-based or concrete types? - Sync or async? - What bounds does it require?
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 |