dreamina-3d-auto-seedance

Automatic Seedance Entry

Use when the user explicitly wants the validated Blender preview turned into a final Seedance video automatically rather than opened in Jimeng Web.

Capability Boundaries

✅ Can do

• Validate the local preview receipt and current SHA-256.
• Discover live Dreamina capabilities/account readiness.
• Obtain action-time approval, submit once, query, download and verify.

⚠ Requires user confirmation

• A paid request must have an exact model, resolution, duration and either an authoritative maximum-charge envelope or explicit auto_exact_request permission when Dreamina exposes no quote API.
• Dreamina authentication or Web compliance prerequisites may require user action.

❌ Out of scope

• Never send the .blend scene; send only the validated preview.
• Never resubmit after timeout or an unknown state.
• Never treat CLI exit zero or querying as Completed.

Workflow

1. Require PreviewValidated; independently re-hash the local artifact.
2. Instantiate McpDesignClient over the host's MCP tool invoker. It may call only dreamina_cli_status, dreamina_account, dreamina_submit_video, and dreamina_query_task.
3. Build the exact multimodal2video request from live capability data.
4. Never invent a quote. If none is available, stop unless the exact request has auto_exact_request authorization; native paid-action approval still occurs inside dreamina_submit_video.
5. Call dreamina_submit_video once and persist its submit ID before reporting Submitted.
6. Call dreamina_query_task for the same ID until success, failure, or Unknown; unknown permits query-only recovery.
7. Download into the approved root, verify media metadata, bytes and SHA-256, then and only then transition to Completed.

Privacy

Keep account identity, credentials, approval material and local absolute paths out of the cross-plugin ledger. Persist non-secret hashes, submit IDs, states, timestamps and error categories only.

When to use

Load this skill when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when the user wants a validated DCC preview turned into an approved Seedance video through Dreamina Design MCP. Covers submit-once recovery and verified download.

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, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when the result is unclear, query first and do not blindly retry.
• 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 precheck

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; 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 in minimally sufficient steps and record evidence at key state changes; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and no adjacent task was misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope of user authorization.
• The 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. Mistaking the plan for the result: documents or prompts are not the same as actual execution; the actual execution level must be stated.
2. Retrying after errors: 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, publish, overwrite, 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

Do not exceed the scope given by the user; writes, payments, publishing, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its content; hand off by skill name and preserve the current task context.

Progressive disclosure

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