dreamina-3d-from-blender

dreamina-3d-from-blender

When to use

The user wants a Dreamina 3D render from a Blender scene. Companion blender-design is already installed.

Workflow

Automatic run policy

When the user provides one auto_with_budget envelope — approved reference upload, model/resolution/duration preferences, a maximum charge, and permission for one remote submission — perform the following workflow without asking at every state transition. Resolve capability, validate the preview, obtain and compare the quote, submit once only when it is within the cap, query the recorded identifier, download, and independently verify the final artifact. Return one final artifact inventory.

Stop and ask only when the quote exceeds the cap, a required reference was not authorized for upload, a platform-mandated confirmation or web prerequisite is pending, validation fails, or recovery would require another paid submission. interactive retains the review at each gate; review_only does not upload or submit.

Because Dreamina Design currently exposes no authoritative quote tool, auto_with_budget stops at QUOTE_UNAVAILABLE. The user may instead approve one fully specified auto_exact_request; that grants one submission only and does not bypass the native paid-action approval in Dreamina Design.

1. Inspect. Call inspect_scene(executable=blender_adapter, scene=<user_scene>). Reject if the scene cannot be inspected.
2. Specify preview. Collect user-approved camera, frame range, output path, and dimensions. Build a PreviewSpec.
3. Export. Call request_preview_export(...) with the user's prompt metadata embedded in the request payload. Independent re-hash is performed by the orchestrator — never trust the producer's declared sha256 alone.
4. Validate. Run validate_artifact(receipt, current_file) from scripts/handoff_validator.py. On any error, transition the job to Failed with the classified error_category.
5. Resolve readiness. Use McpDesignClient to call dreamina_cli_status and dreamina_account. On user action required, stop with the returned remediation.
6. Bind request. Build QuoteInputs(prompt, model, resolution, ratio, duration) and the validated preview reference. Record that an authoritative quote is unavailable; never synthesize one.
7. Authorize. Require auto_exact_request (or a future authoritative quote within auto_with_budget) plus reference-upload and one-submit flags.
8. Submit. Let McpDesignClient call dreamina_submit_video; Dreamina Design obtains native approval internally. Persist submit_id before reporting Submitted.
9. Query. Let McpDesignClient call dreamina_query_task for the stored identifier and approved download root. Unknown is query-only.
10. Download + verify. Re-hash the downloaded artifact and compare to the declared hash; reject on mismatch.

Ledger transitions

Drive the job through Draft → DccSelected → PreviewSpecified → PreviewValidated → CapabilityResolved → Quoted → Approved → Submitted → Querying → Completed | Failed | Unknown exactly once each.

Never do

• Never resubmit a job whose design_submit_id is already set.
• Never skip the preview validation gate.
• Never send DCC scene data to the design plugin — only the validated artifact reference (artifact_id + sha256), the user prompt, and the quote inputs.
• Never use the consumer plugin's internal design_handoff.py fixture for a production route. It is not shipped by this granular skill and exists only as a deterministic compatibility harness in the plugin test suite.

When to use

When the user needs to select and execute a verifiable, recoverable professional workflow for the current request , load this skill. First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when the user has a Blender scene and wants a Seedance 2.5 render from it. Drives the preview through the validated Dreamina 3D pipeline.

Rules

• Read before write: first confirm the current state and real capabilities, then execute 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 phase state; when results are unclear, query first and do not retry 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: Run prechecks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any key condition is unknown, stop at the read-only phase.

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 minimal 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, unfinished 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 adjacent tasks were not misrouted to this skill.
• The 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 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: a document or prompt is not equal 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, overwrite, and paid actions are not natural extensions of ordinary read/write operations.
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; write, paid, publishing, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When it is necessary to determine inputs/outputs, state, and authorization points, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation denial, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。