Tauri Orchestrator
The single entry skill for Tauri v2 work. It locates the task on the lifecycle ×
concern map and delegates to one of 40 specialist spokes. The cross-cutting model every
Tauri app shares — the capability / permission / scope security system, the IPC trust
boundary, the process model, and the v2 conventions — lives in tauri-core; read it before
configuring permissions or wiring IPC.
Routing map (intent → spoke)
Scaffold & understand
- New project / first run →
setting-up-tauri-projects, tauri-v2
- "How does Tauri actually work?" →
understanding-tauri-architecture, understanding-tauri-process-model, understanding-tauri-runtime-authority, understanding-tauri-lifecycle-security, understanding-tauri-ecosystem-security
Configure the app
- App/config knobs →
configuring-tauri-apps
- Security surface (the heart of Tauri) →
configuring-tauri-capabilities, configuring-tauri-permissions, configuring-tauri-scopes, configuring-tauri-csp, configuring-tauri-http-headers (model in tauri-core)
- Windows / chrome →
customizing-tauri-windows, adding-tauri-splashscreen, adding-tauri-system-tray
- Bundled files →
managing-tauri-app-resources
IPC & the Rust ↔ frontend bridge
- Concept →
understanding-tauri-ipc
- JS → Rust (commands) →
calling-rust-from-tauri-frontend
- Rust → JS (emit/invoke) →
calling-frontend-from-tauri-rust
- Events →
listening-to-tauri-events
- Wiring a frontend →
integrating-tauri-js-frontends, integrating-tauri-rust-frontends
Extend
- Sidecars / external binaries →
embedding-tauri-sidecars, running-nodejs-sidecar-in-tauri
- Plugins →
developing-tauri-plugins, managing-tauri-plugin-permissions
Build, sign, ship
- Optimize / CI →
optimizing-tauri-binary-size, building-tauri-with-github-actions
- Sign →
signing-tauri-apps
- Per-platform →
distributing-tauri-for-macos, distributing-tauri-for-windows, packaging-tauri-for-linux, distributing-tauri-for-ios, distributing-tauri-for-android
- Managed pipeline →
using-crabnebula-cloud-with-tauri
Operate & maintain
- Debug →
debugging-tauri-apps
- Test →
testing-tauri-apps
- Upgrade / migrate →
updating-tauri-dependencies, migrating-tauri-apps
Standard Operating Flow
- Locate the task: which lifecycle stage (scaffold → configure → bridge → extend → ship → operate) and which concern.
- If it touches permissions, scopes, IPC, or CSP, pull the model from
tauri-core first — these are interlocking, not independent.
- Delegate to the spoke(s). Multi-step asks fan out in lifecycle order (e.g. "ship to all desktops" → sign → macos + windows + linux).
- Return: chosen spoke(s), the capability/permission changes implied, target platform(s), and the next action.
Guardrails
See tauri-core. In short: default-deny — grant the narrowest capability/permission/scope
that works; keep the CSP strict; never expand the IPC allowlist or filesystem scope without
saying so explicitly; confirm signing identities and per-platform requirements before a release
build. Tauri's value is the locked-down security boundary — don't quietly widen it.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
1---2name: tauri-orchestrator3description: Route a Tauri task to the right skill among 40 Tauri specialists — scaffolding, the security/capability model, IPC and the Rust↔frontend bridge, windows/UI chrome, sidecars, plugins, building, signing, per-platform distribution, debugging, and migration. USE WHEN a user is building, configuring, securing, or shipping a Tauri v2 desktop/mobile app but hasn't named the specific concern.4---56# Tauri Orchestrator78The single entry skill for Tauri v2 work. It locates the task on the **lifecycle ×9concern** map and delegates to one of 40 specialist spokes. The cross-cutting model every10Tauri app shares — the capability / permission / scope security system, the IPC trust11boundary, the process model, and the v2 conventions — lives in `tauri-core`; read it before12configuring permissions or wiring IPC.1314## Routing map (intent → spoke)1516**Scaffold & understand**17- New project / first run → `setting-up-tauri-projects`, `tauri-v2`18- "How does Tauri actually work?" → `understanding-tauri-architecture`, `understanding-tauri-process-model`, `understanding-tauri-runtime-authority`, `understanding-tauri-lifecycle-security`, `understanding-tauri-ecosystem-security`1920**Configure the app**21- App/config knobs → `configuring-tauri-apps`22- **Security surface** (the heart of Tauri) → `configuring-tauri-capabilities`, `configuring-tauri-permissions`, `configuring-tauri-scopes`, `configuring-tauri-csp`, `configuring-tauri-http-headers` *(model in `tauri-core`)*23- Windows / chrome → `customizing-tauri-windows`, `adding-tauri-splashscreen`, `adding-tauri-system-tray`24- Bundled files → `managing-tauri-app-resources`2526**IPC & the Rust ↔ frontend bridge**27- Concept → `understanding-tauri-ipc`28- JS → Rust (commands) → `calling-rust-from-tauri-frontend`29- Rust → JS (emit/invoke) → `calling-frontend-from-tauri-rust`30- Events → `listening-to-tauri-events`31- Wiring a frontend → `integrating-tauri-js-frontends`, `integrating-tauri-rust-frontends`3233**Extend**34- Sidecars / external binaries → `embedding-tauri-sidecars`, `running-nodejs-sidecar-in-tauri`35- Plugins → `developing-tauri-plugins`, `managing-tauri-plugin-permissions`3637**Build, sign, ship**38- Optimize / CI → `optimizing-tauri-binary-size`, `building-tauri-with-github-actions`39- Sign → `signing-tauri-apps`40- Per-platform → `distributing-tauri-for-macos`, `distributing-tauri-for-windows`, `packaging-tauri-for-linux`, `distributing-tauri-for-ios`, `distributing-tauri-for-android`41- Managed pipeline → `using-crabnebula-cloud-with-tauri`4243**Operate & maintain**44- Debug → `debugging-tauri-apps`45- Test → `testing-tauri-apps`46- Upgrade / migrate → `updating-tauri-dependencies`, `migrating-tauri-apps`4748## Standard Operating Flow49501. Locate the task: which lifecycle stage (scaffold → configure → bridge → extend → ship → operate) and which concern.512. If it touches **permissions, scopes, IPC, or CSP**, pull the model from `tauri-core` first — these are interlocking, not independent.523. Delegate to the spoke(s). Multi-step asks fan out in lifecycle order (e.g. "ship to all desktops" → sign → macos + windows + linux).534. Return: chosen spoke(s), the capability/permission changes implied, target platform(s), and the next action.5455## Guardrails5657See `tauri-core`. In short: **default-deny** — grant the narrowest capability/permission/scope58that works; keep the CSP strict; never expand the IPC allowlist or filesystem scope without59saying so explicitly; confirm signing identities and per-platform requirements before a release60build. Tauri's value is the locked-down security boundary — don't quietly widen it.6162## Loading spokes on demand6364To keep CLI startup context lean, this cluster's spokes are **not** separately registered as skills — only this orchestrator and its `*-core` are enumerated. When you route to a spoke named above, **load it on demand** by reading its file:6566`~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md` (or `skills/<spoke-name>/SKILL.md` inside the skill-clusters repo).
Sheshiyer