morganlinton/BeautifulRust

If you already use a coding agent for Rust work and keep correcting its API shape, error handling, and doc examples, this skill is worth a test run. It does not add tooling; it changes the instructions the agent sees when a Rust task appears.

The problem

A developer asks an agent for a small Rust library. The result compiles, but exports public fields, calls unwrap() inside doc examples, and never documents failure modes. Each fix becomes a manual review cycle, and the same corrections recur on the next crate. Beautiful Rust installs a skill that agents load automatically when a task mentions Rust, cargo, crates, the borrow checker, clippy, or .rs files, so style guidance arrives before the code is drafted. The result, per the README's own before-and-after excerpt, is private fields with accessors, an # Errors section, and examples that propagate rather than panic.

What's different

This is a condensed style guide written for an agent to scan, not a linter. Roughly 500 lines cover ownership, type and API design, Option/Result/panic policy, async and Send concerns, unsafe and SAFETY: comments, feature and semver hygiene, docs, tests, and a pre-handback checklist of fmt, clippy with -D warnings, tests, and docs. Behind it sit paraphrased digests of the Google Rust Style Guide, the Rust API Guidelines, Effective Rust, Rust Design Patterns, and Microsoft's Pragmatic Rust Guidelines. When sources conflict, the skill picks a side and states why, which is the useful part for an agent that otherwise averages contradictory advice.

The trade-off is that this is prompt guidance, not enforcement. It cannot block a bad commit, and its advice is only as good as the agent's compliance. The included three-task evaluation gives a concrete signal: 29 of 30 assertions passed with the skill against 24 of 30 without, at roughly a third more tokens per task. Those numbers come from the maintainer's own eval setup and its stated good-result descriptions, so treat them as directional rather than independent proof.

The repository also bundles the five source digests so the agent can consult the original reasoning, but the author describes these as condensed paraphrases written for this project, not verbatim copies. If your team's Rust conventions diverge from these five sources, you are adopting someone else's consensus.

Who should try it

Good fit: a developer using Claude Code, Codex, Copilot, Cursor, or Gemini CLI on Rust libraries and applications who wants fewer review comments about API surface, error types, and documentation. It is especially relevant if you work across multiple agents, since the same skill folder is installable in each. Less fitting if you maintain a narrow internal style guide already encoded in lints or clippy configuration, or if you want deterministic enforcement in CI; a skill influences generated code but does not replace compiler and lint gates.

Setup varies by host. There is a one-command skills installer for many agents, a Claude Code plugin path, a GitHub CLI path, a Gemini CLI path, and a plain folder copy into each agent's skills directory. That means the project is not tied to Claude Code, although the eval harness referenced in the README is claude plugin eval.

Requirements and limitations

The skill follows the Agent Skills format, so it requires a host that reads that format and a skills directory it recognizes. The installer route needs Node 22.20 or later; the GitHub Copilot route needs GitHub CLI 2.90 or later. If you copy the folder manually, note that Claude Code does not read the shared .agents/skills/ location and needs its own directory or the plugin. Restart the agent if the skill does not appear.

Running the bundled evals is a real, billed model run, and the agent needs Write, Edit, and Bash tools to perform the tasks. Ongoing upkeep is manual: edit the skill, bump the version in the plugin manifest, commit, and then plugin users update while folder copiers reinstall. The project is MIT licensed, but the bundled Effective Rust digest rests on a CC BY-NC-ND source, so redistribution questions around derived digests are worth checking before republishing.

HotRepo's take

HotRepo first recorded the project at age 2 on 2026-10-25, listing 302 total stars and #21 on the NEW-REPOSITORY board for Python: a single dated snapshot, not a daily growth measurement. With only that observation, persistence cannot be judged. Before adopting, read the evaluation assertions and confirm whether their definition of a good result matches your team's Rust conventions.