agentsclimarketplace

Unsafe code review

Skill Amey-Thakur/AI-SKILLS/skills/systems-languages/unsafe-code-review

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill unsafe-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.4 KB, as published. Nobody here has run it

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

  1. 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).

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.