How do I install the Unsafe Code Review skill?

Run npx skillmds@latest add amey-thakur/unsafe-code-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Unsafe Code Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Unsafe Code Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Unsafe Code Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Unsafe Code Review?

Amey-Thakur (@amey-thakur) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Unsafe Code Review by amey-thakur — Agent Skill

Name: Unsafe Code Review
Author: Amey-Thakur

Unsafe Code Review

Audit unsafe blocks by verifying documented invariants, minimizing surface, and testing under sanitizers and Miri. Use when reviewing unsafe Rust, C/C++ interop shims, or any code that bypasses language safety.

Amey-Thakur 2b1a42f 3.4 KB Updated Sep 17, 2026

File contents

Unsafe code review

An unsafe block is a proof obligation transferred from the compiler to the author. The review's job is to check the proof: what invariant justifies this, is it written down, and does the safe wrapper make it impossible for callers to break.

Method

Demand the SAFETY comment before reading the code. Every unsafe block/fn carries a // SAFETY: comment stating the invariants relied on (non-null, aligned, initialized, unique access, valid for lifetime, in-bounds) and why they hold here. Missing comment: review stops; the author reconstructs the argument or discovers there is none. Vague comment ("this is fine"): same.
Shrink the unsafe surface first. The block should span the minimal expressions needing it, wrapped in a safe API whose type signature makes misuse unrepresentable (slices carry bounds, newtypes carry validity; see api-surface-minimalism). Reject unsafe spread through business logic: the module boundary is where safety gets re-established, and everything outside it must be un-crashable no matter what callers do.
Check the classic holes systematically. Bounds and alignment on raw pointer arithmetic; lifetime laundering (transmute, pointer-to-reference casts outliving the source); aliasing violations (constructing &mut while & lives; Stacked-Borrows territory); uninitialized memory (MaybeUninit misuse); panic safety (an unwind mid-invariant leaving corrupted state); Send/Sync impls asserted without a threading argument (see race-conditions).
Verify FFI contracts on both sides. Signatures match the C header exactly (types, ownership, who frees; see ffi-boundaries), error codes translated, callbacks' unwind behavior contained (panic across FFI is UB: catch at the boundary). The foreign library's documented preconditions join the SAFETY comment.
Test with the UB-detecting tools, in CI. Miri on the unsafe modules' test suite (catches UB tests "pass" through), ASan/TSan builds where Miri cannot reach (FFI, threads; see c-memory-safety), and fuzzing on any unsafe parser surface (see fuzz-testing). A sanitizer-clean run is evidence, not proof; the written invariant argument remains the primary artifact.
Gate merges on justification, not cleverness. The PR states why safe alternatives fail (measured performance, FFI necessity, a primitive the std lacks); "faster, probably" gets a benchmark or a rejection (see benchmark-design). Track unsafe blocks in an inventory (grep-able, #[deny(unsafe_op_in_unsafe_fn)], cargo-geiger-style reports) so the surface trends down, not up.

Boundaries

This review assures memory/UB safety, not logical correctness or security of the design (see security-code-review for that lens).
Miri and sanitizers explore executed paths only; invariants depending on untested configurations (feature flags, targets) need per-configuration runs or stronger static argument.
Rewriting a hot unsafe module in safe code with 3% cost is usually the better review outcome than perfecting the proof; recommend it when the numbers allow (see rewrite-vs-refactor).

---name: unsafe-code-reviewdescription: Audit unsafe blocks by verifying documented invariants, minimizing surface, and testing under sanitizers and Miri. Use when reviewing unsafe Rust, C/C++ interop shims, or any code that bypasses language safety.---# Unsafe code reviewAn unsafe block is a proof obligation transferred from the compiler tothe author. The review's job is to check the proof: what invariantjustifies this, is it written down, and does the safe wrapper make itimpossible for callers to break.## Method1. **Demand the SAFETY comment before reading the code.** Every `unsafe` block/fn carries a `// SAFETY:` comment stating the invariants relied on (non-null, aligned, initialized, unique access, valid for lifetime, in-bounds) and why they hold *here*. Missing comment: review stops; the author reconstructs the argument or discovers there is none. Vague comment ("this is fine"): same.2. **Shrink the unsafe surface first.** The block should span the minimal expressions needing it, wrapped in a safe API whose type signature makes misuse unrepresentable (slices carry bounds, newtypes carry validity; see api-surface-minimalism). Reject unsafe spread through business logic: the module boundary is where safety gets re-established, and everything outside it must be un-crashable no matter what callers do.3. **Check the classic holes systematically.** Bounds and alignment on raw pointer arithmetic; lifetime laundering (`transmute`, pointer-to-reference casts outliving the source); aliasing violations (constructing `&mut` while `&` lives; Stacked-Borrows territory); uninitialized memory (`MaybeUninit` misuse); panic safety (an unwind mid-invariant leaving corrupted state); Send/Sync impls asserted without a threading argument (see race-conditions).4. **Verify FFI contracts on both sides.** Signatures match the C header exactly (types, ownership, who frees; see ffi-boundaries), error codes translated, callbacks' unwind behavior contained (panic across FFI is UB: catch at the boundary). The foreign library's documented preconditions join the SAFETY comment.5. **Test with the UB-detecting tools, in CI.** Miri on the unsafe modules' test suite (catches UB tests "pass" through), ASan/TSan builds where Miri cannot reach (FFI, threads; see c-memory-safety), and fuzzing on any unsafe parser surface (see fuzz-testing). A sanitizer-clean run is evidence, not proof; the written invariant argument remains the primary artifact.6. **Gate merges on justification, not cleverness.** The PR states why safe alternatives fail (measured performance, FFI necessity, a primitive the std lacks); "faster, probably" gets a benchmark or a rejection (see benchmark-design). Track unsafe blocks in an inventory (grep-able, `#[deny(unsafe_op_in_unsafe_fn)]`, cargo-geiger-style reports) so the surface trends down, not up.## Boundaries- This review assures memory/UB safety, not logical correctness or security of the design (see security-code-review for that lens).- Miri and sanitizers explore executed paths only; invariants depending on untested configurations (feature flags, targets) need per-configuration runs or stronger static argument.- Rewriting a hot unsafe module in safe code with 3% cost is usually the better review outcome than perfecting the proof; recommend it when the numbers allow (see rewrite-vs-refactor).

Frequently asked questions