lov-image-creator

Image Maker

Generate images by purpose, create editable graphic-text layouts, or organize image prompts.

Triggers

Activate when

"Generate images by purpose, create editable graphic-text layouts, or organize image prompts."
“Create an image, designed graphic, or image prompt.”

Do not activate when

Only querying the description of this Skill, or requesting tasks unrelated to the above results; do not perform actual business operations.
When the user only wants a preview or review, do not enter the modification, submission, or publishing branches.

Execution boundary

A natural language request is sufficient to trigger; no legacy slash path, parameter interpolation, or designated assistant is needed. Explicitly parse the project, target files, options, and output location in the current request; use the file, search, CLI, and browser capabilities actually provided by the current host. Project dependency versions and external APIs must be verified at execution time; do not assume examples are current configurations. Bundled scripts resolve from the Skill root, and business files resolve from the target project root. Read the current state first, and protect existing uncommitted content and the staging area of other tasks. Analysis and preview requests remain read-only; modification, commit, push, deployment, and publishing are each executed according to the explicit scope of the current request. Do not bypass protections, automatically send messages, forcibly terminate user processes, or take the foreground. On failure, preserve the original diagnostic error.

Workflow

First distinguish between generating an image, editing an existing image, a design draft containing typography, and prompts only. Choose the mechanism based on user intent, and preserve the boundaries of reference images, text, brand assets, and purpose.
Prefer the image generation/editing tools provided by the current host, and pass reference images according to their input protocol. When the user only wants prompts, output only the prompts and must not claim an image already exists.
Use external APIs only when that channel is authorized and credentials are configured; first verify the current production model and official endpoint, do not pin outdated models, do not install global Python packages on your own, and do not scan other projects' keys.
When posters, cards, etc. require editable text, HTML/SVG and installed typography tools may be used; check Chinese coverage against the actual fonts, use reliable static layouts, and do not reference nonexistent React UMD versions.
After generation or editing is complete, inspect the final file to verify composition, text, reference consistency, dimensions, and transparency; do not use pure image generation to fabricate real logos, source photos, or event evidence.
Save to the user-specified location or the project output, read back the actual file, and display the result. Do not automatically open foreground applications, upload, or publish; the old API scripts are no longer the default execution entry point.

Composition

Before execution, read capability combinations, and hand off to adjacent capabilities according to the explicit artifact.

Runtime context (shared)

Before running, read this package's skill.yaml and Profile contract. Priority is the current request, project context, this Skill's records, shared preferences, brand/user Profile, and safe defaults. Read only declared fields; hosts without a dedicated runtime may use scripts/profile_store.py to read the shared Profile. For missing configuration, ask only one question that affects the result. Values the user explicitly requests to save long-term are written atomically through that script, and the actual path is reported; do not save inferences, credentials, or information from other tasks.

General feedback loop

When the user provides modification feedback during a Skill-driven task, the following must be executed before continuing with the current artifact:

First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
task-specific Only modify the current task, not the Skill.
reusable First determine the scope: for domain rules, update the corresponding canonical Skill first; for rules that apply to all Skills, update the shared specification first.
After completing the rule updates, versioning, lint, and distribution verification, then apply the changes to the current task.
reusable Modifications will invalidate prior "confirm," "continue," and "send it" instructions; after completing the current artifact modification and reading it back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, committing, or any other external write.