soloist

Work ONE ticket from a .scratch/<feature>/issues/ local-tracker backlog end to end, in a single command, so each implementation session is one step instead of many. Runs the Soloist start-of-session protocol, picks the next open+unblocked ticket (or the one you name), claims it, implements it test-first via /implement (tdd → gates → code-review → commit), then updates the ticket Status and PROGRESS.md. Use when the user says 'work the next ticket', '/work-ticket', 'do the next PRD/issue', or names a ticket number to implement. One ticket per invocation.

Detect, fix, and re-verify performance, quality, supply-chain, and runtime issues across the whole Soloist app — the Rust core + Tauri adapters and the React/TS frontend — using the project's own detection tools. Use when the user wants to optimize, speed up, audit, health-check, or "find and fix anything broken or slow" in Soloist. Runs the real gates (cargo-deny, clippy, the soak leak-gate, bundle/bloat measurement) and delegates React component issues to the react-doctor skill, then applies fixes and re-runs each gate to confirm green. It changes code, but stays inside the architecture and the locked non-changes — it measures before optimizing, never weakens a test to pass, accepts an unfixable advisory only with a written reason, and never touches PROGRESS.md unless asked.

Cut and ship a Soloist release. Reads what merged since the last release, decides the semantic-version bump, syncs the version across the three manifests, tags, and pushes so CI builds and publishes the GitHub Release the in-app updater reads from. Use when the user wants to release, ship, publish, or bump the app version.

Comprehensively research, review, and verify a set of Soloist changes — a phase's work, a commit range, a PR branch, or the current uncommitted diff — against the architecture, security, clean-room, and codebase-discipline contracts. Use when the user wants to review, audit, or sanity-check Soloist code before merge. Read-and-verify only — it grounds itself in the plan docs, pins the exact diff, researches official docs before judging (never assumes), runs the real gates, and reports findings by severity. It does NOT build features and does NOT change code unless explicitly told to after the findings. First-class checks span domain boundaries & separation (hexagonal + bounded contexts), duplication / single-source / DRY, correctness & bugs, security gaps, performance & size, comment/clean-room discipline, tests, and docs — and it consults the official Tauri docs plus the project's tauri-* skills before judging any Tauri surface.