This skill is only responsible for safely delivering already-written production specifications to the adapter configured in the runtime environment. Image prompts remain the responsibility of , video prompts belong to , dialogue and recording sheets belong to , and voice identity belongs to .

Only after the creator explicitly requests actual generation, take the current prompt from , , or , and create a bounded run job. A creator-first job's must point to the current Markdown that owns this prompt, and must name the document's allowed secondary heading: uses , uses , uses (modality is , body is taken from that shot's ). This selector only extracts the first frame; the tail frame must first be established as a separate state-graph entry by the image prompt stage, and then an image job is prepared from . Creators may also provide an existing start frame—generating the image in their own tool and placing it into the project is equally valid; if images never enter the project, use from the storyboard; after the output lands in , the storyboard owner can bind it as a with . When real reference images exist, you must also fill in each slot of with order, path, Chinese name, purpose, and the allowed/forbidden control scope; the built-in video adapter reads the field here as the vendor's own role and only accepts its published values (MiniMax uses ////, Seedance uses three values); a job with reference images but no bindings will fail directly—it will not guess a role. Local images are sent by the built-in adapter as base64 data URIs directly; no self-hosted upload service is needed. When an entry's "input reference image" is written as , those images live in the creator's own tools and there is no file in the project to send: fails directly and explains that real files must first be placed in the project and rewritten as ; it does not use the plan as input and does not silently drop references. can be omitted and generated from binding order, or provided as an explicit mirror in the same order. Output goes to ; this job is a temporary input for the production tool, not a sixth creation document:

python3 {skill_directory}/scripts/production_tool.py prepare <project> --job <temporary-job.json>

First show the complete preview from ; no vendor is called at this point.

Every production must go through the following four steps, in order, and they cannot be merged:

If the job, prompt, parameters, output path, or direct input change in any way, the old confirmation immediately becomes invalid. You must not fill in confirmation on behalf of the creator. The currently confirmed job is the only work unit for this round; after execution completes, report the result and return control, without automatically preparing the next batch or starting review.

The "input reference image" path in is only a readable basis and usage intent during the creation stage, not a production-input snapshot. When entering production, a creator-first job must establish bindings from the corresponding entry in or ; the , , and the confirmed job shown by are the authority for which file bytes the adapter actually reads this time and what each is allowed to influence. Non-creator structured specs may omit / and continue using only explicit ; but any new image/video job whose points to canonical or is forced to use the corresponding selector and cannot downgrade by omitting fields. Old jobs that were prepared and written to disk before the upgrade can still be read by their original fingerprint. New production results are not automatically backfilled or refreshed into the storyboard; if they need to become subsequent input, the storyboard owner revises the document, then creates a new job and re-previews and re-confirms it.

Only after entering the production boundary, write the current prompt and run parameters as a temporary JSON; for video and image jobs, the follows the prompt language already parsed from the current copyable body, so that adapter-appended reference constraints use the same language instead of falling back to fixed English. Do not pre-create jobs for every prompt during the creation stage. Format and adapter contract are in adapter-contract.md. Commands are provided by production_tool.py, then run:

python3 <this-skill-directory>/scripts/production_tool.py prepare <project> --job <job.json>
python3 <this-skill-directory>/scripts/production_tool.py confirm <project> --job-id <id> --confirmation "CONFIRM <id> <code>"
python3 <this-skill-directory>/scripts/production_tool.py run <project> --job-id <id> --adapter-config <outside-project-config.json>
python3 <this-skill-directory>/scripts/production_tool.py status <project> --job-id <id>
python3 <this-skill-directory>/scripts/production_tool.py collect <project> --job-id <id> --adapter-config <outside-project-config.json>
python3 <this-skill-directory>/scripts/production_tool.py audit <project>

only validates and previews; it does not produce. only saves a one-time confirmation bound to the current job fingerprint. is what starts the adapter. only retrieves the result of a task that was already submitted and already billed; it does not resubmit and does not need new confirmation—see "Interruption Does Not Mean Re-running" below. only reconciles the local task history, post-failure recovery, duplicate content attempts, and current output bytes; it does not call vendors and does not write technical success, file existence, or hash consistency as media-quality conclusions. While an unresolved attempt exists for the same job, re-running prepare, confirm, or run is forbidden; first wait for completion or investigate the leftover attempt.

A single job does not mix modalities. Large batches are split into small jobs where the creator can see clear quantity and cost boundaries; do not implicitly stuff an entire season into one confirmation for convenience.

Adapter configuration must live outside the project and contain only the argv command and timeout; credentials are read by the adapter itself from the process environment or system credential store. Project jobs, confirmation records, run logs, and Dashboard must not store secrets.

The script invokes the argv array via JSON stdin, does not use a shell, and does not concatenate commands. The adapter returns local temporary files; the tool only accepts results that exactly match the confirmed targets, and atomically copies complete files into the project directory. The project and upstream Skills do not hardcode vendors, models, or soon-to-change APIs.

The built-in image/video compiler appends a deterministic reference-semantics note to the vendor prompt (Chinese name, purpose, allowed control, and forbidden control scope) in order, based on the confirmed ; it does not mistake slot names for text to be rendered into the frame. External adapters must also preserve this semantics or explicitly refuse, and must not silently lose control boundaries by merely uploading files.

This skill optionally provides four stdlib adapters, all selected via an out-of-project adapter config, with credentials read only from the runtime environment:

These adapters are validated request contracts, not guarantees of account availability or generation quality; formal production must still pass the above per-confirmation gate, and a review Skill judges the quality of the output.

The repository's is for offline testing only and does not represent real generation quality or the default production adapter.

A video task is billed at the moment of submission, not when the result is received. Everything after submission—polling for minutes, downloading— can be interrupted by a killed process, network loss, or machine sleep. The built-in adapter therefore writes the vendor task ID into as soon as it receives it (before the first poll), and this path is not deleted with this attempt.

So after an interruption, there are three deterministic actions that avoid spending again:

Do not resubmit directly when

audit

reports

orphaned_provider_job

—that would be paying a second time for the same shot. It is intentional that does not go through the confirmation gate: the gate prevents accidental spending, and collect does not spend; if it also required re-confirmation, the cheapest path after interruption would become paying again, exactly what the gate is meant to prevent.

On success, report the actual output path, media type, and run status; do not write "adapter returned success" as a quality conclusion. After multiple tasks or retries, first run : terminal failures route via ; retries still require new explicit confirmation; if output is missing or a file's hash or size no longer equals the run record, first recheck the current bytes or re-produce. is only a cost and diagnostic signal; it cannot automatically determine whether the same-text retry is reasonable or unreasonable; is a pending operational status, and audit must return attention. Failures are routed three ways. Technical failures such as timeout, throttling, and server errors can be retried with a cap. When the failure message names which input was rejected— prompt text, reference image, or audio—fix that item before resubmitting: if text was rejected, rewrite that sentence, changing "fist slams into the other's face, blood drips along the chin" to "fist swings empty, the other sidesteps, the cup on the table is knocked over"; if the reference image was rejected, replace it with an image whose composition and character are consistent and whose content is compliant; if audio was rejected, re-record that line. Write the change into a new job and re-run prepare, letting the creator see in the preview which item changed, then confirm; resubmitting the same content without change produces no fix, only a charge. Duplicate-content defects return to the corresponding prompt/spec owner. Production does not automatically enter editing. When the material needs to be assembled into a final cut, the user names ; it only selects among existing frames, and does not retroactively change jobs from this stage or generate new material. If quality review is needed, the report can hand existing results to separately; do not auto-start review from within the production call. The Dashboard is only for displaying these files and run summaries; it does not provide adapter settings or production buttons.

Run offline self-tests only during installation, upgrade, or troubleshooting; not during normal creation or production preparation:

python3 scripts/selftest.py
python3 scripts/provider_adapters.py --selftest