Unsafe Checker
Review and harden Rust unsafe blocks and raw-pointer APIs against a structured rule catalog before merge or release.
Overview
Unsafe Checker is an agent skill most often used in Ship (also Build backend review) that audits Rust unsafe code against categorized P/G rules from rules/**.
Install
npx skills add https://github.com/actionbook/rust-skills --skill unsafe-checkerWhat is this skill?
- Rule tables auto-generated from rules/** with IDs, levels (P/G), and titled checks
- 3 General Principles rules on when not to abuse unsafe for safety escape or blind performance
- 11 Safety Abstraction rules including SAFETY comments, panic/double-free, and public API exposure
- 6 Raw Pointers rules covering NonNull, PhantomData, and cross-thread sharing
- Enforces assert! over debug_assert! inside unsafe functions per safety-11
- 6 Raw Pointers rules in the quick-reference tables
Adoption & trust: 909 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You added unsafe Rust for performance or FFI but lack a consistent checklist for invariants, docs, pointers, and panic safety.
Who is it for?
Rust maintainers shipping libraries or systems code with unsafe blocks who want rule-ID traceable reviews in the agent.
Skip if: Pure safe-Rust application code with no unsafe, or teams that already run formal Miri/policy gates without agent assistance.
When should I use this skill?
Auditing or authoring Rust unsafe code, raw pointers, public unsafe APIs, or manual auto trait implementations.
What do I get? / Deliverables
Reviews map changes to rule IDs (general, safety, ptr) with required SAFETY comments and API boundaries before you merge or release the crate.
- Rule-ID mapped review notes for unsafe changes
- SAFETY comment and docs-section recommendations per safety-09 and safety-10
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Unsafe Rust review is a quality gate most often run while shipping code that already uses low-level patterns. The skill is a checker against documented rules—canonical shelf is code review during Ship.
Where it fits
Draft a public unsafe helper and ask the agent to apply safety-09 SAFETY comments and safety-06 pointer exposure rules before opening a PR.
Run a pre-merge pass mapping each new unsafe block to general-01 and safety-02 invariant verification.
Audit FFI boundaries for ptr-01 thread sharing and safety-03 uninitialized memory in outward-facing structs.
How it compares
Use as a procedural rule checklist alongside the compiler and Miri—not as a substitute for running tests and Miri on unsafe paths.
Common Questions / FAQ
Who is unsafe-checker for?
Solo and indie Rust developers who write or review unsafe, FFI, or performance-critical low-level APIs and want structured rule coverage.
When should I use unsafe-checker?
During Ship review before merging unsafe changes, and during Build when drafting public unsafe functions or raw-pointer wrappers.
Is unsafe-checker safe to install?
Check the Security Audits panel on this Prism page and your org’s skill policy; the skill guides review and does not replace human verification of safety proofs.
SKILL.md
READMESKILL.md - Unsafe Checker
# Unsafe Checker - Quick Reference **Auto-generated from rules/** ## Rule Summary by Section ### General Principles (3 rules) | ID | Level | Title | |----|-------|-------| | general-01 | P | Do Not Abuse Unsafe to Escape Compiler Safety Checks | | general-02 | P | Do Not Blindly Use Unsafe for Performance | | general-03 | G | Do Not Create Aliases for Types/Methods Named "Unsafe" | ### Safety Abstraction (11 rules) | ID | Level | Title | |----|-------|-------| | safety-01 | P | Be Aware of Memory Safety Issues from Panics | | safety-02 | P | Unsafe Code Authors Must Verify Safety Invariants | | safety-03 | P | Do Not Expose Uninitialized Memory in Public APIs | | safety-04 | P | Avoid Double-Free from Panic Safety Issues | | safety-05 | P | Consider Safety When Manually Implementing Auto Traits | | safety-06 | P | Do Not Expose Raw Pointers in Public APIs | | safety-07 | P | Provide Unsafe Counterparts for Performance Alongside Safe Methods | | safety-08 | P | Mutable Return from Immutable Parameter is Wrong | | safety-09 | P | Add SAFETY Comment Before Any Unsafe Block | | safety-10 | G | Add Safety Section in Docs for Public Unsafe Functions | | safety-11 | G | Use assert! Instead of debug_assert! in Unsafe Functions | ### Raw Pointers (6 rules) | ID | Level | Title | |----|-------|-------| | ptr-01 | P | Do Not Share Raw Pointers Across Threads | | ptr-02 | P | Prefer NonNull<T> Over *mut T | | ptr-03 | P | Use PhantomData<T> for Variance and Ownership | | ptr-04 | G | Do Not Dereference Pointers Cast to Misaligned Types | | ptr-05 | G | Do Not Manually Convert Immutable Pointer to Mutable | | ptr-06 | G | Prefer pointer::cast Over `as` for Pointer Casting | ### Union (2 rules) | ID | Level | Title | |----|-------|-------| | union-01 | P | Avoid Union Except for C Interop | | union-02 | P | Do Not Use Union Variants Across Different Lifetimes | ### Memory Layout (6 rules) | ID | Level | Title | |----|-------|-------| | mem-01 | P | Choose Appropriate Data Layout for Struct/Tuple/Enum | | mem-02 | P | Do Not Modify Memory Variables of Other Processes | | mem-03 | P | Do Not Let String/Vec Auto-Drop Other Process's Memory | | mem-04 | P | Prefer Reentrant Versions of C-API or Syscalls | | mem-05 | P | Use Third-Party Crates for Bitfields | | mem-06 | G | Use MaybeUninit<T> for Uninitialized Memory | ### FFI (18 rules) | ID | Level | Title | |----|-------|-------| | ffi-01 | P | Avoid Passing Strings Directly to C | | ffi-02 | P | Read Documentation Carefully for std::ffi Types | | ffi-03 | P | Implement Drop for Wrapped C Pointers | | ffi-04 | P | Handle Panics When Crossing FFI Boundaries | | ffi-05 | P | Use Portable Type Aliases from std or libc | | ffi-06 | P | Ensure C-ABI String Compatibility | | ffi-07 | P | Do Not Implement Drop for Types Passed to External Code | | ffi-08 | P | Handle Errors Properly in FFI | | ffi-09 | P | Use References Instead of Raw Pointers in Safe Wrappers | | ffi-10 | P | Exported Functions Must Be Thread-Safe | | ffi-11 | P | Be Careful with repr(packed) Field References | | ffi-12 | P | Document Invariant Assumptions for C Parameters | | ffi-13 | P | Ensure Consistent Data Layout for Custom Types | | ffi-14 | P | Types in FFI Should Have Stable Layout | | ffi-15 | P | Validate Non-Robust External Values | | ffi-16 | P | Separate Data and Code for Closures to C | | ffi-17 | P | Use Opaque Types Instead of c_void | | ffi-18 | P | Avoid Passing Trait Objects to C | ### I/O Safety (1 rule) | ID | Level | Title | |----|-------|-------| | io-01 | P | Ensure I/O Safety When Using Raw Handles | ## Clippy Lint Mapping | Clippy Lint | Rule | Category | |-------------|------|----------| | `undocumented_unsafe_blocks` | safety-09 | SAFETY comments | | `missing_safety_doc` | safety-10 | Safety docs | | `panic_in_result_fn` | safety-01, ffi-04 | Panic safety | | `non_send_fields_in_send_ty` | safety-05 | Send/Sync | | `uninit_assumed_init` | safety-03 | Initialization | | `uninit_vec` | mem-06