lvtd-llc/skills

rust-unsafe-boundaries

Isolate and review unsafe Rust behind small, documented, testable boundaries with explicit invariants.

First seen Jun 21, 2026

Installation

$ npx skills add lvtd-llc/skills --skill rust-unsafe-boundaries

Summary

  • Isolate and review unsafe Rust behind small, documented, testable boundaries with explicit invariants.
  • Use when writing, refactoring, or reviewing unsafe code, raw pointers, unsafe functions, unsafe traits, MaybeUninit, pointer aliasing, panic safety, Miri checks, or safe abstractions over unsafe internals.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from lvtd-llc/skills · top by installs.

npx skills add lvtd-llc/skills

Browse all from lvtd-llc/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Declared
Cursor Not declared
Codex Declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 1
License LICENSE
Default branch main
Open issues 0
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version0.1.0
LicenseMIT
CompatibilityCodex, Claude Code, and other Agent Skills-compatible clients.
Declared agents claude-code codex
More metadata
version
0.1.0
displayName
Rust Unsafe Boundaries
category
Rust
tags
rust,unsafe,raw-pointers,memory-safety,miri

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,126 B
  • docs SUMMARY.md 338 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 57 installs

SKILL.md

Rust Unsafe Boundaries

Use this skill to isolate unsafe Rust behind small, documented, testable boundaries. Unsafe code is acceptable only when a safe API cannot express the needed operation with acceptable correctness and performance.

Core Workflow

  1. Try the safe design first. Check standard APIs, ownership restructuring,

iterators, synchronization primitives, and existing crates.

  1. State the invariant that safe Rust cannot prove. If the invariant cannot be

written down, do not write unsafe code yet.

  1. Keep unsafe blocks tiny. Put runtime checks and setup in safe code before the

block.

  1. Add a // SAFETY: comment immediately before each unsafe block explaining

why every unsafe operation inside is valid.

  1. Mark a function unsafe fn only when callers must uphold extra conditions.

Document those conditions in a # Safety section.

  1. Enable or respect unsafeopinunsafefn; unsafe operations inside unsafe

functions should still be wrapped in explicit unsafe blocks.

  1. Test normal behavior, boundary cases, panic paths, and drop behavior. Run

Miri when the project supports it.

Boundary Rules

Read references/safety-invariants.md before adding or approving unsafe code.

  • Prefer private unsafe internals plus a safe public wrapper.
  • Prefer MaybeUninit<T> over deprecated or ad hoc uninitialized memory

patterns.

  • Never create references from raw pointers unless validity, alignment,

initialization, aliasing, and lifetime are all proven.

  • Do not use setlen, pointer arithmetic, or fromraw_parts without proving

capacity, initialization, and ownership.

  • Make panic safety explicit when partially initialized values, manual drops, or

length changes are involved.

  • Avoid static mut; prefer OnceLock, LazyLock, atomics, or locked state.

Documentation Pattern

/// # Safety
///
/// `ptr` must be non-null, aligned for `T`, initialized, and valid for reads
/// for the returned lifetime. No mutable reference may alias the same value.
pub unsafe fn read_ref<'a, T>(ptr: *const T) -> &'a T {
    // SAFETY: The caller guarantees `ptr` satisfies the documented contract.
    unsafe { &*ptr }
}

Review Checklist

  • Every unsafe block has a local SAFETY explanation.
  • Every unsafe fn or unsafe trait has a # Safety contract.
  • Public safe APIs cannot be used to violate internal invariants.
  • Drop, panic, and early-return paths preserve initialization and ownership.
  • Tests or Miri cover the dangerous edge, not only the happy path.