rust-skill

Migrate a Rust codebase to the Polonius borrow checker (location-sensitive analysis, nightly flag -Zpolonius=next) and evolve owned-value internal APIs into the reference-returning, borrow-centric designs that NLL discouraged. Use this skill whenever the user mentions Polonius, NLL limitations, borrow-checker workarounds, defensive clones, double map lookups, get-or-insert helpers, lending iterators, reducing clone counts, or asks to audit, simplify, de-clone, or redesign Rust APIs around borrowing. Also use it when reviewing Rust code containing clone-to-appease-borrowck patterns, entry() calls with cloned keys, id/index indirection standing in for references, or clone-modify-writeback sequences — even if the user does not name Polonius. Provides two modes (workaround retirement; ownership-model evolution), a pattern catalogue with lifetime-versus-aliasing discriminators, an API evolution playbook, worked examples, and a documentation strategy.

Route Rust work to the smallest useful skill. Use for Rust coding, design, compile errors, API questions, crate layout, async, performance, unsafe, or domain-specific Rust work.

Design and maintain Rust unit tests with clear helper boundaries, rstest fixtures and parameterization, serial_test isolation, fallible setup, and rich assertions with googletest, pretty_assertions, and insta. Use when refactoring assertion helpers, replacing brittle boolean assertions, shaping table tests, or deciding between equality, matcher, and snapshot assertions.

Use for Rust crate boundaries, workspace structure, feature flags, public versus internal APIs, layering, and testable module design.

Capture architectural decisions in Rust projects using the Y-Statement format. Use when a choice is hard to reverse, when the rationale will outlive its author, or when reviewers keep asking "why did we pick this?". Especially relevant for typestate, trait bounds, public API shape, `unsafe` invariants, runtime selection, and verification tooling.

Audit and curate a Rust project's dependency graph. Use for `cargo-vet`, `cargo-audit`, `cargo-deny`, lockfile hygiene, version pinning, and the policy of who is trusted to ship what. Also for SemVer guardrails (`cargo-semver-checks`, `cargo-public-api`) at the publishing boundary.

Write and maintain Kani bounded model checking harnesses for Rust. Use when verifying structural invariants, unsafe code, bounded state machines, or dispatch logic via exhaustive symbolic execution.

Write and maintain proptest property tests for Rust, including custom strategies, shrinking discipline, regression files, and state-machine tests. Use when checking that a property holds across a generated input domain and when a unit test or example does not exercise enough of the input space.

Use for ownership, borrowing, lifetimes, aliasing, smart pointers, interior mutability, resource acquisition is initialisation (RAII), and resource handoff in Rust.

Use for Rust performance work, allocation pressure, data layout, hot-path APIs, benchmarks, and when layout or copying choices affect runtime behaviour.

Use for trait bounds, generics, trait objects, newtypes, typestate, conversion boundaries, public API design, and crate-facing Rust interfaces.

Use for unsafe Rust, raw pointers, `MaybeUninit`, `NonNull`, foreign function interface (FFI), application binary interface (ABI) boundaries, layout guarantees, and soundness review.

Select and combine Rust verification tools — Miri, sanitizers, property testing, mutation testing, deterministic concurrency exploration (loom, shuttle, turmoil), bounded model checking (Kani), and deductive proofs (Verus). Use when choosing the smallest tool that gives the required guarantee for a given failure mode.

Write and maintain Verus deductive proofs for Rust code. Use for formal verification of pure functions, ordering invariants, mapping logic, and properties that require unbounded reasoning beyond bounded model checking.

Use for Rust `dead_code` and `unused_imports` findings, especially when conditional compilation, feature flags, target-specific code, or test-only code change what actually gets compiled. Prefer conditional compilation, narrowly scoped inline modules, and in-function imports so only needed code enters each compiled module. Use when deciding whether code should move behind `#[cfg(...)]`, into a tighter module, or into a narrower import scope instead of suppressing lints.

Use for Rust command-line interfaces (CLIs), workers, daemons, batch jobs, and services where process lifecycle, operator feedback, and shutdown rules matter.

Use for Rust `no_std`, firmware, device control, interrupts, constrained edge nodes, and Internet of Things (IoT) systems where memory, timing, and hardware contracts dominate.

Use for Rust HTTP services, request handlers, middleware, shared state, backpressure, and shutdown behaviour in web-facing systems.

Use for async Rust, task ownership, `Send` and `Sync`, shared state, channels, cancellation, blocking boundaries, runtimes, and shutdown behaviour.

Use for Rust error design, `Result` shape, panic boundaries, context propagation, library vs binary handling, retryability, and failure classification.