splicr (Vynaro): a Tauri 2 desktop pipeline for first-person AI video narration

What splicr actually automates, and for whom

The README positions splicr (叙影) as a desktop engine for 短剧拆条, 影视解说 and story-driven self-media work: cutting long drama episodes into clips, writing narration over them, and delivering the result as a CapCut project. The intended user is a solo creator who already works in CapCut and wants the repetitive middle of the job handled by software: scene detection, first-person monologue drafting, voice cloning, subtitle timing and track alignment.

The scope is deliberately narrow. splicr does not try to be a general NLE. It produces a .draft project that you finish and publish in CapCut, and the export crate is listed first among the export targets in Cargo.toml. If your delivery target is not CapCut, or if you edit in DaVinci Resolve or Premiere, the last step of the pipeline is the one that does not fit you.

The interface is a three-column workbench plus a dashboard, an asset manager and a settings screen, which the README shows as screenshots. That is a creator-facing tool, not a library. There is no documented CLI for the seven steps.

The six-agent pipeline and where state lives

The README's Mermaid diagram is the clearest description of the design. A DirectorAgent receives imported footage and style preferences from the human, then dispatches work: VisualCriticAgent runs FFmpeg scene detection and keyframe extraction, ScreenwriterAgent writes the 0 to 3 second hook and the first-person monologue, VoiceArtistAgent picks a voice and synthesises audio, SoundEngineerAgent aligns five tracks and ducks the background music, and QualityReviewerAgent checks the timeline before the Director either returns it for revision or hands it back to the creator.

The ScreenwriterAgent box is the one worth noting: the diagram shows an arrow looping back into itself, labelled as a self-reflection scoring loop on hook retention. That means script generation is not a single LLM call. It is generate, score, regenerate, with the loop bounded by something the README does not specify.

The crate layout matches the diagram one-to-one. crates/agent holds the orchestration, and the seven steps map to intake, detect, script, voice, subtitle, compose and export. crates/storage handles SQLite persistence and, per the Cargo.toml comments, API key storage in the system keychain. crates/compose is described as a state machine with a DAG executor, and the front end wires xstate into that, so the pipeline state is not just a Rust-side concept.

The interesting trade-off is that the agents are Rust-native rather than a Python orchestration layer. That keeps the app a single binary and avoids shipping a Python runtime, but it also means adding a new provider is a Rust change unless it goes through the WASM plugin runtime in crates/plugin, which the README mentions only as a crate comment.

Building splicr from source and running the first project

The README's local development section is short and assumes a Rust and Node toolchain already present. The badges state Rust 1.85+ and the workspace Cargo.toml repeats rust-version = 1.85, so that is the floor. The four documented commands are:

git clone https://github.com/Agions/splicr.git
cd splicr
pnpm install
pnpm tauri dev

pnpm install pulls the React 19 front end, and pnpm tauri dev starts the Tauri desktop shell. Note that package.json defines predev and prebuild hooks that run pnpm gen:ipc first, so the Rust-to-TypeScript IPC bindings are regenerated before the app starts. If you skip pnpm and run cargo directly, you are bypassing that step.

For a release build, the Makefile wraps the same thing. make build-tauri calls pnpm tauri build, and the Makefile comment states that three-platform artefacts are produced by CI rather than locally.

make build-tauri
make test

make test runs the Rust workspace tests plus the front-end vitest suite. The README also gives cargo test --all and pnpm test as the direct equivalents.

On macOS, the README documents a Gatekeeper problem for downloaded builds: the installer may report 已损坏, 无法打开 because the file is unsigned. The stated fix is to clear the quarantine attribute:

sudo xattr -rd com.apple.quarantine /Applications/splicr.app

The README notes that older builds use the path /Applications/vynaro.app instead. That command is a workaround for an unsigned build, not a security recommendation, and it is the clearest signal in the README that official signed binaries are not the distribution path.

After the app opens, the first real task is to configure a model. The README lists eleven providers, including Qwen, DeepSeek, OpenAI, Claude, Gemini, Kimi, GLM, Doubao and Hunyuan, plus local Ollama and LMStudio. The settings screen is where those are entered. The README does not document a config file format, so provider setup happens in the UI and is persisted through crates/storage.

Where the pipeline will let you down

The README advertises millisecond alignment with a sub-18ms deviation figure and a QualityReviewer score of 98/100. Those numbers appear as feature claims in a table, not as results of a published benchmark, and there is no method described for how either was measured. Treat them as design targets rather than guarantees.

The bigger gap is failure behaviour. The README does not document rollback, partial-run recovery, or what happens when an LLM provider returns malformed script output mid-pipeline. crates/storage is described in Cargo.toml as supporting 断点续传, which suggests resumable projects, but the README never explains the granularity: whether a resumed run restarts the current agent or the whole seven-step sequence. If you are processing a long episode and the run fails at the compose step, that distinction decides whether you lose minutes or the whole job.

Provider dependency is the second exposure. The pipeline needs both an LLM and a TTS backend. Edge-TTS is network-dependent; GPT-SoVITS and the local models are not. The README lists the engines but does not state which ones work offline end to end, so an offline workflow is an assumption you have to verify rather than one the documentation supports.

Finally, the model names in the README are unusual. Entries such as qwen3.8-max, gpt-5.6-sol and claude-sonnet-5 do not correspond to model identifiers in wide circulation. Whether these are internal aliases, forward-looking names, or errors in the README is not something the repository explains. If a provider call fails, that list is the first place to check.

splicr against Auto-Editor and FFmpeg scripting

The nearest open source comparison is Auto-Editor, which also uses FFmpeg under the hood but takes the opposite approach. Auto-Editor is a command-line tool: you give it thresholds and it cuts silence or motion out of a video, and the output is a rendered file. It has no notion of narration, no LLM step, no voice cloning, and no project file for another editor.

splicr inverts that. The cutting step is one agent among six, and the deliverable is a CapCut .draft that a human finishes. Auto-Editor is better if you want a deterministic, scriptable cut with no model calls and no GUI, and it runs happily in CI. splicr is better if the editing decision itself is the part you want automated and you are willing to accept a non-deterministic LLM in the loop.

The other alternative is writing the FFmpeg pipeline yourself. splicr's crates/detect, crates/subtitle and crates/compose are essentially a packaged version of that work, with silencedetect-based VAD for subtitles and a DAG executor for the compose step. Building it yourself gives you control over every threshold; adopting splicr gives you the three-column UI and the agent orchestration, at the cost of the undocumented failure semantics described above.

Maintenance, licensing and the upgrade path

The repository is not archived. The last push was on 2026-08-28, and the most recent release is v1.0.1 from 2026-08-06, with v1.0.0 landing the same day. Version 1.0.1 is also the version string in package.json and the workspace Cargo.toml, and the Makefile reads the version from package.json as its single source of truth. So a release means touching package.json first, then the workspace version, then the tag.

The project ships a crates/update crate described as a cross-platform auto-update engine with version checking and SemVer, and the Tauri dependency list includes tauri-plugin-updater. Upgrades are therefore intended to be in-app. The README does not describe a downgrade path or a migration step for existing SQLite project data, which matters because crates/storage persists projects locally. If a schema change lands between versions, the README gives no guidance on what happens to projects created under the previous release.

Licensing is MIT, stated in the README badge, the LICENSE file and the workspace Cargo.toml. That is permissive and imposes no copyleft obligation on your output. It says nothing about the third-party services the pipeline calls: your LLM provider and any TTS endpoint have their own terms, and the MIT grant covers the splicr code, not those services. The README does not discuss this, and it is not a legal question this article can answer for you.

Editorial conclusion

Adopt splicr if you already cut short-form narration in CapCut and want the script, voice and timeline assembled locally rather than in a browser tab, and you are willing to build from source on Rust 1.85+ with pnpm. Skip it if you need signed macOS installers, documented rollback behaviour, or a headless batch pipeline, none of which the README describes. Before committing, verify two things yourself: that your chosen LLM provider and TTS engine are actually reachable from the settings screen, and that a draft exported by the current release opens in your CapCut version, since the export crate targets the .draft format and the README does not state which CapCut versions it covers.

Frequently asked questions

Official sources

1. Agions/splicr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases