Home / Agent Skills

RUST AGENT SKILLS : 2026 SYSTEMS SUITE

Hardened Rust Skills for AI Coding Agents

Generic language models generate Rust code that compiles cleanly but causes catastrophic runtime degradation: threadpool starvation, lock contention across await points, silent cancellation drops, and multi-gigabyte buffer cloning across Python FFI boundaries.

These production-grade skills inject static AST guards, GIL-releasing contracts, and memory-layout verification directly into Antigravity, Claude Code, and Cursor.

Target Ecosystem

Tokio & PyO3

✓ Async & FFI Interop

Compatibility

Triple Agent Harness

Antigravity · Claude · Cursor

Quality Standard

Zero Clichés

Verified Systems AST Lints

Distribution

1-Click Local Deploy

CLI Scripts & Clippy Configs

Async Runtime Guard Async Concurrency v1.0.0

tokio-safety-auditor

Antigravity Claude Code Cursor

Static AST and heuristic auditor for Tokio asynchronous Rust. Eliminates worker thread starvation, cross-await Mutex deadlocks, and select! cancellation safety data loss.

⚠ Why Generic Agents Fail

✕ Generic LLMs frequently call std::fs::read or std::thread::sleep inside async fn, freezing Tokio worker threads and destroying system throughput.
✕ Models use std::sync::Mutex across .await points, violating the Send trait or causing deadlocks under high concurrency.
✕ AI code generators naively use AsyncReadExt::read in tokio::select! branches, permanently discarding unconsumed stream bytes on branch cancellation.
✕ Failure to bind or offload CPU-intensive serialization (>100µs) to spawn_blocking, leading to unexplainable p99 latency spikes.

🛡 Guardrails Enforced by Skill

✓ Strict prohibition of std::fs and std::thread::sleep inside async contexts; mandatory replacement with tokio::fs and tokio::time.
✓ Scoped mutex guard dropping before await boundaries, or migration to tokio::sync::Mutex when lock spanning is required.
✓ Cancellation-safe stream handling using tokio_util::codec::FramedRead or pinned stream futures outside select! loops.
✓ Automated delegation of heavy computational workloads to tokio::task::spawn_blocking with Semaphore concurrency bounds.

1-Click Installation Setup

Download SKILL.md

For Antigravity Agent:

agy skill install https://github.com/rustinfrajobs/skills/tree/main/skills/tokio-safety-auditor

For Claude Code (CLAUDE.md / .claude/rules):

curl -sSL https://rustinfrajobs.com/skills/tokio-safety-auditor/SKILL.md >> .claude/rules/tokio-safety.md

For Cursor (.cursor/rules):

mkdir -p .cursor/rules && curl -sSL https://rustinfrajobs.com/skills/tokio-safety-auditor/SKILL.md -o .cursor/rules/tokio-safety.mdc

Engineering Case Comparisons

Case 1: Synchronous Filesystem I/O vs Tokio Non-blocking Async I/O

✕ Naive Agent Output (Vulnerable)

// [FAULT] Freezes Tokio worker thread
pub async fn read_config(path: &Path) -> Result<Config, Error> {
    let raw = std::fs::read_to_string(path)?; // Blocks executor OS thread!
    let cfg = serde_json::from_str(&raw)?;
    Ok(cfg)
}

✓ Hardened Skill Output (Production Safe)

// [SAFE] Non-blocking cooperative async I/O
pub async fn read_config(path: &Path) -> Result<Config, Error> {
    let raw = tokio::fs::read_to_string(path).await?;
    let cfg = serde_json::from_str(&raw)?;
    Ok(cfg)
}

System Mechanism: Tokio schedules tasks onto an M:N thread pool matching physical CPU cores. A synchronous blocking call halts the entire worker thread, pausing all co-scheduled tasks and inflating tail latency.

Case 2: std::sync::Mutex Held Across Await vs Scoped Lock Dropping

✕ Naive Agent Output (Vulnerable)

// [FAULT] MutexGuard held across await point
pub async fn update_state(state: &std::sync::Mutex<State>, client: &ApiClient) {
    let mut lock = state.lock().unwrap();
    let payload = client.fetch().await; // Lock held while awaiting network IO!
    lock.records.push(payload);
}

✓ Hardened Skill Output (Production Safe)

// [SAFE] Lock acquired strictly after await point
pub async fn update_state(state: &std::sync::Mutex<State>, client: &ApiClient) {
    let payload = client.fetch().await; // Network IO resolved outside critical section
    {
        let mut lock = state.lock().unwrap();
        lock.records.push(payload);
    } // Guard dropped immediately
}

System Mechanism: Holding a synchronous MutexGuard across an .await boundary causes lock starvation. If another thread needs the lock to complete the awaited task, deadlock is guaranteed.

Case 3: tokio::select! Partial Read Loss vs Framed Stream Decoding

✕ Naive Agent Output (Vulnerable)

// [FAULT] Data loss on cancellation
loop {
    tokio::select! {
        n = stream.read(&mut buf) => { // If timer fires, partial bytes in buffer are dropped!
            handle_bytes(&buf[..n?]);
        }
        _ = timeout.tick() => handle_heartbeat(),
    }
}

✓ Hardened Skill Output (Production Safe)

// [SAFE] Framed codec maintains internal buffer across cancellation
let mut framed = tokio_util::codec::FramedRead::new(stream, PacketCodec::new());
loop {
    tokio::select! {
        biased;
        Some(pkt) = framed.next() => handle_packet(pkt?),
        _ = timeout.tick() => handle_heartbeat(),
    }
}

System Mechanism: AsyncReadExt::read is not cancellation safe. Dropping the future midway discards data pulled from the kernel socket. FramedRead preserves internal state across loop iterations.

Pre-Merge Verification Checklist:

▹ Verified all filesystem operations in async call paths utilize tokio::fs or spawn_blocking.
▹ Audited all Mutex usage with cargo clippy -- -D clippy::await_holding_lock.
▹ Confirmed futures inside tokio::select! are cancellation-safe according to official Tokio contracts.
▹ CPU-bound tasks exceeding 100µs isolated via tokio::task::spawn_blocking.

Run Heuristic Verification:

python3 skills/tokio-safety-auditor/scripts/audit_tokio.py --target ./src

Zero-Copy FFI Bridge AI Systems Interop v1.0.0

pyo3-zero-copy-bridge

Antigravity Claude Code Cursor

Production FFI bridge generator connecting Python AI applications with Rust kernels. Enforces GIL release via py.allow_threads, NumPy/Arrow zero-copy contiguous memory sharing, and PyO3 0.21+ Bound lifetime boundary safety.

⚠ Why Generic Agents Fail

✕ Generic LLMs hold the Python GIL during heavy SIMD or tensor computations, blocking all concurrent Python worker threads.
✕ Agents generate naive vector conversions like array.to_vec() or Vec<f32>, triggering 100% heap copying on gigabyte-sized embeddings.
✕ Outdated PyO3 code patterns produce raw pointer conversions that trigger segmentation faults when Python's garbage collector frees underlying arrays.
✕ Missing Apache Arrow C Data Interface integration, falling back to slow serialized dictionary or pickle payloads.

🛡 Guardrails Enforced by Skill

✓ Mandatory py.allow_threads closure for all numerical loops exceeding 50 microseconds.
✓ Zero-copy NumPy tensor ingestion via numpy::PyReadonlyArray and .as_slice() with contiguous memory validation.
✓ Direct Apache Arrow RecordBatch sharing using arrow::ffi C Data Interface pointers.
✓ Strict adherence to PyO3 0.21+ Bound<'py, T> lifetime references with abi3-py310 stable ABI.

1-Click Installation Setup

Download SKILL.md

For Antigravity Agent:

agy skill install https://github.com/rustinfrajobs/skills/tree/main/skills/pyo3-zero-copy-bridge

For Claude Code (CLAUDE.md / .claude/rules):

curl -sSL https://rustinfrajobs.com/skills/pyo3-zero-copy-bridge/SKILL.md >> .claude/rules/pyo3-bridge.md

For Cursor (.cursor/rules):

mkdir -p .cursor/rules && curl -sSL https://rustinfrajobs.com/skills/pyo3-zero-copy-bridge/SKILL.md -o .cursor/rules/pyo3-bridge.mdc

Engineering Case Comparisons

Case 1: Holding GIL During Compute vs Releasing GIL with py.allow_threads

✕ Naive Agent Output (Vulnerable)

// [FAULT] Holds GIL during heavy SIMD computation
#[pyfunction]
pub fn process_embeddings(py: Python, arr: &PyArrayDyn<f32>) -> PyResult<Vec<f32>> {
    let slice = arr.to_vec()?; // Copies entire buffer!
    // GIL is held during parallel execution, freezing Python threads
    let result: Vec<f32> = slice.par_iter().map(|&x| x * 2.0).collect();
    Ok(result)
}

✓ Hardened Skill Output (Production Safe)

// [SAFE] Zero-copy slice borrowed, GIL released for Rayon parallelism
#[pyfunction]
pub fn process_embeddings<'py>(
    py: Python<'py>,
    arr: PyReadonlyArrayDyn<'py, f32>,
) -> PyResult<Bound<'py, PyArrayDyn<f32>>> {
    let slice = arr.as_slice()?; // Zero-copy borrow
    let mut output = vec![0.0f32; slice.len()];
    
    py.allow_threads(|| { // GIL released: Python threads continue unhindered
        output.par_iter_mut().zip(slice.par_iter()).for_each(|(o, i)| *o = *i * 2.0);
    });
    
    Ok(PyArrayDyn::from_vec(py, output)) // Ownership transferred to Python GC
}

System Mechanism: Releasing the GIL allows the Python runtime to service other asynchronous web requests or data loaders while Rust fully saturates multicore CPU threads.

Case 2: Python Dictionary Serialization vs Arrow C Data Interface Zero-Copy

✕ Naive Agent Output (Vulnerable)

// [FAULT] Serializing table via Python dictionary overhead
#[pyfunction]
pub fn ingest_features(py: Python, dict: &PyDict) -> PyResult<usize> {
    // Iterating Python dict induces severe CPython interpreter overhead
    let keys = dict.keys();
    Ok(keys.len())
}

✓ Hardened Skill Output (Production Safe)

// [SAFE] Direct C Data Interface pointer ingestion
#[pyfunction]
pub fn ingest_features(_py: Python, array_ptr: usize, schema_ptr: usize) -> PyResult<usize> {
    let ffi_array = array_ptr as *mut arrow::ffi::FFI_ArrowArray;
    let ffi_schema = schema_ptr as *mut arrow::ffi::FFI_ArrowSchema;
    let (data, _schema) = unsafe { arrow::ffi::from_ffi(std::ptr::read(ffi_array), &std::ptr::read(ffi_schema))? };
    let batch = arrow::record_batch::RecordBatch::from(arrow::array::make_array(data));
    Ok(batch.num_rows()) // Zero bytes copied
}

System Mechanism: The Apache Arrow C Data Interface enables zero-copy interchange of column chunks between PyArrow and Rust arrow-rs via raw C ABI pointers with zero serialisation penalty.

Pre-Merge Verification Checklist:

▹ Verified py.allow_threads wraps all computationally intensive loops.
▹ NumPy inputs validated for C-contiguity via .as_slice() prior to pointer extraction.
▹ Replaced legacy PyO3 pointer dereferencing with modern Bound<'py, T> types.
▹ Configured abi3-py310 stable ABI flags in Cargo.toml and pyproject.toml.

Run Heuristic Verification:

maturin develop --release && python3 skills/pyo3-zero-copy-bridge/template/test_bridge.py

Architectural Philosophy: Why Agent Skills Matter for Systems Engineering

Rust enforces memory safety through ownership and borrow semantics at compile time, but it cannot prevent cooperative runtime starvation or FFI boundary mistakes. Specialized agent skills bridge this gap by constraining generative models to proven distributed and low-latency architectural patterns.

01. Runtime Integrity First

Asynchronous executors rely on cooperative yielding. Blocking I/O or mutex contention does not manifest as compiler errors: it manifests as severe latency tail spikes under production load.

02. Zero Memory Copies

In AI model serving and embeddings retrieval, tensor copying destroys throughput. Enforcing PyO3 contiguous slice borrowing and Apache Arrow C Data Interface guarantees zero-overhead interop.

03. Deterministic Lint Gates

Pairing LLM system prompt directives with strict compiler configurations (clippy.toml and disallowed-methods) creates a self-healing feedback loop for coding agents.