Google Rust Skills
A Google skill for Rust that writes and reviews Safety sections and unsafe comments as proofs grounded in the Rust Reference
- 72 ★ on the repository
- Last commit
- Apache-2.0
Minimal access
Why this level
- Instructions and reference rules: the skill runs nothing and makes no network calls
Install
- Works in
Manual install
Install the skill: clone https://github.com/google/rust-skills, copy the unsafe_rust_review folder into .claude/skills/ of this project and check that SKILL.md loads. Copy the experimental variant only if I ask.
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- Instructions and reference rules: the skill runs nothing and makes no network calls
This is third-party code. Review the repository files before installing.
What it does
The Rust Skills repository holds two skills for working with unsafe Rust. The main one, unsafe_rust_review, tells the agent to act as an extremely strict author and reviewer: every # Safety section is treated as a theorem and every safety comment as its proof. The skill requires stating the proposition, listing all assumptions, naming the source of each, showing that they imply the contract of the unsafe operation and describing the postconditions. The skill activates on any work with an unsafe surface: unsafe fn, unsafe trait, unsafe impl, unsafe extern blocks and similar. Inside are a hierarchy of sources of truth, a mandatory classification of facts, rules for documentation and for comments, a list of required proof topics, reject patterns, rules for dependencies and checklists for risky spots such as reference creation. Sections carry stable IDs like [doc] and [rej] that are cited instead of numbers. The second skill, unsafe_rust_review_experimental, is shorter and wider in scope: it covers designing and auditing unsafe code, raw pointers, FFI, inline assembly, atomics, SIMD, allocators and trusted computing base reviews.
Who it is for. Rust developers who write or review unsafe code and teams whose safety comments must withstand strict review.
Good fit when
- A public unsafe fn needs a # Safety section that reads as a set of checkable conditions
- An unsafe block in an FFI wrapper gets a safety comment listing assumptions and their sources
- A pull request with an unsafe impl is under review and weak, circular or unverifiable premises must be found
- Agent-generated code contains unsafe and is checked against hazard checklists
- A module contract changes while an invariant lives in struct fields: a proof audit is needed
Not a fit when
- The code is fully safe: the skill activates only where an unsafe surface exists
- You need general Rust style or optimization: the skill has a different goal, proofs for unsafe
- You need a quick skim: the main skill of 2,141 lines demands strict reasoning and works slowly
- You need rules for another language: the set is built for Rust only
Example request
Write a # Safety section for the read_unaligned_u32 function and safety comments for its unsafe blocks, then review them as a strict reviewerLimitations
- The skill is built for unsafe Rust and is not meant for safe code.
- The skill is large: the main SKILL.md runs 2,141 lines and the experimental one 364, so they consume a noticeable part of the context.
- It insists on strict sourcing from the Rust Reference, standard library documentation and contracts of trusted dependencies, and rejects guesswork.
- The unsafe_rust_review_experimental variant is marked experimental by the author.
- The README has no install commands: the skill folder is copied into the agent skills directory by hand.
- The license is Apache-2.0 and the last commit is from October 2026.
How to disable. The skill is removed by deleting the unsafe_rust_review or unsafe_rust_review_experimental folder from the agent skills directory, for example .claude/skills/. It leaves no other traces.
FAQ
What does the unsafe_rust_review skill do?
It teaches the agent to write and review # Safety sections and safety comments for unsafe code as formal proofs: a proposition, assumptions with sources, the derivation of the contract and postconditions.
When does the skill activate?
On any work with an unsafe surface: unsafe fn, unsafe trait, unsafe impl, unsafe extern, unsafe attributes and code that depends on such code.
How does the experimental variant differ?
It is shorter, 364 lines against 2,141, and wider in topics: design, audit, FFI, atomics, SIMD, allocators and trusted computing base reviews.
Which sources does the skill treat as authoritative?
The Rust Reference, standard library documentation, explicitly opted-in documented dependencies, type-system facts and local project invariants. It rejects folklore and circular premises.
How do I install the skill in Claude Code?
Copy the unsafe_rust_review folder into .claude/skills/ of the project or ~/.claude/skills/ for all projects. The README has no separate install command.
Discussion
No questions or reviews yet.
Related
Skills265 short Rust rules for an AI agent covering ownership, errors, async, unsafe and performance, each with a bad and a good code example
Three skills and a clippy config: an agent writes, reviews and ports idiomatic Rust, and CI enforces the checkable rules
A code review skill across many languages and frameworks: architecture, performance, security, anti-patterns and common bugs
Over 200 skills by stack and practice: React, Next.js, Rails, Rust, Python, debugging, TDD and UI review
kyy-logs code-review-skill
code-review-skill
A code review skill with four independent probes, evidence-backed findings and a merge gate derived from JSON
Guard skills for coding agents: a second pass over the diff that catches typical AI mistakes in code, tests and docs
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Google Rust Skills (this card) | yes | 72 | ||
| Beautiful Rust | no | 1,798 | a reference on Rust style and idioms with no unsafe safety proofs | |
| rust-docs-mcp | no | not required | 142 | an MCP server for Rust crate documentation that does not review unsafe |
README in short
The README is very short: it names the repository a collection of skills for working with Rust code, including a skill for unsafe review. The two SKILL.md files in the unsafe_rust_review and unsafe_rust_review_experimental folders carry all the weight. The repository also holds CONTRIBUTING.md and LICENSE.md.
README badge
Original SKILL.md
---
name: unsafe-rust-review
description: Write and review unsafe Rust `# Safety` documentation and safety comments (e.g., `// safety:` or `/// safety:` in any capitalization) as proof obligations grounded in the Rust Reference, standard library documentation, trusted opted-in dependency contracts, and explicit project invariants.
---
# Unsafe Rust Safety Documentation and Commenting Skill
## Mission
Act as an extremely strict unsafe Rust author and reviewer. Treat every `#
Safety` section as an English-language theorem or lemma, and every safety
comment (e.g., `// safety:` or `/// safety:` in any capitalization) as an
English-language proof.
The goal is not reassuring prose. The goal is logic bulletproof-ness. A reviewer
should be able to mechanically translate the prose into proof obligations and
check each obligation against authoritative Rust axioms, documented dependency
contracts, project-local invariants, type-system facts, and local code facts.
The governing standard is:
> Every unsafe boundary creates proof obligations, and every unsafe operation
> must locally prove that those obligations are discharged.
An `unsafe fn` or `unsafe trait` states extra conditions that callers or
implementers must satisfy. An `unsafe {}` block, `unsafe impl`, or unsafe
attribute use is the code author’s assertion that the relevant conditions have
been satisfied at that exact program point.
Unsafe documentation and comments must therefore be written in the style of
formal proof:
- Define the proposition being proved.
- Enumerate all required assumptions.
- Classify each assumption by source.
- Show that the assumptions imply the required unsafe contract.
- State the postconditions and state transitions caused by the unsafe
operation.
- Reject every implicit, circular, stale, unverifiable, or folklore premise.
## Conventions
Every section carries a stable `` `[area.slug]` `` ID after its heading. Cite
sections by ID, never by number or title: numbers shift when a list grows, and
titles get reworded. Areas: `model`, `evidence`, `fact`, `conv`