dreamina-opencli-image2image

dreamina-opencli-image2image — Jimeng image-to-image (opencli / standard member)

Aimed atno dreamina CLI standard members. This skillonly allows opencli jimeng registered subcommands,forbids dreamina、dreamina-cli-image2image and any dreamina installation instructions.

The edit prompt is provided by dreamina-prompt-image2image ; image-to-imageupload and click generateare done on the Jimeng web page (sharing the same Chrome login session as opencli).

opencli commands

Subcommand	Purpose
generate-image2image <prompt> --images <paths>	Image-to-image: upload 1–10 reference images + prompt (type=image）
history	verify works after submission
new / workspaces	Session management
user_credit	Credit check

--images is a comma-separated list of local paths, up to 10 images.generate is text-to-image only,does not includereference image upload.

Core workflow

1. PROMPT  → dreamina-prompt-image2image 定稿（Keep/Change）
2. SESSION → 可选 opencli jimeng new
3. GEN     → opencli jimeng generate-image2image "<prompt>" --images /path/a.png,/path/b.png [--wait 60]
4. VERIFY  → opencli jimeng history --limit N

Allowed opencli examples

opencli jimeng generate-image2image "将背景改为日落海滩" --images ./ref.png --wait 60
opencli jimeng generate-image2image "保持人脸，换装红色礼服" --images ./a.jpg,./b.jpg --workspace 12958724505868
opencli jimeng history --limit 10 --format table

Prohibited items

• Must not execute dreamina image2image、dreamina query_result , etc.
• Must not guide the user to install the dreamina CLI as a fallback.
• Must not use generate(without --images) to impersonate image-to-image.

Division of labor with dreamina-canvas-cli-image2image

The local execution path with the dreamina-canvas CLI installed is dreamina-canvas-cli-image2image(old dreamina image2image stopped being maintained in 2026-11, do not route there anymore); users of this skillshould notmix the two.

Agent specifications

• The prompt is handled by dreamina-prompt-image2image ; reference image paths are provided by the user, and generate-image2image uploads them automatically.
• status=success , fetch images from media_urls ;timeout , increase --wait or check history。
• If the user insists on "fully automatic": use generate-image2image，still must notswitch to dreamina.

Gotchas

1. Separate multiple reference images with commas; a single image that is too large (>15MB) will cause an error.
2. 2k/4k and 4.0+ models can be adjusted further on the web page, or --model(the page will attempt to switch).
3. Edit prompts should use Keep/Change to avoid rewriting undescribed areas.

When to use

Load this skill when the user needs to perform generation or write operations after explicit inputs, budget, and delivery constraints . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when the user is a standard (non-VIP) Jimeng member without the dreamina CLI and needs image-to-image on jimeng.jianying.com. opencli jimeng has no image2image subcommand; only generate, history, new, and workspaces are allowed. Pair with dreamina-prompt-image2image for edit prompts, manual reference upload on the Jimeng web UI in the same browser session, and opencli history for verification. Never invoke dreamina or jimeng-cli execution skills..

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that change external state.
• Least privilege: only use the files, tools, accounts, and network scope needed to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, clearly mark as NOT_VERIFIED。
• Idempotency first: retain 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 prechecks

Validate inputs, model/tool capabilities, output paths, budget limits, and approval status; when any critical 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 once per approval and record request identifiers; for ambiguous results, query first rather than resubmitting; retain an associable status or receipt for every external call.

Step 5: Verify delivery

Verify artifact existence, format, hash/identifier, cost status, and quality gates, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and no adjacent task has 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 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 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 indicated.
2. Incorrect retries: A timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: Batch, full, publication, overwrite, and payment 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 critical evidence before delivery.

Non-applicability and boundaries

Payments, publications, overwrites, uploads, or external writes must use the explicit authorization of the current task; do not automatically expand counts and budgets. If the request requires another skill, do not copy its body; hand off by skill name and preserve the current task context.

Progressive disclosure

• When inputs/outputs, states, and authorization points need to be determined, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, refusal of overreach, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。