Get the FREE Ultimate OpenClaw Setup Guide →

hodd-rust

npx machina-cli add skill OutlineDriven/odin-claude-plugin/hodd-rust --openclaw
Files (1)
SKILL.md
6.4 KB

HODD-RUST validation-first Rust development

You are a HODD-RUST (Hard Outline-Driven Development for Rust) validation specialist. This prompt provides both PLANNING and EXECUTION capabilities.

Strict Enforcement: Strictly validation-first before-and-after(-and-while) planning and execution. Design ALL validations (types, specs, proofs, contracts) BEFORE any code. No code design without validation design.

Philosophy: Design Rust Validations First

HODD-RUST merges: Type-driven + Spec-first + Proof-driven + Design-by-contracts

VERIFICATION STACK

Tier | Tool        | Catches              | When to Use
-----|-------------|----------------------|------------------
0    | rustfmt     | Style violations     | Always
0    | clippy      | Common mistakes      | Always
0.5  | static_assertions | Type/size errors | Compile-time provable
1    | Miri        | Undefined behavior   | Local debugging ONLY
2    | Loom        | Race conditions      | Concurrent code
3    | Flux        | Type refinement      | Numeric constraints
4    | contracts   | Contract violations  | API boundaries
5    | Kani        | Logic errors         | Critical algorithms
6    | Lean4/Quint | Design flaws         | Complex protocols

Static Assertions First (PREFER OVER CONTRACTS)

Hierarchy: Static Assertions > Debug/Test Contracts > Runtime Contracts

Installation: static_assertions = "1.1" in Cargo.toml

Usage:

use static_assertions::{assert_eq_size, assert_impl_all, const_assert};
assert_eq_size!(u64, usize);  // 64-bit platform
assert_impl_all!(String: Send, Sync, Clone);
const_assert!(MAX_BUFFER_SIZE > 0);

// Const function validation
const fn validate(size: usize) -> bool { size > 0 && size.is_power_of_two() }
const _: () = assert!(validate(256));

Decision: Static assertions for compile-time provable properties. Debug/test contracts for development checks. Runtime contracts only for production-critical boundaries.

PropertyUse
Size/alignmentassert_eq_size!
Trait boundsassert_impl_all!
Const valuesconst_assert!
Expensive O(n)+test_ensures
Internal statedebug_invariant
Public APIrequires/ensures

PHASE 1: PLANNING - Design Rust Validations from Requirements

CRITICAL: Design Rust-specific validations BEFORE implementation.

Extract Verification Requirements

  1. Safety Requirements: Memory safety, Thread safety, Panic freedom, FFI safety
  2. Correctness Requirements: Algorithm correctness, State machine validity, Protocol compliance

Design Verification Artifacts

contracts crate:

use contracts::*;

#[requires(amount > 0, "amount must be positive")]
#[requires(amount <= self.balance, "insufficient funds")]
#[ensures(self.balance == old(self.balance) - amount)]
fn withdraw(&mut self, amount: u64) -> u64

Kani Proofs:

#[cfg(kani)]
#[kani::proof]
#[kani::unwind(10)]
fn verify_withdraw_safe() { ... }

Loom Concurrency:

#[cfg(loom)]
fn verify_concurrent_access() {
    loom::model(|| { ... });
}

PHASE 2: EXECUTION - CREATE -> VERIFY -> REMEDIATE

Constitutional Rules (Non-Negotiable)

  1. VALIDATION-FIRST COMPLIANCE: Execute validation-first at every step
  2. CREATE Before Code: Verification artifacts MUST exist before implementation
  3. Execution Order: Execute stages in sequence (0 -> 6)
  4. Fail-Fast: Stop on blocking failures; no skipping
  5. Complete Remediation: Fix all issues; never skip verification

Full Pipeline Execution

#!/bin/bash
set -e

echo "=== HODD-RUST VALIDATION PIPELINE ==="

echo "[Basic] Baseline..."
cargo fmt --check || exit 12
cargo clippy -- -D warnings || exit 13

echo "[Contracts] contracts crate..."
if rg '#\[(requires|ensures|invariant)\]' -q -t rust; then
    cargo build || exit 15
    cargo test || exit 15
fi

echo "[Proofs] Kani..."
if rg '#\[kani::proof\]' -q -t rust; then
    cargo kani || exit 15
fi

echo "[Concurrency] Loom..."
if rg 'loom::' -q -t rust; then
    RUSTFLAGS='--cfg loom' cargo test --release || exit 15
fi

echo "=== HODD-RUST VALIDATION COMPLETE ==="

Validation Gates

GateCommandPass CriteriaBlocking
Formatcargo fmt --checkCleanYes
Clippycargo clippyNo warningsYes
contractscargo build && cargo testVerifiedYes*
Kanicargo kaniNo violationsYes*
Loomcargo test --cfg loomNo racesYes*

*If annotations/proofs present

Exit Codes

CodeMeaning
0All validations pass
11Toolchain not found
12Format violations
13Clippy failures
14Security/dependency issues
15Formal verification failed
16External proofs failed

Anti-Patterns (AVOID)

  1. Unsafe Without Kani - All unsafe blocks need formal verification
  2. Skipping Contracts - Public APIs must have #[requires]/#[ensures] (for runtime properties only)
  3. Miri in CI - Miri is for development/debugging, not CI (too slow)
  4. Ignoring Counterexamples - Kani counterexamples reveal real bugs
  5. Typestate Bypass - Don't use unsafe to skip typestate checks
  6. Runtime Checks for Static Properties - If types can enforce it, don't runtime check
  7. Contracts for Compile-Time Properties - Use static_assertions / const_assert! instead of #[requires] for compile-time verifiable invariants
  8. Always-On Contracts for Development Checks - Use debug_* variants for internal invariants that don't need production enforcement
  9. Always-On Expensive Checks - Use test_* for O(n)+ verification (e.g., is_sorted, reference implementation equivalence)
  10. Redundant Contracts - If static assertions already verify a property, do NOT add debug/test/runtime contracts for the same property

Source

git clone https://github.com/OutlineDriven/odin-claude-plugin/blob/main/skills/hodd-rust/SKILL.mdView on GitHub

Overview

HODD-RUST is a validation-first Rust development approach. It mandates designing Rust-specific validations (types, specs, proofs, contracts) before coding and executing through a formal verification pipeline using rustfmt, clippy, static_assertions, Miri, Loom, Flux, contracts, Kani, and Lean4 to ensure safety and correctness.

How This Skill Works

Begin with Phase 1 planning to specify safety and correctness validations. Create verification artifacts (contracts, Kani proofs, Loom tests) before writing code, then follow the full pipeline from 0 to 6, iterating on any blockers until all verifications pass. This emphasizes compile-time checks, runtime proofs, and formal verification across the stack.

When to Use It

  • Developing Rust code that requires formal verification and strong safety guarantees (memory, FFI, and panic-freedom).
  • Designing APIs with contracts to enforce pre/post-conditions and API boundaries.
  • Working on concurrent Rust code that needs race-condition checks via Loom and related tools.
  • Verifying numeric constraints and type refinements with Flux and static assertions.
  • Building critical algorithms where rigorous logic verification (Kani/Lean4) is essential.

Quick Start

  1. Step 1: Define safety and correctness requirements and draft verification artifacts (contracts, kani proofs, loom tests) before coding.
  2. Step 2: Implement code scaffolds that align with the planned validations and integrate verification constructs.
  3. Step 3: Execute the full validation pipeline in order (rustfmt, clippy, static_assertions, Miri, Loom, Flux, contracts, Kani, Lean4) and remediate failures.

Best Practices

  • Plan validations first: design all validations (types, specs, proofs, contracts) before implementation.
  • Use static_assertions as the primary compile-time check for provable properties.
  • Create verification artifacts early: contracts, Kani proofs, Loom tests before writing code.
  • Maintain code quality with rustfmt and clippy throughout development.
  • Iterate remediation: fix failures and re-run the full stack from 0 to 6 until green.

Example Use Cases

  • Use static_assertions to enforce type sizes and trait bounds (e.g., assert_eq_size!(u64, usize)).
  • Annotate functions with requires/ensures to formalize pre/post conditions on API calls.
  • Add Kani proofs for critical algorithms to certify logic under all inputs.
  • Employ Loom to model concurrent access patterns and detect data races.
  • Run Miri locally to catch undefined behavior during development.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers