agentleFS
Sign inStart free
MesteriisMesteriis/Engineering-Bible-AI/skills/rust/SKILL.md

rust

Skill0 starsChanged 4 months agoMITView on GitHub

Applies Rust rules for ownership, modules, errors, unsafe code, concurrency, tests, and tooling.

We split this skill into the rules it gives an agent

24 rules. 0 are common, 15 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 30 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before changing Rust code, inspect relevant files when present:

    line 14
  2. Very specific:

    Prefer cargo nextest run over cargo test when cargo-nextest is installed and compatible with the workspace.

    line 36
  3. Very specific:

    Use bacon for local interactive feedback loops when available.

    line 38
  4. Very specific:

    Use cargo watch for focused watch commands when available and useful.

    line 39
  5. Distinctive:

    Do not introduce these tools as required project dependencies unless the user asks or the repository already standardizes on them.

    line 40
  6. Distinctive:

    Follow existing module organization.

    line 45
  7. Very specific:

    Avoid giant mod.rs or lib.rs files.

    line 47
  8. Very specific:

    Prefer explicit domain names over generic utils modules.

    line 48
  9. Distinctive:

    Keep public API surface intentionally small.

    line 49
  10. Distinctive:

    Prefer simple ownership over lifetime acrobatics.

    line 50
  11. Very specific:

    Use Result for recoverable failures.

    line 54
  12. Very specific:

    Do not unwrap or expect in production paths unless the invariant is proven and the message explains it.

    line 55
  13. Distinctive:

    Use the repository's established error type approach.

    line 58
  14. Very specific:

    Do not introduce anyhow, thiserror, or custom error stacks unless already used or justified.

    line 59
  15. Very specific:

    If unsafe is necessary, isolate it, document invariants, and test the safe wrapper.

    line 64
  16. Distinctive:

    Do not create undefined behavior for performance fantasies.

    line 65
  17. Distinctive:

    Prefer borrowing over cloning when simple.

    line 69
  18. Distinctive:

    Avoid exposing unnecessary concrete types in public APIs.

    line 71
  19. Distinctive:

    Use traits when they express real abstraction or test seams.

    line 72
  20. Distinctive:

    Do not create traits for one implementation unless boundary value is clear.

    line 73
  21. Distinctive:

    If async code is present:

    line 77
  22. Distinctive:

    avoid blocking calls in async tasks.

    line 80
  23. Distinctive:

    avoid detached tasks without lifecycle management.

    line 82
  24. Distinctive:

    use timeouts where external calls can hang.

    line 83

“Common” is measured: kept by at least 6 in 10 of the 30 edited versions of this file we could read. “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

Skill: rust

Purpose

Apply the shared engineering style to Rust projects while preserving idiomatic ownership, error handling, module structure, and safety.

Inspect First

Before changing Rust code, inspect relevant files when present:

  • Cargo.toml
  • Cargo.lock
  • .cargo/config.toml
  • rust-toolchain.toml
  • rustfmt.toml
  • clippy.toml
  • workspace layout
  • existing modules and tests

Infer:

  • edition;
  • workspace structure;
  • feature flags;
  • dependency policy;
  • error handling conventions;
  • async runtime if present.

Tooling Defaults

  • Prefer cargo nextest run over cargo test when cargo-nextest is installed and compatible with the workspace.
  • Use bacon for local interactive feedback loops when available.
  • Use cargo watch for focused watch commands when available and useful.
  • Do not introduce these tools as required project dependencies unless the user asks or the repository already standardizes on them.

Style

  • Follow existing module organization.
  • Keep modules cohesive.
  • Avoid giant mod.rs or lib.rs files.
  • Prefer explicit domain names over generic utils modules.
  • Keep public API surface intentionally small.
  • Prefer simple ownership over lifetime acrobatics.

Error Handling

  • Use Result for recoverable failures.
  • Do not unwrap or expect in production paths unless the invariant is proven and the message explains it.
  • In tests, unwrap/expect may be acceptable when failure context is clear.
  • Preserve error context.
  • Use the repository's established error type approach.
  • Do not introduce anyhow, thiserror, or custom error stacks unless already used or justified.

Safety

  • Avoid unsafe.
  • If unsafe is necessary, isolate it, document invariants, and test the safe wrapper.
  • Do not create undefined behavior for performance fantasies.

Ownership and APIs

  • Prefer borrowing over cloning when simple.
  • Clone intentionally when it improves clarity or avoids complex lifetimes.
  • Avoid exposing unnecessary concrete types in public APIs.
  • Use traits when they express real abstraction or test seams.
  • Do not create traits for one implementation unless boundary value is clear.

Async

If async code is present:

  • respect existing runtime;
  • avoid blocking calls in async tasks;
  • handle cancellation/drop behavior;
  • avoid detached tasks without lifecycle management;
  • use timeouts where external calls can hang.

Tests and Validation

Common commands, only when configured or clearly available:

cargo nextest run
cargo test
cargo test --workspace
cargo fmt --check
cargo clippy --workspace --all-targets --all-features
cargo check
bacon
cargo watch -x test

Report exact commands and results.

Shared Cross-Ecosystem Style

Apply the shared engineering style from:

  • ../../engineering/05_design_principles.md
  • ../../engineering/06_responsibility_model.md
  • ../../engineering/07_complexity_budget.md
  • ../../engineering/12_naming_bible.md

Language-specific idioms control syntax and ecosystem details, but they must not weaken the core rules: small cohesive units, explicit boundaries, honest validation, no dumping grounds, and no fake placeholders.

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.

Check your setup, free