dreamina-3d-use

dreamina-3d-use

When to use

The user wants a Dreamina 3D render but has not specified whether the source preview comes from Blender or Maya. This Skill routes to the right workflow.

Three explicit entries

• preview_only: produce and validate a local Blender/Maya preview, then stop at PreviewValidated without web handoff or paid submission.
• jimeng_web: delegate to dreamina-3d-jimeng-web and stop at JimengLinkReady. A ready link is not a submitted or Completed Seedance artifact.
• auto_seedance: delegate to dreamina-3d-auto-seedance; require approval, submit once, query the same ID, download, and verify before Completed.

If the user's intent does not distinguish these outcomes, explain them and ask for one choice. Never silently upgrade a local preview into a web or paid operation.

Report availability honestly

State each entry's availability before the user chooses. Do not imply a capability is production-ready when it is not:

• preview_only and auto_seedance are production routes on macOS + Blender.
• jimeng_web is OPTIONAL_UNAVAILABLE whenever the user-installed official uploader is absent. Report it as optional and unavailable, never as verified. Probe for it; never install or enable it to make the route available.
• dreamina-3d-from-maya is experimental with runtime status NOT_RUN. It is fixture-compatible only and is not part of the production release. Do not present Maya as production-ready, and do not route a user there without saying so.

Workflow

1. Discover companions. Call discover_companions(search_roots) from scripts/capability_probe.py. Do not crawl user directories and do not install anything.
2. Choose the companion. Call select_companion(candidates, requested=None).
   • zero companions: surface install_guidance() and stop.
   • one companion: route to dreamina-3d-from-blender, or to dreamina-3d-from-maya only after flagging it experimental.
   • two companions: ask the user to pick.
3. Select entry. Report availability per the section above, then apply the explicit route.
4. Delegate to the selected bounded Skill and stop.

Never do

• Never install or modify a companion plugin.
• Never skip the companion detection step.
• Never proceed to Dreamina submission before the preview is validated.
• Never report jimeng_web as production-verified while the official add-on is absent.
• Never treat JimengLinkReady as Completed.
• Never present the Maya route as part of the production release.

Gate signals

• Local preview status: PreviewValidated in the job ledger.
• Dreamina submission status: Submitted | Querying | Unknown in the ledger.
• Final artifact acceptance: Completed (only after result.sha256 is on disk and matches the declared hash).
• Web handoff status: JimengLinkReady, or OPTIONAL_UNAVAILABLE when the official add-on is absent. Neither is Seedance completion.

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 to turn a DCC preview into a Dreamina render without naming the source DCC. Routes the request to the right workflow.

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 stage status; when results are unclear, query first instead of blindly retrying.
• 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 prechecks

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 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 are consistent with the user's intent, and adjacent tasks have not been misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no guessed values have been used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope authorized by the user.
• 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 actionable next steps.

Gotchas

1. Mistaking the plan for the result: documentation or prompts are not the same as actual execution; the actual execution level must be stated.
2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-scale, publish, overwrite, and paid operations 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; write, paid, publish, and irreversible actions require explicit authorization. If the request requires a different skill, do not copy its body; hand off by skill name while preserving 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 rejection, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。