Make frontend and Rust agree
Specify command names, argument casing, serialized results and error handling before debugging both sides at once.
Skill
Build with Tauri
Make the desktop app work beyond the dev server.
A Tauri 2 development skill for the boundary between webview, Rust and companion processes. Turn “it opens” into clear contracts for requests, streaming, permissions and shutdown.
Fictional contract: import sidecar Ready: expected versioned health response before deadline Startup failure: show reason, retry and cancel Owner: application retains child handle Exit: graceful stop, then bounded kill fallback Release check: correct target-triple binary included
Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.
Know when a sidecar is ready
Use a bounded readiness check, an owned child handle and explicit failure recovery.
Check the app people install
Separate source checks, mocked IPC, the running desktop app and the packaged release.
The film
Running is not ready.
In 71 seconds, Duffel the hound sleeps in the sidecar while the app waits three seconds, hopes, and sends the first import to nobody. Build with Tauri treats running and ready as two different things: the app holds the sidecar, waits for a ready signal with a deadline, and writes down what ready means, what failure shows and how it stops. Then you break it on purpose. Captions are on the player; a transcript is below.
Read the transcript
Your desktop app is a motorbike. Duffel rides in the sidecar.
You start both, wait three seconds, and hope.
The timer pings. The first import goes out. Duffel sleeps on.
On your machine, it worked every time.
Build with Tauri treats running and ready as two different things.
Your app holds the sidecar, and waits for a ready signal with a deadline.
Out comes the contract: what ready means, what failure shows, how it stops.
Then you break it on purpose: a wrong field, a slow start, a crash.
The skill ships no desktop app. You test drive on your own machines.
On screen: Running is not ready.
Build with Tauri. Make the desktop app work beyond the dev server.
The photo importer and its sidecar contract are a fictional example. The film shows how the skill behaves; it does not report results.
See the work take shape.
Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.
Map the app
Inspect lockfiles, configuration, capabilities, Rust entrypoints and target operating system.
Define the boundary
Choose request/response, channel or event behavior; declare permissions and lifecycle ownership.
Exercise the failure paths
Test wrong fields, startup failure, repeated launch, cancellation and app exit before checking release packaging.
Fictional example
The window opens before the engine is ready
The brief A fictional desktop import tool starts a local sidecar and immediately sends requests.
Before
A fixed sleep and a successful spawn are treated as readiness.
After applying the method
Keep a child handle, wait for the expected versioned health response with a deadline, show retry/cancel, and clean up on every app exit path.
A running process, a ready service, and a successful user task are distinct observations.
A clear job.
A useful stopping point.
Use when creating or repairing Tauri 2 project structure, IPC, permissions, or sidecar lifecycle.
Use it when
- A frontend command reaches Rust with the wrong arguments.
- A companion process starts but is not ready for requests.
- The dev app works while the packaged desktop build fails.
Choose another route when
- A bundled desktop executable or cross-platform acceptance certificate.
- A reason to broaden permissions before inspecting the relevant application or plugin rules.
Structure
The app layout, target platforms, or build boundary is unclear.
A versioned map of frontend, Rust shell, capabilities, and packaged binaries.
IPC
A frontend action needs Rust data, progress, or an error.
A typed command/channel/event contract with lifecycle and permission checks.
Sidecar
A companion process must start, serve, recover, and stop.
An explicit readiness, ownership, failure, and cleanup contract.
Read the canonical method
Build with Tauri
Build a desktop app whose frontend and sidecar agree.
Inspect the app before changing it
Read package.json, the frontend lockfile, src-tauri/Cargo.toml, Cargo.lock, configuration, capability files, Rust entrypoints, and the actual target platform. Record the versions. Decide whether the task belongs in the frontend, Rust shell, a plugin, or a companion process. Keep application-specific examples separate from Tauri's general protocol.
Structure
Use project structure to trace frontend build → shell configuration → Rust setup → bundle output. Preserve the project's package manager and platform setup. Run existing build commands, not a newly invented parallel build system. Check the packaged asset paths and CSP against actual configuration.
IPC
Use IPC patterns as the baseline, with the current corrections. Write a contract for command name, argument names/casing, serialized return/error values, caller window, and permission scope. Register all commands in the actual builder. Prefer commands for request/response, channels for ordered streaming tied to a request, and events for suitable broadcast notifications. Clean up every listener on unmount or cancellation; test failure and repeated mounting.
An async signature does not make blocking filesystem or CPU work nonblocking. Use an appropriate asynchronous API or a blocking task. Application commands and plugin permissions follow different rules: do not invent a per-command capability entry as a universal fix. Inspect the project's application-command ACL and the relevant plugin's generated permissions.
Sidecar
Use sidecar integration and the current corrections. Define the binary name and target-triple artifact, allowed arguments, transport, readiness response/version, bounded timeout, stderr handling, restart policy, cancellation, and shutdown owner. A successful process spawn is not readiness. Keep the child handle; prefer graceful shutdown before a bounded kill fallback. Test startup failure, occupied port, crashed child, repeated launch, and application exit. Window destruction alone may not mean the application exits in a multi-window/tray app.
Verify in layers
Run formatting/type/build checks first, then IPC checks with deliberately mismatched fields and rejected permissions, then the actual desktop app on the target OS. Confirm release packaging contains the correct sidecar architecture. A dev server success does not establish the installed app works. Record which layer ran and which remains blocked. This repository supplies reference patterns, not an executable contract fixture, Tauri compiler or desktop acceptance test. Create boundary checks in the actual app and record what they exercise.
Return changed interfaces, minimum permissions, version/source evidence, exact checks, and a reproducible unresolved case. Keep real-user usability and accessibility claims within the evidence actually collected.
Limits and prerequisites
- Scope is Tauri 2 guidance; inspect the project lockfiles before applying any example.
- Source checks and mocked IPC cannot establish desktop packaging or OS lifecycle behavior.
- No sidecar, network service, or permission broadening is required to install the method.
Your first useful run.
Bring the app, target operating system and one failure you can reproduce.
The download contains the complete skill folder. Extract it into the skills directory supported by your agent, keeping its references and license together. Or use the source installer below. Python 3.11+ is required for that installer.
Start from the public source
git clone https://github.com/michaeljabbour/amplifier-skill-build-tauri.git
cd amplifier-skill-build-tauripython3 scripts/capability.py doctor
python3 scripts/capability.py install --dest ~/.agents/skillsKeep the complete skill folder together, including its references and license. The host applies the method in your context; the skill does not start a background service.
- Requires Git and Python 3.11+ for the repository installer. The portable method itself can be read by a compatible agent without a service or provider account.
- The destination is a skills-parent folder. Use the discovery path supported by your agent; ~/.agents/skills is an example, not a universal host setting.
- Keep the complete installed folder, references and license together. Identical reinstall is safe; conflicts are refused. A deliberate --replace keeps a dated backup.
Try this with your agent
Use Build with Tauri on this Tauri 2 app. Its import sidecar starts slowly and the first request fails. Trace startup, define readiness and shutdown ownership, and propose the smallest fix with target-OS checks.Use after installing in a host that loads skill folders. Supply your own task files and review the result.
Keep the guide nearby
Read the guide · License · Changes · Release metadata · Install guide · Migration · Validation · Native guide · consolidation
Know what you can rely on.
The retained references were reviewed against the linked official Tauri 2 contracts, and the portable package is checked. No desktop executable is supplied; operating-system lifecycle and release packaging must be tested in your app.
Read the checks and their scope
- Source-specific Tauri contract review — reviewed
Confirmed distinctions for application vs plugin ACL, async vs blocking work, channels vs broadcast events, and target-triple sidecars. No Tauri desktop executable is part of this source repository; OS runtime and packaging acceptance not measured.
- Portable packaging and install — passed
All operations passed. No runtime activation or effectiveness measured.
- Skill discovery metadata — passed
Skill is valid. This is a structural check, not a behavioral benchmark.
The retained references were reviewed against the linked official Tauri 2 contracts, and the portable package is checked. No desktop executable is supplied; operating-system lifecycle and release packaging must be tested in your app.
Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.