batch-montage-variants git:20260907.ac52fffA

Immutable. This exact content never changes and is served at /api/v1/blob/17efd7f131513130.

---
name: batch-montage-variants
description: |
  Turn one pool of existing project media into a batch of distinct, publishable montage cuts instead of a single hero edit.
  Use for batch montage, one-source-many-outputs, 一源多出, 批量混剪, 批量出片, 矩阵号, 多账号分发, variant batches, deduped cuts, 去重变体, 防搬运, or when the user asks for N different versions of the same footage.
---

# Batch Montage Variants

Use this workflow when the user wants **many** finished cuts from the same media pool — matrix accounts, A/B hook testing, platform variants, or daily batch output. The hard problem is not making one good cut; it is making N cuts that are each good *and* provably different from each other.

This is a OpenChatCut-native workflow. Use the current project, source assets, asset-frame inspection, AV/script context, and OpenChatCut editing tools. Do not depend on external download, transcription, ffmpeg, or auto-crop pipelines unless the user explicitly asks for an external source that is not already in the project.

## When to switch workflows

- One hero edit from many clips → **Multi Clips to Reels**. Do not use this skill to make a single cut.
- One long source defining a story → **Long Video to Shorts**.
- N distinct outputs from a shared pool → this skill.

Tell the user when you switch, and say why.

## Workflow

1. Read the project state before editing. Inventory the source pool: clip count, usable duration, aspect ratio, visual subjects, motion/energy, audio quality, and duplicates.
2. Confirm the batch is real: the user wants more than one finished cut, and the pool can support it. A pool that only supports one honest cut should be reported as such rather than padded into N near-duplicates.
3. Fix the batch contract before cutting — count, target duration, platform, audience, language, and whether cuts share a music bed or get distinct beds. If more than one is missing, ask in one `<widget>` after loading `widget-forms`.
4. Score every source asset for reuse headroom before planning. See [references/variation-matrix.md](references/variation-matrix.md). Assets that only work in one position (a logo end card, a single spoken punchline) are single-use; do not plan three variants that all depend on them.
5. Build the **variation matrix** before editing: for each planned cut, assign a distinct hook asset, a distinct shot order, a distinct rhythm shape, and a distinct packaging treatment. See [references/variation-matrix.md](references/variation-matrix.md).
6. Plan the dedup budget with [references/dedup-rules.md](references/dedup-rules.md). Decide up front which dimensions carry the differentiation, and record the minimum separation each pair of cuts must clear.
7. Get the matrix approved before cutting the whole batch. Show the plan as a table: cut number, hook, order signature, rhythm, duration, packaging, and the dimension that makes it different from every other cut in the batch.
8. Cut the first variant end to end and verify it renders and exports before batching the rest. Do not generate eight timelines that share one unverified mistake.
9. Cut remaining variants from the approved matrix. Reuse picks and trims where genuinely appropriate; never reuse the same opening three seconds.
10. Name timelines so the batch is auditable: `<topic>-v<NN>-<hook-label>`, consistent across the batch.
11. QA each cut individually **and** the batch as a set. See [references/dedup-rules.md](references/dedup-rules.md) for the pairwise checks.
12. Report per-cut timeline names, durations, the differentiation dimension for each, and which pair is the most similar — that is the pair the user should review first.

## Plan Format

Present the batch as one table, not prose:

| # | Hook asset | Order signature | Rhythm | Duration | Packaging | Differs by |
|---|---|---|---|---|---|---|
| v01 | clip_07 (product in hand) | A-C-E-B | fast-cut, 1.2s avg | 28s | bold captions + beat cuts | hook + order |
| v02 | clip_12 (before/after) | C-A-B-E | slow open, ramp | 34s | minimal captions + zoom | hook + rhythm |

- Total outputs, platform, shared vs distinct music bed
- Source pool size and reuse headroom
- Dedup budget and minimum separation
- Risks: thin pool, single-use assets, near-duplicate pairs

## Rules

- Every cut needs a different opening three seconds. This is the single most important rule; if two cuts share an opening, they are not distinct variants.
- Differentiate on **structure** before decoration. Changing only captions, color, or music produces variants that platforms and viewers treat as duplicates.
- Do not pad a thin pool into N cuts. Report the honest maximum and ask.
- Do not reuse a single-use asset as the hook of more than one cut.
- Keep one variable dominant per cut. When everything differs slightly, nothing reads as different.
- Batch output is not permission to lower the bar: each cut must stand alone as publishable.
- Do not use captions or titles to invent claims the footage does not support, in any variant.
- Report the most-similar pair explicitly. Hiding it defeats the point of the batch.