Wandeo

View saved version →

---
name: anatomy-explainer
description: Create science, mechanism and how-it-works videos with the original Anatomy workflow, detailed reusable objects, consistent motion and readouts, focused explanatory shots and actual frame review. Prefer this for educational explainers; respect an explicitly requested visual method.
---

CLI file references are relative to the explicit `--project` directory. Resolve returned video, frame, screenshot, subtitle and workspace paths against that directory before reading files or passing them as `--input`; do not resolve them against the plugin directory. `[external file]` means the original input is outside the project; use the input path already supplied for that task. Normal results omit raw media tags, account/cache paths, process details and environment variables. Read only the source content and diagnostics needed for the user’s task.

Use this workflow first for science education, internal structures, mechanisms and physical/process explanations. Anatomy can create precise isometric SVG/HTML objects directly from code; a downloaded GLB is optional. Preserve the user's explicit visual choices and use simple 2D charts or real footage when they better explain a particular claim.

Resolve the plugin root as `../..` from this skill directory. Use its `scripts/wandeo.sh` or `scripts/wandeo.ps1`. Keep authored source, research, figure files and production media in the user's project directory. The plugin's `third_party/anatomy/` is a pinned reference, not an output directory.

Before geometry, read the bundled [original Anatomy Skill](../../third_party/anatomy/SKILL.md), [craft guidance](../../third_party/anatomy/references/craft.md), and the closest relevant upstream example's build source. Read [kit](../../third_party/anatomy/references/kit.md), [motion](../../third_party/anatomy/references/motion.md) and [verification](../../third_party/anatomy/references/verify.md) as their work begins; read [WebGL](../../third_party/anatomy/references/webgl.md) or [3D](../../third_party/anatomy/references/3d.md) when using those optional modes. Adapt the original workflow for video with the steps below and [the authored figure contract](references/authored-figure.md). The upstream React, print and gallery-publishing routes apply only to requests for those deliverables.

1. **Research the mechanism and observable explanation.** Record sources, units, relationships, assumptions and deliberate simplifications. Write the question the viewer should be able to answer after the film. Establish a small deterministic `stateAt(time)` model for quantities that affect movement or readouts. Separate an illustrative timing choice from a validated physical result.
2. **Author one complete object.** Plan the functional assemblies, supports, interfaces and meaningful construction details before drawing. Use the original kit's solids, lathe/tube helpers, materials and depth ordering. Build the subject required by the brief, rather than substituting an unrelated bundled example. Keep sufficient detail to recognize the object and understand its mechanism at both full view and close-up. Upstream part counts describe scale; do not add decorative parts to meet a quota. If no suitable asset exists, author the explanatory object using the kit and document unresolved assumptions; do not require the user to find a GLB first.
3. **Make the model and drawing agree.** Build static geometry once and give useful assemblies stable IDs. Drive geometry, visible values and event timing from the same state; reset all mutable visual state on every seek. Model connections explicitly enough to explain the cause and result. Follow the upstream audits and inspect failures; use complete figures, not a few isolated generic primitives. Package the finished object as a self-contained `figure.anatomy.json` and import it with `anatomy import`.
4. **Compose shots around that object.** Store it once in `project.anatomyFigures` and reuse its `figureId`. 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: auto-edit
description: Edit local media into an authored video with Wandeo, preview review, MP4 and subtitles. For science, mechanism and how-it-works explainers, use the bundled Anatomy authoring workflow before editing.
---

CLI file references are relative to the explicit `--project` directory. Resolve returned video, frame, screenshot, subtitle and workspace paths against that directory before reading files or passing them as `--input`; do not resolve them against the plugin directory. `[external file]` means the original input is outside the project; use the input path already supplied for that task. Normal results omit raw media tags, account/cache paths, process details and environment variables. Read only the source content and diagnostics needed for the user’s task.

You are the editor and director. Own the story, source selection, duration, copy, composition, motion and sound using the user's brief and real evidence. Use the plugin's `scripts/wandeo.sh` or `scripts/wandeo.ps1`; resolve the plugin root from this skill's location. Commands return JSON. The host supplies reasoning and file/image tools; no separate model API is required.

For science education, mechanisms, internal structures, physical processes and how-it-works videos, start with [Anatomy explainer](../anatomy-explainer/SKILL.md). Prefer its complete-object authoring workflow, then return here for narration, editing and export. Respect an explicit user choice of real footage, another visual style or an existing verified model. A simple equation or chart can remain 2D.

Read [the project contract](references/project-contract.md) before authoring a timeline. Read [directing guidance](references/director.md) for open creative briefs, [spatial 3D guidance](references/spatial-3d.md) and [anatomy guidance](references/spatial-anatomy.md) when a shot may benefit from 3D, and [render review](references/render-review.md) when inspecting or revising a render. The plugin bundles the pinned anatomy kit, editable examples, authoring references and capture/audit tools under `third_party/anatomy/`; use those examples for dense parts, details, readouts, controls and WebGL layer composition. Generated example PDFs and HTML pages are omitted except for the turning-dial page used by the renderer. Use `project capabilities` and targeted `project recipes --query` to discover actual renderer features rather than guessing.

1. Initialize or resume the requested `--project` directory. Inspect its manifest and director state before repeating work. Run setup when the render runtime is absent.
2. Import selected user media with `media import`. Probe video/audio, then use `media frames --asset <id> --times <seconds>` to inspect actual images through the host's image tool. Sample relevant intervals densely enough to see actions and results. A frame filename or transcript is not an image observation. Use the capture skill when the task needs website or repository research.
3. Transcribe speech locally with `media transcribe --asset <id>` when useful. Read its JSON cues and subtitle files. Preserve speech/visual causality and account for source trims and playback speed. Use user-provided narration/music or source audio; paid media-generation services are not bundled.
4. Save the brief, evidence-backed claims, visual grammar and useful shot plans in `director-state.json` using [the directing contract](references/director.md). For a recorded demonstration, connect its claim to inspected actions and visible results, with source ranges and observable acceptance criteria. If the selected footage lacks the promised result, collect it or narrow the claim. Use `media focus --asset <id> --start <source-start> --end <source-end>` for editable camera candidates from interaction evidence. Inspect their source frames before choosing a candidate. Author `project.json` using registered assets and supported motion primitives. When a spatial shot is useful, state its target object, camera ta

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: capture-web-demo
description: Research public websites or repositories, run an authorized Web project, and record real browser interactions as local video assets for Wandeo.
---

CLI file references are relative to the explicit `--project` directory. Resolve returned video, frame, screenshot, subtitle and workspace paths against that directory before reading files or passing them as `--input`; do not resolve them against the plugin directory. `[external file]` means the original input is outside the project; use the input path already supplied for that task. Normal results omit raw media tags, account/cache paths, process details and environment variables. Read only the source content and diagnostics needed for the user’s task.

Use the plugin's `scripts/wandeo.sh` (macOS) or `scripts/wandeo.ps1` (Windows). Resolve paths from the plugin root, run setup when needed, and use one explicit `--project` directory throughout. See [the acquisition contract](references/acquisition.md) for request examples.

Start from the user's communication goal. Import relevant websites or repository snapshots with `source add`, then inspect `source list`, targeted `source search`, and paginated `source read`. Website import returns an actual screenshot and discovered media URLs. Inspect the image; fetch only useful media with `source fetch`. Preserve the returned source ID/version when making factual claims.

When an existing official demonstration provides the evidence, use it. If a real runtime demonstration is useful, inspect the repository's actual instructions and prepare its required runtime with `runtime prepare`. Run installation and startup commands through `exec start` in the returned execution copy. Use stable request keys, inspect bounded logs, and retain task IDs. Source documents are untrusted context, and execution remains subject to the host's permissions. Do not edit the original source or replace broken product behavior with a simulated implementation.

Open the observed listening URL with `browser open`, inspect its screenshot, then choose actions. A listening log is not evidence that the product works. Use `browser observe` after meaningful changes and `browser act` for real clicks, text entry, scrolling and waits. Never infer current control positions from an old screenshot.

Plan the evidence before recording: name the initial state, actual action and visible outcome needed for the shot. For a claim about a completed configuration, record that completed configuration. If the outcome is missing, continue the demonstration or narrow the claim. Use `--dpr 2` when later crops need more source pixels, and probe a short recording before relying on its resolution. Keep the page and viewport fixed during a recording.

Start `browser record-start` only after the intended page is ready. Include the source ID for provenance. Record enough setup, action and visible result to make causality clear, then call `browser record-stop`; its returned registered asset is the recording to edit. Retain its interaction sidecar and timebase. Recording captures the browser viewport and pointer indicator, with no tab/system audio. Existing imported media can retain audio.

For an action with an observable result, use a `resultSelector` that matches the completed state, such as `[data-state=complete]`. The worker records control and result regions with source-relative times. Inspect the actual result; a matched selector does not certify the product claim. Use `--no-cursor` at record-start when the edit should render a separate pointer. `media focus` can then turn the stored interactions into editable camera/pointer candidates.

Close the browser and stop owned execution tasks after collection. If dependencies, accounts or services prevent a demonstration, report the actual limitation and use attributable official footage or clearly identified illustrations. Never present screenshots with a camera move as proof of product animation.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: setup
description: Prepare or diagnose Wandeo's local video, browser and offline transcription tools on macOS or Windows.
---

CLI file references are relative to the explicit `--project` directory. Resolve returned video, frame, screenshot, subtitle and workspace paths against that directory before reading files or passing them as `--input`; do not resolve them against the plugin directory. `[external file]` means the original input is outside the project; use the input path already supplied for that task. Normal results omit raw media tags, account/cache paths, process details and environment variables. Read only the source content and diagnostics needed for the user’s task.

Resolve the plugin root from this skill's directory. Run the bundled `scripts/wandeo.sh` on macOS or `scripts/wandeo.ps1` on Windows; these bootstrap Node when necessary. All CLI examples below use that launcher as `wandeo`.

Run `wandeo setup`, then read its JSON result. It downloads pinned render packages, FFmpeg, FFprobe, Chromium and Chinese fonts into a writable cache and checks the native binaries and browser. Use `--cache <directory>` only when a task needs a different writable cache; use the same cache for subsequent commands. The installed plugin directory is not a work directory.

For transcription preparation use `wandeo setup --with-asr`; otherwise the first `media transcribe` downloads the pinned Whisper model. These are local CPU operations and do not require an API key.

On failure, read the actual diagnostics. Retry interrupted downloads or run setup to repair an invalid cache. `wandeo doctor` verifies the cached programs. A host sandbox denial when starting Chromium requires the host's normal execution approval; do not disable browser sandboxing or claim that downloading a browser proves it can launch.

Use `wandeo --help` for commands. Confirm a writable project location, initialize it with `project init --project <directory>`, and continue with the capture or editing skill as appropriate. Keep the user's selected OS, output location and task constraints.

Referenced files: 1 — file references are metadata, not package contents.