dreamina-3d-from-maya

dreamina-3d-from-maya

Experimental — runtime gate NOT_RUN. This Skill preserves fixture and contract compatibility only. It is not part of the current production release because no licensed Maya runtime has passed end-to-end acceptance.

When to use

The user explicitly requests the experimental Maya path and understands that its runtime acceptance is NOT_RUN. Do not route ordinary production requests here.

Workflow

Identical to dreamina-3d-from-blender, but:

1. Source DCC. maya-design — preview mode defaults to local_video.
2. Restore state. Confirm the Maya adapter reports restoration.status == 'confirmed'. Reject otherwise.
3. Camera. Maya cameras often have *Shape suffixes; pass through the user-supplied camera name verbatim.

All other steps (validate → capability → quote → approve → submit → query → download + verify) match the Blender workflow.

Ledger transitions

Same machine as the Blender workflow: Draft → DccSelected → PreviewSpecified → PreviewValidated → CapabilityResolved → Quoted → Approved → Submitted → Querying → Completed | Failed | Unknown.

Never do

• Never reuse a previous Playblast if the user has touched the scene since it was generated — invalidate the preview hash and re-export.
• Never send Maya scene data to the design plugin.
• Never auto-approve a quote.

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 has a Maya scene and wants a Seedance 2.5 render from it. Drives the Playblast through the validated Dreamina 3D pipeline.

Rules

• Read before write: first confirm the current state and real 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 output are missing, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage status; 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: Perform preflight checks

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 the minimum sufficient steps, and record evidence at key state changes; retain an associable status or receipt for every external call.

Step 5: Verify delivery

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

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and no adjacent task was misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no guesses were used to replace required values.
• All writes, payments, publications, or irreversible actions are within the scope of user authorization.
• 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: documentation or prompts are not equal to actual execution; the actual execution level must be stated.
2. Retrying 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, publication, overwrite, and payment 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, publications, 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 to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。