Rust Tauri Apps
Build Tauri v2 applications with small Rust command surfaces, secure capabilities, explicit IPC contracts, and maintainable distribution workflows.
Operating Model
- Inspect the Tauri version and generated structure first:
src-tauri, tauri.conf.json, capabilities, permissions, plugins, frontend invocation code, and CI/release scripts.
- Treat every command as a public bridge contract. Validate input, return typed serializable results, and keep filesystem/shell/network capabilities narrow.
- Prefer app-owned Rust services behind commands. Do not put large domain logic directly in
#[tauri::command] functions.
- Keep the capability model least-privilege by default. Avoid broad filesystem, shell, opener, and dialog permissions unless the user workflow truly needs them.
- Coordinate with the general
tauri-v2 skill when available for framework-specific current docs; use this skill for Rust architecture, security, testing, and command design.
Reference Map
references/tauri-v2-rust-backend.md for command/state/plugin architecture and typed IPC.references/capabilities-security.md for permissions, filesystem/shell risk, secrets, updater, and secure defaults.references/distribution-mobile.md for bundling, updater, sidecars, signing, desktop/mobile packaging, and release checks.
Defaults
- Keep commands async only when they await I/O. Do CPU-heavy work off the main runtime.
- Use
serde DTOs at the IPC boundary and convert to domain types inside services.
- Use
tauri::State for shared app services with clear ownership; avoid global mutable statics.
- Use plugin APIs instead of hand-rolled platform code when mature official plugins cover the use case.
- Keep frontend-originated paths, URLs, and shell arguments untrusted until validated.
Verification
Use repo-native checks first, then add Tauri-specific validation:
cargo fmt --all --check
cargo test --manifest-path src-tauri/Cargo.toml --all-targets
cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets --all-features -- -D warnings
For command changes, add Rust tests around service behavior and frontend tests or contract fixtures for IPC shapes when the app already has a frontend test lane.
1---2name: rust-tauri-apps3description: Implicit Rust Tauri v2 skill. Use for Tauri apps, Rust commands, invoke contracts, app state, plugins, capabilities and permissions, secure IPC, filesystem and shell access, sidecars, updater, bundling, desktop and mobile distribution, and Rust frontend bridge design.4license: MIT5---67# Rust Tauri Apps89Build Tauri v2 applications with small Rust command surfaces, secure capabilities, explicit IPC contracts, and maintainable distribution workflows.1011## Operating Model12131. Inspect the Tauri version and generated structure first: `src-tauri`, `tauri.conf.json`, capabilities, permissions, plugins, frontend invocation code, and CI/release scripts.142. Treat every command as a public bridge contract. Validate input, return typed serializable results, and keep filesystem/shell/network capabilities narrow.153. Prefer app-owned Rust services behind commands. Do not put large domain logic directly in `#[tauri::command]` functions.164. Keep the capability model least-privilege by default. Avoid broad filesystem, shell, opener, and dialog permissions unless the user workflow truly needs them.175. Coordinate with the general `tauri-v2` skill when available for framework-specific current docs; use this skill for Rust architecture, security, testing, and command design.1819## Reference Map2021- `references/tauri-v2-rust-backend.md` for command/state/plugin architecture and typed IPC.22- `references/capabilities-security.md` for permissions, filesystem/shell risk, secrets, updater, and secure defaults.23- `references/distribution-mobile.md` for bundling, updater, sidecars, signing, desktop/mobile packaging, and release checks.2425## Defaults2627- Keep commands async only when they await I/O. Do CPU-heavy work off the main runtime.28- Use `serde` DTOs at the IPC boundary and convert to domain types inside services.29- Use `tauri::State` for shared app services with clear ownership; avoid global mutable statics.30- Use plugin APIs instead of hand-rolled platform code when mature official plugins cover the use case.31- Keep frontend-originated paths, URLs, and shell arguments untrusted until validated.3233## Verification3435Use repo-native checks first, then add Tauri-specific validation:3637```bash38cargo fmt --all --check39cargo test --manifest-path src-tauri/Cargo.toml --all-targets40cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets --all-features -- -D warnings41```4243For command changes, add Rust tests around service behavior and frontend tests or contract fixtures for IPC shapes when the app already has a frontend test lane.
BjornMelin