Seedance 2.0 Skill OS: an agent skill for directing video prompts, not generating them

The gap Seedance 2.0 Skill OS fills between an idea and a paid render

Video models take a text prompt and return a clip. The expensive part is not the typing. It is deciding what the shot contains, which reference file controls which attribute, and how the next shot starts from where the last one ended. Seedance 2.0 Skill OS is an agent skill for that planning work. The README frames it as a way to "Turn an idea into a directed video prompt," and it is explicit that "Your video provider handles generation and its costs."

The intended user is someone already working with a video provider, or about to, who keeps getting results that miss one requirement. The repository's workflow table maps what you have to what you should supply next: a rough idea becomes an action, a feeling and a delivery format; a draft prompt becomes the constraints you want preserved; image, video or audio references become actual files plus the role each should control; an accepted clip becomes its observed ending plus the next action. That table is the clearest statement of scope in the README. This is a pre-generation tool, and the teaching example in the README is labelled "an unrendered teaching example" that "does not establish successful folding, motion or audio generation."

How the skill is structured: SKILL.md, references, scripts and schemas

The repository is shaped like a skill folder, not like an application. The top level holds SKILL.md, which Codex documents as the required file for a skill, alongside optional directories that match the documented convention: scripts/, references/, assets/ and agents/. There is also schemas/, evals/, tests/, validation/ and a set of lock files (requirements-masthead.lock, requirements-validation.lock).

The README states that a repository root with SKILL.md is shaped like a skill folder but still needs to be installed or copied under a scanned skills directory, or distributed as a plugin, before automatic discovery works. That is the central architectural fact: the checkout is inert until the installer places it somewhere the client scans. Codex scans .agents/skills locations from the working directory upward, plus user, admin and system skill locations.

The planning content lives in references/ and skills/. The README points to references/performance-example-cards.md, references/product-example-cards.md and references/continuity-example-cards.md for examples, and to skills/seedance-continuation/SKILL.md for continuation. Sequence-shaped examples sit under examples/: sequence-airport-arrival, sequence-mixed-lane, sequence-observed-deviation and standalone-clip. The installer stages and validates the repository before promoting it to <dest>/seedance-20, which means the copy that lands in your client is a validated one, not a raw checkout.

Installing the skill locally and getting a first prompt out of it

Installation runs from inside a local copy of the repository. The README gives the clone and install sequence for Codex user scope first:

git clone https://github.com/Emily2040/seedance-2.0.git
cd seedance-2.0
python scripts/install_codex_skill.py --client codex --scope user

After that, restart your client and select `seedance-20`. The README notes that a ZIP download works too: extract it and run the installer inside that folder. Nothing on the install page works until the clone or the unzip has happened.

The installer is not Codex-only. The README lists Claude Code at personal scope and project scope for an existing project, plus a generic destination flag:

python scripts/install_codex_skill.py --client claude-code --scope user
python scripts/install_codex_skill.py --client codex --scope project --project-root /path/to/project
python scripts/install_codex_skill.py --dest /path/to/client/skills

Choose either `--dest` or `--client` with `--scope`. Project scope requires an existing `--project-root` and, per the README, never guesses from your current directory. Add `--force` only to replace a complete existing install. No-option commands keep the historical `$CODEX_HOME/skills` or `~/.codex/skills` default and do not migrate old copies. The README also names a read-only `install_doctor.py` that takes the same destination options, which is the sensible thing to run before deciding on a replacement.

For a first real use, the README's own example is to tell your agent what happens and what must stay fixed. It shows this instruction:

Use seedance-20. A person finishes a paper fan at a workbench. Keep it quiet,
with one static shot and no music. Give me the prompt only.

The README says one possible draft is a locked tabletop shot with two hands finishing the last fold, a fixed camera and an explicit sound choice, and it explains why: one visible action, a clear endpoint, a fixed camera, and no music. Duration and aspect ratio belong in the provider's controls when that surface owns them. You should see a prompt back, not a video, and the README states a draft can be revised without submitting a paid generation request.

Client compatibility is tool-specific, and the README says so

The README is unusually direct here: "Client support for Agent Skills is still tool-specific." It links docs/HOST_COMPATIBILITY.md for tested revisions and what it calls explicit gaps. That document is the one to read before assuming your client works, because the installer can place files correctly while the client still fails to discover them.

The failure mode is quiet. If the destination is not a skills parent directory your client scans, the install reports success and the skill never appears. The README's own warning about a repository root with SKILL.md is the same problem in miniature: correct shape, no discovery. The installer prints where the skill landed, so the first check is whether that path is one your client scans, not whether the command exited zero.

A second constraint is concurrency. The README states that concurrent installers sharing a destination are serialized, and that automatic retry is limited to states where every authority record required by the phase is present, has flushed file contents, and on POSIX has a flushed containing-directory publication, and still validates. Each payload file is written under a transaction-derived sibling name, bounded by the recorded size, synced, and checked against the recorded digest. That is a careful install procedure, and it also tells you the failure surface: digest mismatches, incomplete publications and interrupted writes are the states the installer is designed to catch rather than paper over.

Where the skill is the wrong tool

It does not generate video. The README states that prompt preparation does not authorize paid generation, and that the provider handles generation and its costs. If your goal is to produce a clip without a video provider, this repository has nothing for you. There is no model, no renderer and no inference path in the described layout.

It also does not decide duration or aspect ratio when your provider's surface owns those settings. The README places them in the provider's controls. If your workflow needs the prompt to carry every parameter, this skill's division of labour works against you.

The teaching image is another boundary worth stating plainly. The README labels the paper-fan still an "AI-generated teaching concept, not Seedance output," and says it illustrates material, framing and light but does not prove the action or sound will render. Anyone reading the repository as evidence of output quality is reading it wrong. The evidence status section exists precisely to prevent that. Finally, the README warns that nothing on the install page works until the clone or unzip has happened, which rules out treating this as a hosted service you can point a browser at.

How it differs from driving a video model directly

The obvious alternative is writing prompts by hand against the provider's own interface, and the practical difference is where the structure lives. Hand-written prompts put the shot plan, the reference roles and the continuity notes in your head or in a scratch document. This skill puts them in a directory your agent reads: SKILL.md for the behaviour, references/ for example cards, skills/seedance-continuation/SKILL.md for the continuation case, and schemas/ for whatever validation the repository enforces through its validation/ and tests/ directories.

The second difference is cost timing. A hand-written prompt goes straight to a paid request. The README's workflow table treats revision as a separate step: a draft can be revised without submitting a paid generation request, and the retake protocol in references/retake-protocol.md is aimed at results that missed. If you already have a retake habit and a provider dashboard, the skill formalises it; if you prefer to iterate inside the provider's own editor, the extra directory layer buys you little.

The third difference is portability. Because the artefact is a skill directory rather than a saved prompt in one vendor's account, the README's installer can place it into Codex, Claude Code or a client-specific skills parent directory via --dest. The cost of that portability is the compatibility caveat above: the same directory that travels between clients can also land somewhere a client never scans.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-08. Two recent releases are listed: v6.7.0 (Seedance 2.0 Skill OS v6.7.0) on 2026-08-06 and v5.3.0 on 2026-05-08. The gap between those two release dates is roughly three months, and the version jump from 5.3.0 to 6.7.0 indicates the project does not follow a slow patch cadence. Upgrading means re-running the installer against the same destination, and the README's warning that no-option commands do not migrate old copies is the upgrade trap: an install that worked once can leave a stale copy behind if the destination changes between runs. The README directs you to run install_doctor.py with the same destination options before deciding on replacement, which is the check to perform on every upgrade, not only the first.

The licence is MIT, and the LICENSE file sits at the repository root. MIT is permissive, so the usual obligations are attribution and inclusion of the licence text in copies or substantial portions. That is a statement about the licence text, not legal advice, and it says nothing about the terms of any video provider you connect to. The README points to SECURITY.md and states you should review the security policy before configuring optional provider tools. If you wire credentials for a provider into the same environment, the MIT grant on this repository does not extend to that provider's terms, and the README's note that prompt preparation does not authorize paid generation is the relevant boundary.

Editorial conclusion

Adopt it if you already pay a video provider and your problem is prompt structure, reference roles and continuity across shots, because the skill is a planning layer you can inspect and revise for free before spending on a generation. Do not adopt it if you want a model, a renderer or a free way to produce video: the README states prompt preparation does not authorize paid generation, and your provider handles generation and its costs. Before installing, read docs/HOST_COMPATIBILITY.md for the tested client revisions and the explicit gaps, and check docs/INSTALL_SCOPES.md so the installer lands in the skills directory your client actually scans. Verify that your client is on the observed-compatibility list, then run install_doctor.py against the same destination options before you replace an existing copy.

Frequently asked questions

Official sources

1. Emily2040/seedance-2.0 on GitHub
2. Issues
3. License: MIT
4. README
5. Releases