Turn "what you want to shoot" into an instruction that Seedance 2.5 can execute accurately.
The first step is always clarification, not starting the render
When users arrive, they usually only have one sentence.First read references/intake.md, and follow the rules there:
- There are only three things you must ask them:how long, where it will be posted (aspect ratio), and one continuous shot or cuts
- For everything else (camera type, follow method, focal length, shot size, style anchor), infer from what they say first, lay the inferences out in a table, and let them veto
- Once the assumptions are laid out,show them a 3-5 line shot list first, and let them revise it in text. Changing one line of the shot list takes one second; changing it after the white model is built takes several minutes
The cost of skipping this step has been measured in practice: on 2026-08-15, all three white models had to be redone (one required rearranging all character trajectories, one required time remapping, and one could only be re-edited locally). The root cause was building the white models directly according to one's own understanding.
Four production lines
| Production line | Output | When to use |
|---|---|---|
| A · Prompts | T2V / R2V prompts that comply with the official specifications | At any time. This is the main line |
| B · White model | White-model video rendered with the scene.json engine | When precise control is needed over camera movement, spatial relationships, timing rhythm, and shot transitions |
| C · Reference image | Cinematic-grade reference images generated by Seedream | When materials, lighting, and shapes need to be locked |
| D · Photo reverse-engineering | Reverse-engineer a white model from the user's photo | When the user has provided a photo and wants to make this scene move |
Typical full chain:clarification → shot list → B makes the white model to lock camera movement → C makes reference images to lock texture → A binds the two into one prompt. If the user has provided a photo, replace B+C with D: that photo serves as both the spatial source and the material reference, and the two are naturally consistent.
Main-line workflow
E="$SKILL_DIR/engine" # SKILL_DIR = 本 skill 所在目录
# ① 写 scene.json（规范见 references/scene-spec.md，样板在 templates/scenes/）
# ② 渲染前体检——必须 0 个 🔴 才往下走
node $E/probe.mjs scene.json
# ③ 生成工程并渲染
node $E/build.mjs scene.json
npx hyperframes@0.7.107 lint
npx hyperframes@0.7.107 render --quality draft --output whitemodel.mp4
# ④ 抽帧自检——这一步没有替代品（体检查得了几何，查不了好不好看）
node $E/frames.mjs whitemodel.mp4 scene.json # 自动按镜头切点+段内均分挑
node $E/frames.mjs whitemodel.mp4 scene.json 0,7.5,15 # 或指定时刻
# ⑤ 从白模的实际几何生成 prompt（同时产出参考图提示词，产线 C 直接可用）
node $E/make_prompt.mjs scene.json > prompt.md
Single-frame preview (used when composing shots, about 30 seconds per round, and multiple moments can be given at once):
node $E/preview.mjs scene.json 0,7.5,15
Each frame also prints the camera facts at that moment (position/focal length/distance/height in frame) —if the image and the numbers do not match, the engine has a problem, do not just look at the image.
Iron rules
1. When terminology conflicts, Seedance 2.5 / 2.0 official takes precedence.
The official guides for Veo / Sora / Kling can be referenced, but are not adopted when they conflict with Seedance (see the three known conflicts at references/model-differences.md）。
2. Every reference asset must declare "what is inherited / what is not inherited". If "what is not inherited" is omitted, the model will bring over everything from the reference. This is the most important of all the rules.
3. Use technical terms, not adjectives. "Cinematic" can only be understood as "good-looking." You have to write Dunkirk, IMAX 65mm, Kodak Vision3, volumetric light shafts, side backlight. Empirical evidence: for the same scene, the adjective version produces stock-photo wallpaper, while the technical-terminology version turns directly into a film shot.
4. Negative constraints must be specific enough to "rule out which wrong category." Don't write "no low quality"; write "avoid white-model plastic feel" (wrong material), "no tutorial breakdown" (wrong narrative), "no arrow labels" (wrong graphics).
5. Don't bet on complex physics. All four official sources agree: the physical plausibility of complex motion (ball bouncing, objects thrown from height) and the stability of multi-subject interaction are both currently done poorly. The Seedance 2.5 official blog admitted this at the end itself. Kling officially also pointed out that the model is insensitive to numbers and cannot achieve quantity consistency for things like "10 puppies on the beach."
6. Every number in the prompt must be measured from the white model.
Not copied from the design draft, and not made up.make_prompt.mjs is responsible for measuring. If you change the white model, rerun it; don't hand-edit the numbers.
On 2026-08-14, two prompts were written according to the design draft: one promised "orbit in to 2 meters" (the white model was actually 3.4 m), and one promised "descend back to 12 meters" (actually descending would ruin the formation).
7. Passing mechanical acceptance does not mean the image is correct. lint all green, durations all correct, health check zero red, and yet five camera moves can still all be broken.After rendering, you must extract frames and look, and there is no substitute for this step. The reverse also holds:having looked at extracted frames does not mean the whole film is correct—you extracted the moments you picked, and the broken parts are often in the segment you didn't pick. So the order is: probe to find suspicious intervals → extract those frames and look, rather than uniformly extracting a few frames and declaring it passed.
8. With more than two people, positioning matters more than action.
What breaks first in a two-person scene is not whether the fight looks good, but thatthe two people overlap into one on screen. The criterion is not whether they are far apart in world coordinates—
when the camera deviates from the midline between the two, the more they are spread out longitudinally and the greater the depth difference, "the nearer person's lateral offset being magnified" will exactly cancel out the left-right misalignment,
world coordinates are perfectly distinct, yet on screen they completely coincide.probe.mjs will calculate this frame by frame and report red.
A oner is especially fatal: there is no hard cut to hide behind, so if it breaks, the entire take breaks.
Production Line A · Prompts
Read references/prompt-spec.md: the official four-part paradigm (duration and aspect ratio → reference binding → shot sequence → global constraints),@图片N / @视频N / @白模N reference syntax, timestamp notation, three reusable templates, and full official prompt samples (including a commercial case with 18 images + 3 audio tracks).
If you go with Production Line B, the prompt draft is generated directly by make_prompt.mjs , and you only need to fill in the narrative content.
Production Line B · White Model
Read references/whitemodel.md(workflow and self-check),references/scene-spec.md(field specifications),references/camera-rig.md(ten camera position types, shot-size distance table, multi-camera switching).
Core fact:the white model can be extremely crude. It only provides spatial relationships, camera-movement paths, and timing rhythm; all material details are left to the reference images. So time should be spent on camera movement and rhythm, not on modeling.
Production Line C · Reference Images
Read references/reference-image.md. Six-element formula (lose any one and it drops a tier): real title anchor, equipment specs, atmospheric medium, scale reference, dramatic lighting, live-action imperfections.
Which text-to-image backend you use doesn't matter; all the value is in the prompt itself. Two size points: output 16:9 at 2560×1440, and don't go below this tier on the long edge; if the reference image resolution isn't high enough, it will drag down the texture of the final output with it.
Pipeline D · Photo Reverse-Engineering
Read references/photo-to-whitemodel.md. Five steps: overlay a grid and read values → read vanishing point / camera height / ruler / focal length → build scene.json → render the first frame and compare side by side with the photo (converge in two or three rounds) → add motion and camera movement.
python3 $E/photo_grid.py 照片.jpg 照片-grid.jpg
⚠️ Always overlay a grid to read positions; never eyeball estimates. Measured on the same corridor photo: eyeballing gave a vanishing point of 0.40, while reading the grid gave 0.51; that 0.11 difference is a 5° pitch difference. Automatic vanishing point detection isn't trustworthy either—carpet patterns will throw it completely off.
A few empirical boundaries you can't get around
| Fact | Source |
|---|---|
| Single-segment limit 30 seconds, output 720P | Measured 2026-08-06 |
| 15 seconds usable (in manual mode, type 15 directly into the number box) | Measured 2026-08-16 |
| Final output 24fps, white model 30fps, cross-frame-rate cut point error < 1 frame | Frame-by-frame check 2026-08-16 |
| Single reference limit 30 images + 10 videos + 10 audio | Official |
| Subject occupies < 10% of frame height and displacement < 0.5 body height → the AI will drop it | Measured 2026-08-16 (in the last 4 seconds of the final output, only an empty altar remained) |
| The white model can lock down position, speed, timing, and spatial relationships,but it cannot lock down poses that violate common sense | A white model walking backwards was quietly corrected by the AI to walking forwards in the final output |
| The color of the white model subject will bleed into the final output | Blue crowd white model → a blue-masked crowd appeared in the final output |
Reference materials
| File | Content |
|---|---|
references/intake.md |
Requirement clarification: what to ask, what to infer, how to lay out assumptions |
references/scene-spec.md |
Complete scene.json field specification |
references/camera-rig.md |
Ten camera position types, shot size distance table, multi-camera switching |
references/whitemodel.md |
White model workflow, self-check, first-frame bugs, handwritten escape hatch |
references/photo-to-whitemodel.md |
Photo reverse-engineering pipeline |
references/prompt-spec.md |
Prompt specification + official samples + three templates |
references/reference-image.md |
Reference image six-element formula + pitfalls to avoid |
references/model-differences.md |
Comparison of four official formulas and three conflicts (for reference only, not adopted) |
templates/scenes/ |
Three scene.json samples you can modify directly |
templates/whitemodel-base.html |
Starter template for the handwritten route |
docs/index.html |
Explanation page for humans |
Methodology sources: ByteDance Seed's official Seedance 2.5 launch blog and official demo materials (with the original prompts alongside the final outputs), plus the official guides from Veo / Sora / Kling. See the source list at references/model-differences.md。
Version self-check (silent)
This section is for AI agents: before using this skill each time, first make an offline judgment—read the .last-update-check file under this skill's directory (the directory where SKILL.md is located) (its content is a single line with the date YYYY-MM-DD). If the file exists and is less than 30 days old, skip this section and get straight to work, without saying anything to the user about updates.
When it has expired or the file does not exist, and only then:
- This directory is not a git clone (no
.gitor no origin) → write today's date and skip this section - Compare versions:
git -C <本目录> rev-parse HEADandgit -C <本目录> ls-remote origin HEAD - Regardless of the result, write today's date into
.last-update-check - The two are consistent → say nothing; confirmed to be behind → first complete the user's current task, then append a sentence when finished: "This skill has a new version, you can use
git -C <本目录> pull --ff-onlyto update." Whether to update is up to the user; do not proactively perform the update