/weftcut

name: weftcut
description: Drive the WeftCut video editor over its MCP tools. Use BEFORE calling any weftcut MCP tool, and whenever the weftcut MCP server is connected and the user wants a video or clip edited — cut, trim, tighten, remove pauses, add captions, titles, lower thirds or callouts, cut a social version — even if they do not name WeftCut; also to author or update a Motif (animated overlay).

Driving WeftCut

WeftCut is a desktop video editor; you operate it over MCP while the user watches the same project live in the app. Every mutation you commit lands in their undo history and on their screen. Each tool's own description carries its contract, and each refusal names its cause and options — this skill covers only what no single tool can: how a session should go.

In ten lines

The server sends these as its `initialize` instructions, so a client without this skill reads the same etiquette; the long form follows. Its last line names the server's version: if it differs from this skill's `metadata.version`, this copy is stale, so read `skill://weftcut/SKILL.md` (always the running version) instead, and replace this copy with the app's (Settings > Agent).

WeftCut is a desktop video editor; the user watches the same project live, and every edit you commit lands in their undo history. A video the user asks you to edit is the project open in WeftCut, named or not. 1. Read `project://tracks` (or `read_project` view "tracks") before your first edit; ids come from reads, never memory. 2. Every mutator answers with the committed record (minted ids, the span as it landed, `adjusted` for a grid snap); verify from it before reporting. 3. A refusal (isError) names the cause and the fix: act on it, never retry the call verbatim. 4. Times are microseconds on the frame grid: off-grid times are snapped and echoed, times outside their layer refused. 5. For a batch (rough cut, pause pass, captions): ask the user, then `begin_agent_session` (it checkpoints and locks the user's undo; `lock: false` opts out) and `end_agent_session` when done, on failure too. 6. Others may edit concurrently; when a commit fails for that, re-read and reapply. 7. Export: `start_export`; `get_export_status { wait_s }` for the completed output_path. 8. Edit the project open in the app; never create one unless asked. With none open, `open_project` or `create_project` the one the user named, else ask. A folder with project.json is a project; if it is not the open one (`project.dir` in `project://session`), ask. Its files change only through tools, TASTE.md aside.

Session etiquette

The ten lines above are the etiquette; this is what they leave out.

• The project open in the app is the one the user means: edit it in place.

A new project with their media re-imported is a copy they did not ask for. `project://tracks` says what each layer is (media, text, role, Motif, Group); without resource support, `read_project` serves the same views.

• A small change (a handful of calls) needs no ceremony: edit, verify, report.
• A batch job (a rough cut, a pause pass, a caption track) runs in a work

session. Ask before you begin one unless the user already agreed; it moves them to the agent view and locks their undo until you end it, so end it on failure too. Switching views neither starts nor ends work, and a user back in the editor has not ended your session. If another agent holds the session, ask the user before taking it over.

• Export when the user asks for a file, and report the completed output's path.

A dropped connection does not cancel an export; its status answers again.

Working in the project folder

When your working directory is a project folder (it holds `project.json`), it is the project the user means. Compare it with `project.dir` in `project://session`; if the app has another project open, ask before `open_project`.

• `project.json` is the app's to write; it autosaves over any edit of yours.

Read the project through its resources or `read_project`.

• `Media/` holds the project's media. Never rename, move or overwrite a file

there: the pool would lose it. New media goes in under a new name, through `import_media`. `Cache/` is derived data; leave it unread.

• `TASTE.md` is the one file you edit by hand (`project://taste` names where

it goes). Its tokens reach new layers; `restyle_to_taste` brings placed ones back to it.

• A file the user mentions goes to `import_media` as it is. Importing a file

the pool already holds answers its existing record, so it is also how a file is matched to its media id.

Batch jobs

Before a batch job, look in `recipes/` beside this file for a recipe whose description matches the job, and follow it. Read the files in `craft/` that touch the job: production rules as numbers, and anti-patterns, that hold under every style. Depart from one only when the user explicitly asks, and say so in your report.

Without a recipe, a batch job runs the same loop: read the state (tracks, open tacks, `project://taste`) → plan in plain words and get the user's go-ahead → build inside the work session → check the result against the plan and with `check_composition` → hand off. Build and check repeat at most three rounds. Whatever is still wrong after the third becomes tacks on the ranges it concerns and is named in your report — never retried silently.

**Style.** The project's style is `project://taste`; its tokens are already the defaults new text and captions take. Tag what you create with a `graphic_role` rather than styling it by hand: the role gives it the style's look and entrance. A role outside the built-ins must be declared in TASTE.md.

**Style Motifs.** A style that is mostly drawn lists example Motifs per role. They are examples, not a template: place one, fork it, or write a new Motif when the video needs something they do not show. Leave the style's shared props unset when placing, and keep them in a fork. *Style Motifs* in `motif-authorin