home / skills / busirocket / agents-skills / busirocket-rust-tauri-standards

busirocket-rust-tauri-standards skill

safe

/skills/busirocket-rust-tauri-standards

This skill enforces Rust and Tauri coding standards for maintainable desktop apps, promoting one-thing-per-file, strict SQL/prompt separation, and proper

npx playbooks add skill busirocket/agents-skills --skill busirocket-rust-tauri-standards

Review the files below or copy the command above to add this skill to your agents.

Files (10)

SKILL.md

2.5 KB

---
name: busirocket-rust-tauri-standards
description:
  Rust and Tauri standards for maintainable desktop apps. Use when writing Rust
  code in Tauri projects, creating Tauri commands, separating SQL/prompts from
  Rust code, and enforcing one-thing-per-file discipline.
metadata:
  author: cristiandeluxe
  version: "1.0.0"
---

# Rust + Tauri Standards

Strict, reusable standards for Rust/Tauri desktop applications.

## When to Use

Use this skill when:

- Writing Rust code in Tauri projects
- Creating new Tauri commands
- Separating SQL queries and prompts from Rust code
- Enforcing one-thing-per-file discipline in Rust modules

## 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. `src-tauri/sql/<area>/Xxx.sql`).
- **No inline LLM/AI prompts** in `.rs` files; use dedicated prompt files with
  `include_str!()` (e.g. `src-tauri/prompts/<area>/Xxx.prompt`).
- When creating a Tauri command: (1) create command file, (2) register in invoke
  handler, (3) add to permissions allowlist.

## Module Layout

- `src-tauri/src/services/`: external boundaries (IO, DB, network).
- `src-tauri/src/utils/`: pure logic (no IO).
- `src-tauri/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)

### Tauri Commands

- `rust-tauri-commands-checklist` - Tauri commands checklist (MANDATORY)

### Validation

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

## 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-tauri-commands-checklist.md
```

Each rule file contains:

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

Overview

This skill provides strict, reusable Rust and Tauri standards for building maintainable desktop apps. It codifies file layout, one-thing-per-file discipline, separation of SQL and LLM prompts from Rust sources, and a checklist for Tauri commands. The rules are designed to reduce coupling, improve reviewability, and make code safer to audit and test.

How this skill works

The skill inspects Rust/Tauri projects and enforces conventions via named rules: one public symbol per file, module layout (services/utils/models), SQL and prompt separation using include_str!(), and Tauri command registration/checklist. Each rule includes rationale, correct/incorrect examples, and concrete steps to remediate violations. Use the rules as a checklist when authoring code, reviewing PRs, or adding new Tauri commands.

When to use it

Writing or refactoring Rust code inside a Tauri project
Adding new Tauri commands and their invoke handlers
Keeping SQL queries and AI prompts out of .rs source files
Enforcing single-responsibility files (one public symbol per file)
Establishing clear service vs. pure-logic boundaries in src-tauri

Best practices

Place IO, DB, and network code in src-tauri/src/services/ and keep pure functions in src-tauri/src/utils/
Store domain types in src-tauri/src/models/, one type per file, and avoid misc helper modules
Put SQL in src-tauri/sql/<area>/Xxx.sql and prompts in src-tauri/prompts/<area>/Xxx.prompt, then load with include_str!()
When adding a Tauri command: create a command file, register it in the invoke handler, and add it to the allowlist/permissions
Keep handlers thin: validate inputs, call services, and return results—push business logic into services or utils
Run the validation/checklist after changes and include rule references in PRs for faster reviews

Example use cases

Creating a new file-system sync feature: add thin command handler, service implementation, and a model file for types
Moving inline SQL out of a module into src-tauri/sql/user/GetUserById.sql and using include_str!() in the data access file
Extracting an AI prompt from code into src-tauri/prompts/compose/GenerateSummary.prompt and loading it at runtime
Reviewing a pull request to ensure no file contains more than one public function or type
Adding a new Tauri command: implement, register in invoke handler, and add to permissions allowlist

FAQ

Why one public symbol per file?

It improves discoverability, reduces merge conflicts, and makes changes easier to review and test.

How should I organize shared utilities?

Keep pure, side-effect-free code in src-tauri/src/utils/ and avoid a catch-all helpers.rs; create focused modules instead.