Rust Standards

Strict, reusable standards for Rust codebases (libraries, CLIs, or backend
services).

When to Use

Use this skill when:

• Writing or refactoring Rust code
• Structuring modules (services, utils, models)
• Separating SQL queries or LLM prompts from Rust code
• Enforcing one-thing-per-file discipline

Non-Negotiables (MUST)

• One public symbol per file (function / type / trait).
• No inline SQL strings in .rs files; use dedicated SQL files with
  include_str!() (e.g. sql/<area>/Xxx.sql).
• No inline LLM/AI prompts in .rs files; use dedicated prompt files with
  include_str!() (e.g. prompts/<area>/Xxx.prompt).
• Handlers (HTTP, commands, etc.) must be thin: validate, call service, return.

Module Layout

• src/services/: external boundaries (IO, DB, network).
• src/utils/: pure logic (no IO).
• src/models/: domain types (one type per file).
• No "misc" modules like helpers.rs or common.rs.

Rules

Language & Style

• rust-language-style - Language & style (English-only, struct/enum, error
  types)

One Thing Per File

• rust-one-thing-per-file - One thing per file (STRICT)
• rust-module-manifests - Module manifests exception (mod.rs)

Module Layout

• rust-module-layout - Module layout (STRICT) - services, utils, models

SQL Separation

• rust-sql-separation - SQL separation (STRICT) - no inline SQL

Prompt Separation

• rust-prompt-separation - Prompt separation (STRICT) - no inline prompts

Boundaries

• rust-boundaries - Boundaries (thin handlers, validate, call service, return)

Validation

• rust-validation - Validation (run checks after changes)

Related Skills

• busirocket-core-conventions - General file structure principles
• busirocket-tauri - Tauri-specific layout and commands (when building desktop
  apps)

How to Use

Read individual rule files for detailed explanations and code examples:

rules/rust-one-thing-per-file.md
rules/rust-sql-separation.md
rules/rust-module-layout.md

Each rule file contains:

• Brief explanation of why it matters
• Code examples (correct and incorrect patterns)
• Additional context and best practices