dreamina-video-production

Dreamina Video Production

Orchestrate one reference video into one verified final MP4. Every step below is a separate Dreamina tool call; the project ledger is the only source of truth for what has already happened.

Example request

Use dreamina-video-production with /approved/input.mp4 in original-redesign mode.
Show the complete storyboard, task count, model specifications, and maximum credit
ceiling before requesting one whole-batch approval. Do not submit paid work yet.

Capability boundary description

✅ Can do

• Create and resume a private, versioned video project.
• Analyze a local reference video into shots, frames, contact sheets, and a typed recut.
• Plan exact Dreamina requests, quote the whole batch, and activate one non-expandable allowance.
• Execute, evaluate, compose, verify, and export the result with a comparison report.

⚠ Requires source material

• A local reference video inside an approved root.
• Enrolled trusted media tools (ffmpeg, ffprobe, and optionally whisper and a narration provider).
• Native confirmation for enrollment, rights, whole-batch approval, and export.

❌ Out of scope

• Do not call ffmpeg, ffprobe, or any local binary directly. Only the project tools may.
• Do not assert rights on the user's behalf. Only the user's literal assertion is recorded.
• Do not resubmit a paid request. Submitted, Querying, and Unknown are query-only.
• Do not treat a Jimeng Web link as Seedance completion.

Workflow

1. Read status first. Call dreamina_video_project with action=runtime_status, then action=get for an existing project. Never guess the current state.
2. Enroll tools when required. action=enroll_media_tools is a native-gated side effect. It binds each executable by absolute path, owner, and digest.
3. Seed and analyze. dreamina_analyze_reference_video with action=seed copies the source under containment; frames, sheets, and recut derive versions from it.
4. Annotate via the specialist. Hand contact sheets to dreamina-shot-annotator. Persist only through dreamina_validate_shot_analysis, which refuses a stale machine fingerprint.
5. Design. dreamina_create_redesign. original_redesign replaces expressive content; authorized_replication additionally requires a complete, unexpired, scope-matching rights assertion.
6. Quote, then approve. dreamina_quote_video_batch returns the exact request fingerprints and the total credit ceiling. dreamina_approve_video_batch activates one whole-batch allowance after native confirmation. An activated batch can only reduce work.
7. Execute. dreamina_execute_video_batch with run_next, reconcile, or resume. reconcile never submits.
8. Evaluate via the specialist. Measure first, then hand the measurement to dreamina-video-evaluator. The same semantic payload must never serve as both the design intent and the acceptance verdict.
9. Compose, verify, export. dreamina_compose_video, then dreamina_export_video_project, which verifies every required gate before it touches the destination.

Gate signals

• PreviewValidated / analysis version: local, deterministic evidence.
• JimengLinkReady: a web handoff finished. Never Seedance completion.
• Submitted / Querying / Unknown: paid, query-only.
• Completed: only after a downloaded artifact was independently re-hashed.

Never do

• Never skip the status read before a transition.
• Never let one semantic payload serve as both design and acceptance verdict.
• Never claim a skipped gate passed.

When to use

Load this skill when the user needs to perform generation or write operations after clarifying inputs, budget, and delivery constraints . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when creating a complete Dreamina video project from a local reference video, including analysis, redesign or authorized replication, batch generation, evaluation, audio, subtitles, composition, recovery, and verified export.

Rules

• Read before write: first confirm the current state and actual capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage state; when results are unclear, query first rather than retrying blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Perform pre-checks

Validate inputs, model/tool capabilities, output paths, budget limits, and approval status; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute according to one approval and record the request identifier; for ambiguous results, query first instead of resubmitting; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Verify artifact existence, format, hash/identifier, cost status, and quality gates, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and adjacent tasks were not misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no required values were replaced with guesses.
• All write, paid, publishing, or irreversible actions are within the user's authorization scope.
• Results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating the plan as the result: documents or prompts are not equivalent to actual execution; the actual execution level must be stated.
2. Erroneous retry: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-volume, publishing, overwriting, and paid actions are not natural extensions of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Paid services, publishing, coverage, uploads, or external writes must use the explicit authorization of the current task; do not automatically expand the number of times or the budget. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the context of the current task.

Progressive disclosure

• When input/output, status, and authorization points need to be determined, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, denial of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。