agentleFS
leaf76leaf76/agent-skills/rust-programmer/SKILL.md

rust-programmer

Skill0 starsChanged 3 months agoMITView on GitHub

Write, refactor, and debug Rust (.rs) code and Cargo projects using idiomatic patterns, safe error handling, ownership/lifetimes guidance, async/concurrency best practices, and a standard verification routine (fmt/clippy/test). Use when tasks involve Rust source files, Cargo.toml workspaces, Rust API design, or Rust performance/safety reviews.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 9 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read Cargo.toml (features, workspace members, lints, edition).

    line 20
  2. Distinctive:

    Follow the current patterns (error types, logging/tracing, async runtime).

    line 21
  3. Distinctive:

    Use strongly typed data; avoid “stringly typed” APIs.

    line 25
  4. Distinctive:

    Prefer ownership at boundaries and borrowing internally.

    line 26
  5. Very specific:

    If async: avoid blocking calls in async contexts.

    line 30
  6. Distinctive:

    Add deterministic unit tests for pure logic.

    line 33
  7. Distinctive:

    Add integration tests for public API and IO boundaries.

    line 34
  8. Distinctive:

    Avoid timing-dependent tests unless required.

    line 35
  9. Distinctive:

    Prefer iterators, pattern matching, and small focused functions.

    line 38
  10. Very specific:

    Avoid unwrap/expect outside tests unless the invariant is proven and documented.

    line 39
  11. Very specific:

    Avoid unsafe unless necessary.

    line 40
  12. Distinctive:

    Run the standard checks (fast → slow):

    line 43
  13. Very specific:

    If useful, run the bundled script: scripts/cargo_verify.sh.

    line 48
  14. Distinctive:

    Call out compatibility risk if public APIs or features change.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Rust Programmer

Goal: produce idiomatic, safe, and testable Rust with a repeatable verification loop.

Workflow

1) Clarify requirements

  • Confirm crate type: library vs binary.
  • Confirm runtime: sync vs async (Tokio or not).
  • Confirm MSRV/toolchain constraints and target platforms.
  • Confirm error strategy (public error type vs opaque errors).
  • Identify public API surface and backwards-compat expectations.

2) Inspect the existing crate/workspace

  • Read Cargo.toml (features, workspace members, lints, edition).
  • Follow the current patterns (error types, logging/tracing, async runtime).
  • Locate critical paths via rg and call sites (avoid introducing a new style).

3) Design before coding

  • Use strongly typed data; avoid “stringly typed” APIs.
  • Prefer ownership at boundaries and borrowing internally.
  • Pick an error model:
    • Library: thiserror + a stable error enum.
    • Binary/CLI: anyhow + Context at boundaries.
  • If async: avoid blocking calls in async contexts; use spawn_blocking for CPU/IO-bound sync work.

4) TDD (required for behavior changes)

  • Add deterministic unit tests for pure logic.
  • Add integration tests for public API and IO boundaries.
  • Avoid timing-dependent tests unless required; keep retries bounded and explicit.

5) Implement (idiomatic + minimal diff)

  • Prefer iterators, pattern matching, and small focused functions.
  • Avoid unwrap/expect outside tests unless the invariant is proven and documented.
  • Avoid unsafe unless necessary; document invariants and add coverage.

6) Verify

Run the standard checks (fast → slow):

  • cargo fmt --all -- --check
  • cargo clippy --all-targets --all-features -- -D warnings (or match repo policy)
  • cargo test --all --all-features

If useful, run the bundled script: scripts/cargo_verify.sh.

Output expectations

  • State assumptions (toolchain, crate type, runtime).
  • Summarize what changed and why.
  • List verification (commands, tests).
  • Call out compatibility risk if public APIs or features change.

Resources

  • scripts/cargo_verify.sh: standard local verification runner.
  • references/rust-playbook.md: deeper patterns and decision notes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.