rust-code-expert

Rust code expert

Overview

Use this skill for small, compilable Rust changes with explicit ownership, an error contract, a target triple, and executable proof. Own core Rust language work, Cargo workflow, and native-target delivery. Route browser and WebAssembly targets to wasm-rust-expert. Start with references/task_selection.md to classify the request, then use references/topic_index.md for focused guidance, a local source, and an oracle.

Workflow

1. Classify the Rust task and name its contract.

• Identify the crate, binary or library boundary, target triple, public API, inputs, outputs, ownership transfer, error type, and performance concern.
• Match borrow checker, lifetime, trait, Cargo, Tokio, unsafe, FFI/PyO3, Result, CLI, or performance work in references/topic_index.md.
• Select wasm-rust-expert for wasm-bindgen, wasm-pack, web-sys, wasm32-unknown-unknown, browser bundles, browser canvas, and native-versus-Wasm parity.

1. Detect the project shape and establish the work surface.

• Inspect Cargo.toml, Cargo.lock, src/, workspace members, existing tests, target-specific configuration, CI commands, and the failing compiler output.
• Existing project: name the owning module, public call sites, current tests, and the narrowest behavior to preserve.
• Greenfield project: create the smallest crate, domain and error types, an entry point, and one executable success path.
• Read references/project_workflow.md for the project-shaped sequence and artifact locations.

1. Model ownership before editing implementation details.

• Draw the value flow: creator, borrower, mutator, consumer, and lifetime relationship at each API edge.
• Express invalid states with enums, compose behavior with traits, and expose fallible operations as Result with contextual errors.
• Keep unsafe, FFI, and PyO3 boundaries small, documented, and wrapped by a safe Rust-facing API.

1. Implement one focused vertical slice.

• Make the smallest change that fulfills the contract in the owning module.
• Prefer direct ownership and borrowing, explicit trait bounds, and standard library types before adding dependencies.
• Confirm the crate API and compatible version in docs.rs, then use cargo add and record feature and target requirements in Cargo.toml.

1. Build executable evidence as the change develops.

• Run cargo fmt --check, cargo check, focused cargo test, and cargo clippy -- -D warnings from the relevant workspace root.
• Use compiler diagnostics as the first ownership and type oracle, then add a deterministic unit, integration, CLI, FFI, or performance test.
• Read references/testing_and_oracles.md to choose the required oracle and measurement.

1. Review the delivered behavior.

• Confirm the command, library API, or binding returns actionable errors with useful Result context.
• Recheck feature flags, platform assumptions, public documentation, and benchmark conditions before reporting a performance conclusion.