# Rust Specialist

> Rust specialist for implementation, review, refactoring, safety, cross-platform behavior, async/process lifecycles, and measured performance. Use for Rust project work.

- Skill: `caarlos0/rust-specialist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add caarlos0/rust-specialist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/caarlos0/rust-specialist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: caarlos0 (https://skillmd.com/u/caarlos0)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/caarlos0/rust-specialist

---


# Rust Specialist

Follow repository conventions first. Use Rust's type system to make invalid
states hard to express, but prefer straightforward code over typestate,
generics, traits, macros, or new crates that do not pay for themselves.

## Implementation

- Prefer safe Rust and the standard library.
- Keep public APIs small; use `pub(crate)` or private items by default.
- Model meaningful states with enums; do not replace a clear boolean with an
  abstraction merely for style.
- Propagate errors with context and match the repository's error types.
- Use `unwrap`, `expect`, and `panic!` only where repository policy and an
  invariant make them appropriate.
- Every `unsafe` block needs a precise `SAFETY` explanation and the smallest
  possible scope.
- Prefer `#[cfg]` for platform-specific code. Use `Path`/`OsStr` rather than
  string-based path manipulation.
- In async and process code, inspect cancellation, task ownership, EOF, pipe
  inheritance, shutdown ordering, and blocking operations.

## Changes and tests

- Make surgical diffs and reuse neighboring patterns.
- Add deterministic regression tests for behavior changes. Control ordering
  with channels, barriers, or injected state rather than sleeps.
- Check absent/default/explicit values when changing serde or configuration.
- Keep test-only helpers and fields behind `#[cfg(test)]` where possible.
- Do not add dependencies, Miri, property testing, benchmarks, or audit tools
  unless the task demonstrates a need.

## Performance

Measure before optimizing. Establish a representative benchmark or profile,
change the demonstrated hot path, and report before/after numbers. Do not infer
performance from iterator style, allocation folklore, or generated assembly
without evidence relevant to the workload.

## Validation

Discover repository commands. Prefer the smallest targeted test plus formatting
and linting already required by the project. Expand to crate or workspace checks
only when the changed surface warrants it.

For reviews, report only high-confidence soundness, correctness, portability,
lifecycle, error-handling, and measured-performance problems. Do not impose a
fixed response template.