Skip to content

/ia-rust-systems

Rust patterns for CLI tools, backend services, and general application code. Use when working with Rust, Cargo workspaces, axum/tokio services, clap CLIs, async concurrency, or configuring clippy, rustfmt, cargo-nextest, or Cargo.toml.

From plugin
2831 skills12 commands
shell
$ npx -y skills add iliaal/whetstone --skill ia-rust-systems --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/ia-rust-systems
How auto-invocation works

Context preview

The summary Claude sees to decide when to auto-load this skill.

Rust patterns for CLI tools, backend services, and general application code. Use when working with Rust, Cargo workspaces, axum/tokio services, clap CLIs, async concurrency, or configuring clippy, rustfmt, cargo-nextest, or Cargo.toml.

SKILL.md

ia-rust-systems.SKILL.md
name: ia-rust-systems
class: language
description: >-
  Rust patterns for CLI tools, backend services, and general application code.
  Use when working with Rust, Cargo workspaces, axum/tokio services, clap CLIs,
  async concurrency, or configuring clippy, rustfmt, cargo-nextest, or Cargo.toml.
paths: "**/*.rs,**/Cargo.toml"

Rust Systems & Services

Covers modern application-layer Rust (edition 2024): CLIs, web services, libraries. Not `no_std`/embedded.

Tooling

| Tool | Purpose | |------|---------| | `cargo` | Build, dep management, script runner | | `clippy` | Lint (`cargo clippy --workspace --all-targets -- -D warnings`) | | `rustfmt` | Formatter (`cargo fmt --all`) | | `cargo-nextest` | Test runner | | `cargo-deny` | License + advisory + duplicate-dep checks | | `cargo-machete` | Find unused dependencies |

  • Pin `rust-toolchain.toml` per repo so every contributor and CI uses the same compiler.
  • `cargo update -p <crate>` for single-package upgrades. `cargo update` rewrites everything — avoid in PR diffs.
  • `Cargo.lock` goes in version control for binaries *and* libraries (modern guidance; reproducibility wins).

Workspaces

Multi-crate projects use a workspace with layered crates. Dependencies point inward only.

Cargo.toml                  # [workspace] members + [workspace.dependencies]
crates/
  protocol/    # Shared types, no deps on other workspace crates
  storage/     # Persistence, depends on protocol
  service/    # Business logic, depends on protocol + storage
  cli/        # Binary, depends on everything
  • Centralize versions in `[workspace.dependencies]`, reference as `foo = { workspace = true }` in members.
  • Keep the leaf-most crate (`protocol` / types) dependency-free so every other crate can depend on it without cycles.
  • Feature flags belong on the crate that introduces the dependency, not re-exported through the workspace root.
  • **Library crates expose one stable facade**: a thin `lib.rs` with a `//!` purpose doc and `pub use` re-exports — one import path per concept, internals free to reorganize without breaking callers.
  • **`pub` alone does not prove an item is externally reachable.** Reachability runs through the re-export graph: a `pub` item inside a private module that is never re-exported is free to change, while the same item surfaced through a `pub use` at the crate root is not — even though its containing module stays private. (A `pub(crate)` item cannot be re-exported at all; `pub use` on one is `E0364`.) Trace the facade before calling a reorganization internal. On a library crate with a published baseline, `cargo semver-checks` settles it mechanically.
  • **Document public items at the point of exposure.** `///` on every public item (purpose, params, return, plus `# Examples` / `# Errors` / `# Panics` / `# Safety` where they apply); `//!` for modules and crates. Doc examples compile and run under `cargo test --doc`, so they are regression tests, not decoration. Enforce with `#![deny(missing_docs)]` on library crates; see [rustdoc.md](./references/rustdoc.md).
  • **Feature gates must error, never silently degrade.** If runtime config requests a capability the binary wasn't compiled with (e.g. `device = "gpu"` on a non-CUDA build), fail at startup — silent fallback diverges from operator config unnoticed.
  • **Centralize lints at the workspace root** with `[workspace.lints.*]` — every member crate inherits the same ruleset, no per-crate `#![deny(...)]` drift:
  [workspace.lints.clippy]
  all = { level = "warn", priority = -1 }
  pedantic = { level = "warn", priority = -1 }

Each member crate opts in with `[lints] workspace = true`.

Build Profiles

When tuning Cargo build profiles (release LTO, release-dbg symbols, release-min for distributable binaries) or adding dev-machine speedups (mold linker, `target-cpu=native`, share-generics), load [build-profiles.md](./references/build-profiles.md).

Error Handling

Split by crate role:

  • **Libraries / lower crates**: define typed errors with `thiserror`. Consumers can pattern-match.
  • **Binaries / top-level crates**: use `anyhow::Result` with `.context("what was being attempted")`. Human-readable error chains.
  • Never return `Box<dyn Error>` from library APIs — it erases variant information.
  • Use `?` liberally. Never `.unwrap()` or `.expect()` outside tests and `main`. An `expect("...")` is acceptable only when the invariant is provably upheld and the message explains why.
  • Convert at boundaries: `#[from]` on thiserror variants for auto-conversion; `.map_err(MyError::from)` when explicit.
  • `bail!("...")` / `ensure!(cond, "...")` in application code for early exits.
  • Prefer `Result<T, E>` over panics for any recoverable error. Panics are for programmer bugs (broken invariants), not runtime failures.
  • **`#[must_use]` on fallible APIs**: annotate functions returning `Result` or newtype-wrapped results that callers frequently ignore. Catches `let _ = validate(x);` at compile time instead of shipping a silently-dropped error.
  • **Make illegal call-sequences unrepresentable** — the type-state pattern: encode a mandatory call order as distinct types (`Client<Uninitialized>` → `Client<Connected>`) so an out-of-order call fails to compile instead of erroring at runtime.

Ownership Discipline

  • Take `&str` over `&String`, `&[T]` over `&Vec<T>` in function signatures — accepts more call sites for free.
  • Return owned (`String`, `Vec<T>`) from constructors and public APIs. Borrow in hot paths where lifetimes are obvious.
  • Reach for `Arc<T>` only when sharing across threads. Single-threaded sharing uses `Rc<T>` or references.
  • `Cow<'_, str>` when a function sometimes allocates and sometimes borrows (e.g. normalization).
  • Rely on lifetime elision. More than one signature needing an explicit `'a` is a signal the type should own its data — convert the borrow to owned before adding lifetimes.
  • Reducing hot-path allocations (SmallVec, ArrayVec, string interning, `B
Read more
Read it on GitHub ↗

Showing the first part of this file.

Ships withwhetstone

A Claude Code plugin that makes AI coding agents follow engineering discipline. Plan before coding. Verify before claiming done. Find root cause before patching. Review before merge. Skills activate based on file type and task signals, not manual toggling.

Get the whole plugin, auto-invoked
Stats
28
Stars
0
Views
2
Forks
Active
Maintenance
Python
Language
MIT
License
4d ago
Last commit
5mo ago
Created

Repo: iliaal/whetstone

Other skills on whetstone.