Canonical Rust 2026 stack chooser — recommends the right crate (+ exact version + alternative rejected + reason) for any domain : HTTP servers, async runtimes, databases, crypto, parsing, CLI, terminal UIs, WASM, GUI, observability, ML. Use this skill *aggressively* — whenever the user asks 'which crate', 'best library for X', 'recommend a stack', 'should I use Y or Z', 'how do I do some-thing in Rust', is about to write or edit any Cargo.toml, mentions adding a dependency, or hesitates between several libraries. Also use proactively before suggesting any crate when discussing architecture, even if the user did not ask explicitly. The recommendations are fact-checked against awesome-rust top-ranked sources, RUSTSEC advisories, OSI license safety (no GPL contamination of Apache-2.0 aphrody), and last-commit recency (active maintenance). Refuses deprecated stacks (openssl 0.9, actix-web 4.x for new code, tokio 0.2, hyper 0.14 raw, native-tls on Linux servers, GPL crypto wrappers).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Canonical Rust 2026 stack chooser — recommends the right crate (+ exact version + alternative rejected + reason) for any domain : HTTP servers, async runtimes, databases, crypto, parsing, CLI, terminal UIs, WASM, GUI, observability, ML. Use this skill *aggressively* — whenever the user asks 'which crate', 'best library for X', 'recommend a stack', 'should I use Y or Z', 'how do I do some-thing in Rust', is about to write or edit any Cargo.toml, mentions adding a dependency, or hesitates between several libraries. Also use proactively before suggesting any crate when discussing architecture, even if the user did not ask explicitly. The recommendations are fact-checked against awesome-rust top-ranked sources, RUSTSEC advisories, OSI license safety (no GPL contamination of Apache-2.0 aphrody), and last-commit recency (active maintenance). Refuses deprecated stacks (openssl 0.9, actix-web 4.x for new code, tokio 0.2, hyper 0.14 raw, native-tls on Linux servers, GPL crypto wrappers).
Mode /goal permanent : décider seul, ne pas s'arrêter avant recommandation justifiée.
When a user asks "what should I use for X in Rust?", do not improvise. Do not
default to the first crate that comes to mind. Consult this table, pick the
canonical choice, and explain why the alternative was rejected. Naming
the rejected alternative is half the value — it tells the user you considered
the obvious option and ruled it out for a reason.
When to engage this skill
Direct question: "best crate for X", "which library", "should I use Y or Z"
Architecture discussion that will result in a dependency choice
About to edit a Cargo.toml (add, bump, replace a dep)
User wrote "let's use openssl" / "let's use actix" / any other phrase
matching the § Anti-patterns table — flag it, recommend
the modern equivalent, but do not block (advisory per project policy).
Why a curated stack matters
Assume an Apache-2.0 / permissive host project shipping across Linux
(priority #1), Windows, and wasm32 (adapt to the host repo's actual license if
different — the GPL-contamination guard still applies to permissive projects).
Three failure modes the canonical stack protects against:
License contamination — GPL/AGPL crates virally infect Apache-2.0
binaries at link time. Apex offenders: unicorn-engine 2.x (CPU emu),
radare2-rs, certain reverse-engineering wrappers.
Cross-platform breakage — native-tls on Linux pulls OpenSSL system
libs that drift across distros; tao/wry pull GTK3 (CVE-tagged). Anything
that breaks on Linux #1 is non-mergeable (cf. CLAUDE.md §6).
Bit-rot — popular ≠ maintained. actix-web 4.x keeps working but
maintenance velocity has dropped; tokio 0.2/0.3 is fossil. Recency
matters more than star count past ~10k★.
For toolchain / language features (Rust 1.95, Edition 2024 idioms, async
closures, CVE-2026-33056, WASM 1.96 breakage), consult the sibling skill
rust-best-practices-2026 — that skill covers how to write the code; this
one covers what to depend on.
Canonical stack table
The Pick column is the recommendation. The Reject column is what NOT
to use (or what the user might reasonably suggest first). The Why is the
half-sentence that lets the user accept the trade-off.
If the user's question covers **multiple domains** (e.g. "build a REST API
with auth and Postgres"), produce one block per domain, ordered by build-up
dependency (runtime → server → db → auth → observability).
If the user explicitly **insists** on a rejected stack ("I want actix because
my team knows it"), accept the choice but record the trade-off briefly:
*"Fine, actix-web 4 is still production-grade; the maintenance gap with
axum's velocity is the watchpoint. Pin to 4.9.x and re-evaluate in 6mo."*
---
## Integration with aphrody-marketplace::awesome
When the workspace has run `aphrody marketplace awesome manifest`, a curated
JSON whitelist sits at `var/data/awesome/stack-whitelist.json` (cf.
`aphrody_marketplace::awesome::to_stack_policy`). Prefer that file as the
**dynamic source of truth** — it reflects the most recent fact-checked
top-of-awesome-rust snapshot. The table above is the **embedded fallback**
when the manifest is not yet generated (first-run, hermetic CI).
Both sources are consistent by design — the table is hand-curated from the
same top-200 awesome-rust sources the curator scrapes.
For deeper notes on why each Pick won (RUSTSEC history, license audit,
benchmark deltas), see `references/anti-patterns.md` and the live data in
`var/data/awesome/ranked.json`.
---
## Output discipline
- **Always** name the version range (`"0.8"`, not just `axum`).
- **Always** explain the rejected alternative in one line.
- **Never** recommend a crate from the [§ Anti-patterns](#anti-patterns)
table without flagging it.
- **Refuse** GPL / AGPL crates outright when the user's project is
Apache-2.0 / MIT — state the contamination risk in one sentence.
- **Defer** to `rust-best-practices-2026` skill for language/toolchain
guidance (Edition 2024, async closures, WASM 1.96 break, CVE-2026-33056).
