dreamina-3d-jimeng-web

Jimeng Web Entry

Use when the user explicitly asks to upload/open the Blender result in Jimeng Web or use the official uploader.

Capability Boundaries

✅ Can do

• Validate local preview readiness before a web handoff.
• Ask the Blender Connector to call the installed official uploader once.
• Report JimengLinkReady and open the link after separate user intent.

⚠ Requires materials

• Foreground Blender Connector and an enabled official uploader.
• An approved camera/range/output or an existing local video.

If the official add-on is absent, report jimeng_web=OPTIONAL_UNAVAILABLE and stop. State it as optional and unavailable — never as verified, and never as a production claim. Probe for the add-on read-only; do not install or enable it to make this route available.

❌ Out of scope

• Do not install or enable the official add-on.
• Do not persist Bridge tokens, URLs containing thirdparty_id, credentials, or private prompts.
• Do not submit, query, or retry paid generation.

Workflow

1. Confirm the Blender companion and call official_uploader.inspect.
2. Validate the local preview inputs. For camera rendering call official_uploader.render_and_link once; for an existing video call official_uploader.link_existing once.
3. Call official_uploader.status. Report only the redacted origin and JimengLinkReady state.
4. Call official_uploader.open_link only after explicit open intent.

JimengLinkReady does not mean Seedance submitted, querying, or Completed. Final artifact acceptance remains outside this route.

Privacy

Keep local scene/video paths and prompts private. Never expose loopback tokens or the encoded resource URL. The official add-on owns its Bridge lifecycle.

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 needs a validated Blender preview or existing video routed through the official uploader into Jimeng Web. Never claims Seedance completion.

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, explicitly mark them as NOT_VERIFIED。
• Idempotency first: preserve request identifiers and stage status; when results are unclear, query first rather than 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: Run 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 minimal sufficient steps and record evidence at key state changes; retain an associable status 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 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 writes, payments, 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 actionable next steps.

Gotchas

1. Treating the plan as 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, publishing, overwriting, 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; writing, payment, 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 input/output, states, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-checks are needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, denial of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。