agentsclimarketplace
Sign in

Ship tauri python sidecar

Skill aAAaqwq/AGI-Super-Team/skills/ship-tauri-python-sidecar

Build and release Tauri apps with a Python sidecar. Use for WebView shells, PyInstaller bundles, version sync, installers, CI releases, lifecycle bugs, signing, or updates.From its SKILL.md

Install
npx -y skills add aAAaqwq/AGI-Super-Team --skill ship-tauri-python-sidecar

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.4 KB, 647 tokens by cl100k_base, as published. Nobody here has run it

Ship Tauri Python Sidecar

Build the desktop shell and backend as one lifecycle-managed product. Treat a generated installer as an intermediate artifact; completion requires an installed-app startup and shutdown proof.

Workflow

  1. Map the runtime topology. Record the Tauri process, sidecar process tree, loopback API, frontend entry point, writable data root, required external runtimes, and shutdown owner.
  2. Freeze one version. Select one canonical version and synchronize it across the backend, Tauri config, Cargo package, JavaScript package, installer name, update manifest, and release tag.
  3. Define the sidecar contract. Give the sidecar a deterministic binary name and target-triple filename. Define its command-line dispatch, readiness endpoint, dynamic-port discovery, stdout encoding, data directory, and parent-death behavior.
  4. Constrain the shell. Keep capabilities minimal, bind backend HTTP only to loopback, define CSP deliberately, and avoid exposing arbitrary shell execution to frontend code.
  5. Create one build entry point. Let local builds and CI call the same script. Build dependencies, sidecar, icons, Tauri binary, installer, and SHA-256 in a fixed order. Fail on a missing or implausibly small artifact.
  6. Validate in layers. Run unit and contract tests, sidecar CLI smoke tests, Tauri-to-sidecar handshake tests, process cleanup tests, installer structure checks, and a silent-install real startup test.
  7. Release by channel. Separate macOS and Windows tags, artifacts, manifests, secrets, signing credentials, and rollback procedures. Never let a tag for one platform update the other platform's channel.
  8. Report evidence. Record version, commit, runner, produced artifact, hash, startup endpoint, shutdown result, signing state, and known external prerequisites.

Non-negotiable gates

  • Do not declare success from tauri build alone.
  • Do not infer readiness from a process name; connect to the loopback endpoint owned by the listening sidecar process.
  • Account for one-file packagers that create parent and child processes with the same executable name.
  • Close the shell and prove all sidecar descendants exit. Treat leftovers as a release failure.
  • Keep user data outside the installation directory and preserve it across upgrades.
  • Never commit signing certificates or publishing secrets. Inject them only in the release environment.
  • Publish a checksum and preserve the exact build provenance.

Decision points

  • Prefer an external sidecar when the backend has a mature independent runtime or CLI surface.
  • Prefer an embedded Rust implementation only when eliminating the second runtime outweighs migration risk.
  • Embed a WebView runtime bootstrapper when target machines cannot be assumed to have it; document installer-size impact.
  • Use per-user installation unless machine-wide installation is a product requirement with an elevation plan.

References

  • Read release-contract.md when implementing or reviewing the build, CI, installer, signing, or update path.
  • Read project-evidence.md when applying the lessons extracted from this repository.

What ships with it: 4 files

5.7 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most ship operate skills give in 647 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • map the runtime topology
  • freeze one canonical version across all artifacts
  • give the sidecar a deterministic binary name
  • constrain shell capabilities
  • create one shared build entry point
  • validate the app in layers

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.