How the router decides

Updated Jul 18, 2026

rust-router routes by the concrete problem at hand, not by the file being edited. A short version of its decision table:

  • ownership, borrowing, aliasing, or interior mutability → rust-memory-and-state,
  • Polonius adoption, NLL workaround audits, borrow-checker-driven defensive clones, or borrow-centric API evolution → nll-to-polonius,
  • trait bounds, generics, API shape, newtypes, or typestate → rust-types-and-apis,
  • error shape, panic boundary, or library-versus-binary handling → rust-errors,
  • unit-test fixtures, table tests, assertion helper refactors, snapshots, or serialized tests → rust-unit-testing,
  • tasks, Send/Sync, blocking, channels, or cancellation → rust-async-and-concurrency,
  • allocation pressure, layout, or benchmark discipline → rust-performance-and-layout,
  • unsafe, FFI, layout guarantees, or soundness review → rust-unsafe-and-ffi,
  • crate boundaries, features, public surface, or layering → arch-crate-design,
  • dependency hygiene, cargo-vet, cargo-deny, SemVer guardrails → arch-supply-chain,
  • recording a hard-to-reverse architectural decision (Y-Statement) → arch-decision-records,
  • choosing a verification tool (Miri, proptest, cargo-mutants, loom, shuttle, turmoil, Kani, Verus) → rust-verification,
  • HTTP services, middleware, or request state → domain-web-services,
  • CLIs, workers, daemons, or long-running jobs → domain-cli-and-daemons,
  • no_std, firmware, devices, or edge nodes → domain-embedded-and-iot.

The router's pairing rules and escalation triggers live in its SKILL.md; the routing matrix covers the residual ambiguous cases.