1---2name: rust-rig3description: Use when building, reviewing, or refactoring Rust code in HOM that requires strong maintainability, testing discipline, and explicit dependency boundaries4---56<objective>7Apply the Rust-specific design, testing, and review discipline for HOM.89This is the Codex-compatible form of the important guidance previously carried by `.claude/skills/rust-rig/SKILL.md` and `.claude/rules/rust-patterns.md`.10</objective>1112<when_to_use>13Use this skill when:14- implementing a Rust feature15- refactoring Rust code for maintainability16- reviewing architecture, module boundaries, or dependency flow17- tightening tests around user-visible behavior18- replacing hardcoded wiring with explicit dependency injection19</when_to_use>2021<required_reading>22Read these files before making a meaningful Rust change:23- `skills/rust-rig/references/process-discipline.md`24- `skills/rust-rig/references/rust-patterns.md`2526Also read the relevant domain skill for the area you are changing.27</required_reading>2829<process>30Follow this workflow:31321. Inspect the workspace, relevant crate, feature flags, tests, and existing patterns first.332. Define acceptance behavior before implementation details.343. Add or update an acceptance-level or closest boundary-level failing test first.354. Add the next smallest failing unit or module test.365. Implement the minimum change that makes the tests pass.376. Refactor while green.387. Verify formatting, linting, and tests for the affected scope before handing off.39</process>4041<decision_rules>42Apply these rules during implementation:43- keep project structure clean and predictable44- enforce SRP for modules, types, and functions45- remove duplication when the abstraction improves clarity46- extend behavior additively through composition, traits, enums, and configuration47- do not introduce trait-per-struct abstractions without real consumer need48- keep domain logic separate from transport, persistence, configuration, and presentation49- keep public APIs minimal, intentional, and stable50</decision_rules>5152<dependency_injection>53Manage collaborators explicitly:54- pass long-lived collaborators through constructors55- pass short-lived collaborators and pure inputs through function parameters56- do not instantiate external clients, repositories, clocks, or runtime collaborators inside core domain logic57- do not hardcode URLs, ports, file paths, credentials, or feature switches58- prefer concrete types internally and traits only at real consumer boundaries59- use `Arc` only when shared ownership is genuinely required60</dependency_injection>6162<testing_discipline>63Testing is mandatory:64- use ATDD first for user-visible behavior65- use TDD for the next smallest increment66- cover happy path, invalid input, edge cases, and failure paths67- add concurrency-focused tests when async, task, or locking behavior can fail68- keep tests deterministic and avoid sleep-based timing where practical69</testing_discipline>7071<verification>72Run these commands as appropriate to the affected scope:73- `cargo check`74- `cargo fmt --all`75- `cargo clippy --all-targets --all-features -- -D warnings`76- `cargo nextest run` or `cargo test`77- `cargo test --all-features`78- `cargo test --no-default-features --features vt100-backend`79- `cargo test --doc`80- `cargo doc --no-deps`81</verification>8283<success_criteria>84This skill is being followed correctly when:85- changes are small, test-backed, and easy to review86- dependency flow is explicit87- module responsibilities are clearer after the change88- types and errors are strict and intentional89- formatting, clippy, and tests pass for the affected scope90</success_criteria>
mudrii