/baocut

name: baocut
description: >-
  BaoCut-only operator for the installed `bcut` CLI and `.bcut` projects.
  Implicitly trigger only when the request explicitly names BaoCut or `bcut`,
  targets a `.bcut` project or BaoCut Subtitle Studio, or continues a BaoCut
  workflow already established in the conversation. Do not trigger solely for
  generic audio or video, transcription, subtitles, translation, editing,
  animation, review, rendering or export, FFmpeg, or another NLE. Once
  triggered, execute and verify the requested BaoCut transcription, subtitle or
  timeline, overlay, review, render, or export workflow. Being inside the
  BaoCut source repository is not itself a trigger; ordinary code and
  documentation tasks follow repository instructions unless they also operate
  the product or a `.bcut` project.
metadata:
  version: "1.1.4"
  minAppVersion: "1.1.4"

BaoCut

Use the bundled resolver for every command. On macOS/Linux:

BAOCUT_SKILL_ROOT="<this-skill-directory>"
"$BAOCUT_SKILL_ROOT/bin/baocut" --json version

On Windows, run the native PowerShell resolver (WSL is not required):

$env:BAOCUT_SKILL_ROOT = "<this-skill-directory>"
& "$env:BAOCUT_SKILL_ROOT\bin\baocut.ps1" --json version

Mandatory startup version gate

Run this gate once at the start of every BaoCut task, before `spec`, `doctor`, any project command, or reuse of an existing `bcut serve`:

1. Explicitly run the platform resolver's `--json version` command above and retain its `appVersion` and `commit`. A successful resolver handshake, a compatible `spec`, `doctor`, or `serve --status` is not an update check. 2. Immediately read and execute [references/updates.md](references/updates.md): fetch the published appcast and compare its version numerically with the local `appVersion`. Only an unavailable appcast may be reported as skipped. 3. When the appcast is newer, update the standalone skill and let its refreshed resolver download, verify, and cache the pinned CLI before continuing. Do not merely report the update or keep using the compatible old CLI. Never overwrite a development checkout or an App-bundled skill; use the supported source/App update path documented in the reference instead. 4. After any CLI update, run the refreshed resolver with `serve --background`, then `serve --status`. This idempotent start replaces an older same-root service, restores its mounts, and must report the refreshed CLI's `appVersion` and `commit`; also require HTTP 200 from its health endpoint. Discard any URL discovered before the restart.

Only after this gate may capability preflight and the requested work begin.

The resolver locates the right CLI on its own — never call `bcut` directly:

• An explicit `BAOCUT_CLI` (or `BCUT_EXECUTABLE` / `BAOCUT_BIN`) override wins.

Point it only at a CLI built for this machine's architecture — see the architecture guard below.

• In a BaoCut development checkout (this skill directory inside the source

tree) it uses the workspace build — newest of release/debug, under `core/target/{release,debug}/bcut` or `core/target/<host-triple>/…` — or runs the sources via `cargo run` when nothing is built yet (it looks for `cargo` in `~/.cargo/bin`, Homebrew's rustup, and `~/.rustup/toolchains` when PATH lacks it). It prints a `development checkout detected` note to stderr in that case, and a separate note when it must compile from source or when it falls back to the installed App CLI because nothing is built and `cargo` is unavailable — read those notes instead of guessing why a version gate failed. A foreign-architecture build in the tree (for example `core/target/x86_64-apple-darwin/…` on Apple Silicon) is never selected.

• In a released install it uses the CLI embedded in BaoCut.app, in either

`/Applications` or `~/Applications`; every App release ships with its matching `baocut-cli`, so App and CLI versions always move together.

• Then a `bcut` on PATH.
• Then the cached CLI this skill pinned earlier, under

`${XDG_CACHE_HOME:-~/.cache}/baocut/cli/<version>-build.<build>/bcut`.

On Windows, `bin/baocut.ps1` uses the same explicit overrides, development-checkout build, and PATH lookup first. It then checks cached `<version>-build.<build>` CLIs newest-first — by version *and* build, because the handshake only reports the marketing version and cannot tell two builds apart — and compatibility-checks them locally. Only when no compatible cache exists does it find the newest stable `baocut-v<version>-build.<build>` GitHub Release that includes `windows-cli-release.json`, downloads its x64 Windows archive, verifies the manifest-pinned SHA-256, and caches `bcut.exe` under `%LOCALAPPDATA%\BaoCut\cli\<version>-build.<build>\bcut.exe`. "Newest" is the highest `<version>`/`<build>` parsed from the release tags, not the first entry the API returns: Windows assets are appended to an already-published macOS release, so creation order does not track build order. The Windows archive is currently an unsigned preview, so SmartScreen, Smart App Control, or enterprise policy may warn about or block it; SHA-256 proves download integrity, not publisher identity.

A compatible cache normally ends the search, so a rebuild published under the same marketing version is not picked up on its own — nothing local announces it, since the Windows skill ships no CLI pin and `--json version` carries no build number. Set `BAOCUT_SKILL_CLI_UPDATE_CHECK=1` to let the cache path compare against the newest release and adopt a higher build; unset, that path stays entirely offline, and any failed check silently keeps the cached CLI. `BAOCUT_SKILL_NO_DOWNLOAD=1` still wins over this opt-in.

Before choosing a Windows cache or release, the resolver runs `bin/detect-windows-cli-variant.ps1`. The detector uses `nvidia-smi` and selects `cuda13` only when at least one NVIDIA GPU has compute capability 8.0+ (Ampere / RTX 30 series or newer) and t