BeautifulRust: Agent Skills and a Clippy Config That Make AI Write Idiomatic Rust

Morgan Linton's open-source repository BeautifulRust, which bundles three Agent Skills for writing, reviewing and porting Rust plus a tested clippy lint configuration, reached about 1,200 GitHub stars and 56 forks within days of launch. The MIT-licensed repo works with Claude Code, Codex, Copilot, Cursor and Gemini CLI, and its lints flag issues including unwrap() outside tests, unsafe blocks lacking a // SAFETY: comment, and bool function parameters. The README's benchmark claims come from the maintainer's own evals and are not independently proven.

BeautifulRust is a small repository that tries to fix a familiar problem: coding agents write Rust that compiles but reads like translated Python. It bundles three Agent Skills https://explainx.ai/blog/what-are-agent-skills-complete-guide one to write Rust, one to review it, one to port other languages and a clippy lint configuration, and it picked up about 1,200 GitHub stars in the days after launch. It is MIT licensed and, according to its README https://github.com/morganlinton/BeautifulRust?ref=explainx , works with Claude Code, Codex, Copilot, Cursor and Gemini CLI. This post explains what is in the repo, how to install it, what the clippy rules enforce, and how much weight to give the evaluation numbers the author publishes. TL;DR: what readers ask first | Question | Short answer | |---|---| | What is it? | Three Agent Skills plus a tested clippy config for Rust | | Who made it? | Morgan Linton, as an open repository about 1.2k stars, 56 forks, 15 commits at the time of writing | | License? | MIT for the repo's own text, digests and scripts; the underlying style guides keep their own licenses | | Does it need API keys? | No. Skills are plain instruction files your agent loads; only the optional evals make billed model calls | | Works with which agents? | Claude Code, Codex, Copilot, Cursor, Gemini CLI and anything that reads the Agent Skills format | | Are the benchmark claims proven? | No. They come from the maintainer's own evals | What is inside BeautifulRust? The repository has four parts, per the README. skills/ holds three skill folders, each with a SKILL.md and an evals/ directory. The rust-best-practices skill also ships a references/ folder of paraphrased digests. lints/ holds lints.toml , clippy.toml and a small check/ crate used to confirm every lint actually fires. scripts/ contains check-skill.py and check-lints.sh , which validate the skills and the lints. examples/ includes a sample review report so you can see the output format before installing anything. The guidance is a synthesis of five public sources: the Google Rust Style Guide, the Rust API Guidelines, Effective Rust by David Drysdale, Rust Design Patterns, and Microsoft's Pragmatic Rust Guidelines. The README says it bundles paraphrased digests rather than copying text, which matters because those sources carry different licenses Effective Rust is CC BY-NC-ND, for example . The three skills rust-best-practices: the write-time skill This one loads when an agent writes or changes Rust and nudges it toward idiomatic patterns. It is the always-on layer: the point is that the agent consults the digests before it produces an unwrap -heavy first draft, not after. rust-review: a prioritized report Point it at a file, a crate or a diff and it writes a report grouped as must fix, should fix and consider. Each finding cites the rule behind it and includes a fix. That structure is the useful part: a review that names its rule is easier to argue with, and easier to turn into a lint later. rust-port: migrating from C, C++, Python, Go or JavaScript The porting skill ports the original tests first, then the code, and produces a PORTING.md documenting decisions. Test-first porting is a sound habit for any migration, and it fits the pattern we described in GitHub Copilot's Rust migration https://explainx.ai/blog/github-copilot-runtime-rust-migration-2026 , where the hard part is proving the new code behaves like the old. The clippy config: guardrails the agent cannot talk its way past Skills are suggestions an agent can ignore. A lint config is a gate. The lints/ folder is a drop-in set that, per the README, flags: - unwrap outside tests - unsafe blocks without a // SAFETY: comment - allow attributes without a reason - bool function parameters - silent lossy as casts - missing Errors and Panics documentation sections - leftover dbg and unfinished-code macros To use it, copy lints/clippy.toml next to your Cargo.toml , paste the lints block from lints/lints.toml into the manifest, and run: cargo clippy --all-targets --all-features -- -D warnings Some lints are marked lib and can be dropped for applications, and the allow attributes lints need rust-version = "1.81" or later. scripts/check-lints.sh runs the config against the lints/check/ crate to verify each rule fires, which is a nice touch: a lint config nobody has tested can silently do nothing. The combination is the real idea. The skill makes the agent less likely to write unwrap ; the lint makes the build fail if it does anyway. This is the same two-layer thinking behind most agent guardrails, and it echoes what we covered in i-have-adhd https://explainx.ai/blog/i-have-adhd-skill-action-first-ai-coding-agents-2026 : a skill shapes behavior, but only a hard check enforces it. How to install it The README documents several routes. | Agent | Command | |---|---| | Any agent | npx skills add morganlinton/BeautifulRust Node 22.20 or newer; -g for user-level, -a codex to target one agent | | Claude Code plugin | claude plugin install beautiful-rust --marketplace morganlinton/BeautifulRust | | Claude Code in session | /plugin marketplace add morganlinton/BeautifulRust , then /plugin install beautiful-rust@beautiful-rust | | GitHub Copilot | gh skill install morganlinton/BeautifulRust <skill-name GitHub CLI 2.90 or newer , once per skill | | Gemini CLI | gemini skills install https://github.com/morganlinton/BeautifulRust --path skills/<skill-name | | Codex, Cursor, others | Clone the repo and copy the skills/rust- folders into ~/.agents/skills/ | | claude.ai | Zip each skill folder and upload it under Customize, then Skills code execution must be on | Two gotchas from the README: Claude Code does not read ~/.agents/skills/ , so use the plugin route there, and you may need to restart the agent before a new skill shows up. A quick first test: install it, then ask your agent to "review the diff on this branch with rust-review" and compare the report to what your human reviewer would flag. If the findings are mostly things clippy would already catch, the lint config alone may be enough for you. What do the eval numbers actually show? The README reports results from the maintainer's own evals: | Skill | With the skill | Without | |---|---|---| | Writing | 29 of 30 assertions passed | 24 of 30 | | Review | 11 of 12 | 7 of 12 | | Porting | 22 of 22 | 19 of 22 | The README adds that the writing skill used roughly a third more tokens. Read these carefully. They are small samples 12 to 30 assertions , graded by the same person who wrote the skills, and we have not seen an independent reproduction. A five-assertion gap on 30 can be real or noise. The direction is plausible, since a skill that tells a model the rules should improve rule-following, but this is a claim from the author, not a verified benchmark. The sensible reading is: promising, cheap to try, not proven. The token cost is worth noting on its own. Skills load into context, and a third more tokens on a writing task adds up across a long session. If you are watching spend, our Claude Code token efficiency guide https://explainx.ai/blog/claude-code-token-efficiency-prompt-cache-sessions-guide-2026 covers how prompt caching changes that math. A practical rollout plan for a team Adopting this on a shared codebase goes better in steps than in one pull request. 1. Baseline first. Run cargo clippy --all-targets --all-features -- -D warnings with the new config on your main branch and record the count of failures per lint. Expect noise from unwrap and missing Errors sections in older code. 2. Scope the gate. Enforce the lints on new and changed files only, using a CI step that diffs against the base branch. Legacy debt then stays visible without blocking every merge. 3. Install the skills per developer, not in CI. Skills guide the agent while it writes. CI should only run the deterministic checks. 4. Review the reviewer. For two weeks, run rust-review on pull requests next to your human review and note which findings the humans also raised. Keep the rules that earn their place and delete the ones that generate arguments. 5. Re-measure. Count lint failures on agent-authored commits before and after the skills. That is the one number that tells you whether the skills help your codebase, and it needs no external benchmark. This mirrors how teams roll out any style tool: start with measurement, enforce narrowly, and let the data decide which rules stay. The official Agent Skills specification https://agentskills.io/?ref=explainx describes how skills are discovered and loaded, which helps when you debug why a skill did not trigger for a given prompt. Where it fits among language-specific skill packs BeautifulRust follows a pattern we have seen before: a language or platform community packaging its house style as skills. Microsoft's dotnet-skills repository https://explainx.ai/blog/dotnet-skills-ai-agents-complete-guide-2026 does this for .NET, and community packs now exist for many stacks. What distinguishes BeautifulRust is the paired lint config and the test crate that proves the lints fire. Most skill packs stop at prose. It is also a close cousin of persona-style skill collections such as founder-skill https://explainx.ai/blog/founder-skill-eleven-claude-skills-100-buyer-agents-cfo-board-hormozi-thiel-jobs-claims-vs-readme-2026 , but aimed at a concrete, checkable engineering task rather than a simulated advisory panel. Checkable is the key word: Rust's compiler and clippy give you ground truth that most skill domains lack. Limitations and open questions - Self-reported evals. See above. Run your own before you rely on the numbers. - Opinionated rules. Banning unwrap outside tests and bool parameters is a style choice. Application code and library code differ, which is why some lints are tagged lib . - Version requirements. Node 22.20 or newer for the npx route, GitHub CLI 2.90 or newer for Copilot, and Rust 1.81 or newer for the allow attributes lints. - Maturity. Fifteen commits and a young repository mean rules will move. Pin a commit if you need stability. - Eval cost. Running the repo's evals makes real, billed model calls. - Licensing of sources. The repo's own content is MIT, but it digests material under other licenses. If you redistribute it inside a product, read the README's source list first. Should you install it? If you already use an agent for Rust, yes: the clippy config alone is worth ten minutes, and the skills cost nothing to try. Install the lints first, see how many warnings your agent's last commit produces, then add the skills and check whether that number drops. That before-and-after on your own code is a better benchmark than any README table. If you work in another language, the useful lesson transfers: pair a skill with a deterministic check, and measure the difference yourself. Related reading Details such as star counts, version requirements and install commands are accurate as of October 27, 2026 and may change as the repository evolves.