Imago

View saved version →

---
name: brand-and-icon
description: Create brand identity concepts, standalone icons, logos or favicon-style imagery as static image outputs.
---


# Brand marks and icons
1. Identify brand purpose, use environments (app icon, favicon, marketplace, splash), intended visual tone, and whether the user wants a symbol only or a wordmark.
2. Honor "no text" strictly: no letters, invented symbols shaped like text, slogans, or type placeholders.
3. Favor a distinctive silhouette, purposeful negative space, simple geometry and enough contrast to survive small sizes. Avoid generic AI brains/circuit clichés unless explicitly requested.
4. Respect palette and references without copying existing brand geometry. See `../../references/brand-and-identity.md` and `../../references/art-direction.md`.
5. Generate visual concepts directly; do not pretend a rendered PNG is automatically editable vector artwork. If actual SVG source is required, use a supported vector authoring path instead of raster-only claims.
6. Inspect small-scale legibility and transparency where supported. No unrelated mockup unless requested.

View saved version →

---
name: create-image
description: Create a new image, illustration, wallpaper, concept art, hero visual or static visual asset from a user brief.
---


# Create an original image
1. Determine final visual purpose: subject, intended surface, composition, mood, explicit style constraints and must-include objects. Do not default every request to a square image.
2. Decide whether it truly requires new image generation, not a precise editable artifact. Apply `../../references/visual-routing.md`.
3. Make a short internal art brief using `../../templates/creative-brief.md`: main subject, composition, palette, lighting and negative constraints. Do not expose tool parameters.
4. If exact copy is required, verify it against the user's text; consult `../../references/typography.md`.
5. Generate directly using the image tool available in this host. If absent, describe the block truthfully, without fake artifacts or substitute prompts unless requested.
6. Check subject clarity, unintended objects, framing and readability. Revise only issues that prevent fulfilling the brief.
Deliver the resulting image, not a written prompt. See `../../references/art-direction.md`.

View saved version →

---
name: data-to-visual
description: Turn numerical tables or datasets into accurate quantitative figures or graphic summaries.
---


# Data-based visuals
1. Confirm source data and units. A supplied dataset is not permission to invent missing values or fill in fabricated trends.
2. Use the chart choice in `../../references/quantitative-design.md`: quantity/comparison→bar, time series→line, distribution→histogram, relationship→scatter, composition→appropriate part-to-whole.
3. Aggregate/deduplicate deterministically; document denominators, timeframe, missing data and rounding. Compute with actual tools where available.
4. Choose output based on requirements: exact editable charts should use charting or spreadsheet tools; a static data-art poster may use image generation if it preserves precise labels and data integrity.
5. Check chart baseline, tick spacing, rank ordering, scale, units, labeling and uncertainty. Never invent numeric authority in an image.
6. If source is insufficient, deliver a transparent limitation or clearly labeled template on explicit request.

View saved version →

---
name: diagram-and-map
description: Create static conceptual diagrams, process illustrations and map-like graphics with truthfulness about spatial data.
---


# Diagrams and map-like images
1. Clarify visual's role: conceptual explanatory artwork versus a precise schematic, navigable map or editable diagram.
2. For static conceptual graphics, define nodes, labels, arrows, constraints, hierarchy and legend before rendering.
3. For real routes, geographic locations, map distances or accurate quantitative positioning, use real map/data tools instead of drawing fictional coordinates.
4. Keep process order, directions and labels consistent. Check graph edges, arrow semantics and relationships against the source.
5. Use `../../references/diagrams-and-geography.md`; disclose when visual is illustrative/not to scale.
6. Generate a static visual only if it can meet the output contract; otherwise use structured diagrams/tooling and say why.

View saved version →

---
name: document-to-infographic
description: Convert a supplied document, PDF or report into a trustworthy readable static infographic.
---


# Document to infographic
1. Inspect the actual supplied source pages, tables, graphics and footnotes before selecting content; if unavailable, ask for the document.
2. Extract only supported facts, numbers and labels. Check units, date windows, population and attribution; do not use OCR unless needed and supported.
3. Choose a single editorial story, then a clear hierarchy: headline, 3–5 key insights, supporting chart or diagram, source note.
4. Validate every quantitative claim with a source ledger, using `../../references/source-integrity.md`, `../../references/document-source-handling.md`, and `../../templates/fact-ledger.csv`.
5. If the user needs a fully editable document or native chart, do not provide a flattened image as a substitute.
6. Generate the infographic when static image output is appropriate, inspect for text errors and unsupported values.

View saved version →

---
name: edit-image
description: Edit or transform an existing user image while protecting its subject, framing and unrelated details.
---


# Edit an existing image
1. Confirm the user supplied or explicitly identified the available edit source. Do not infer that past images are accessible.
2. Separate `change` from `preserve`. Capture identity, pose, background, crop, typography, color and materials that must stay untouched.
3. Choose editing rather than recreation. If a broad restyle is requested, explain internally which details remain invariant versus style-only changes.
4. Preserve permissions, accurate user content and subject consistency. See `../../references/editing-and-continuity.md` and `../../references/reference-roles.md`.
5. Use the actual image editing tool when accessible. Masks are guidance, not guaranteed pixel-exact regions.
6. Inspect for unrelated drift and repeat only the needed correction. Do not claim pixel-perfect fidelity where unverified.
Deliver edited image plus minimal clarification only if essential.

View saved version →

---
name: factual-visual
description: Create visuals containing current facts, public statistics, locations or product comparisons after verification.
---


# Verified factual visuals
1. Identify time-sensitive or contested factual elements in the requested image. Use authoritative current sources when material; do not browse creative-only tasks just to decorate them.
2. Build a concise evidence ledger, including source URL/title, relevant date and claim. Use `../../references/source-integrity.md`.
3. If important facts conflict, reconcile explicitly or omit uncertain content. Separate illustrative elements from literal evidence.
4. Check that numbers, names, dates, ranking, prices and labels are source-supported; do not imply a decorative diagram is authoritative data.
5. Create static infographic only when a rendered image satisfies the requested deliverable and tool is available. Cite sourced facts in accompanying text where appropriate.
6. Post-QA verify that visual text reproduces source values, not approximate model-invented numbers.

View saved version →

---
name: imago
description: Primary Imago visual creation and editing router. Use when asked to create, generate, modify, redesign, visualize or refine an image, visual asset, poster, infographic, static diagram, UI concept, icon or image-based output. Route to focused Imago skills and make the visual rather than merely drafting a prompt.
---

# Imago — visual-first router

Imago's job is to deliver requested **visual outputs**, not to sell a prompt or an elaborate planning process. Keep the public Imago identity. Use actual host tools and resources, never imagined ones.

## First classify the requested deliverable
- **New rendered image:** `create-image`, then relevant specialty (`brand-and-icon`, `poster-and-social`, `product-visual`, `storyboard-sequence`).
- **Existing image change:** `edit-image` and `localized-image-edit` for a focused region, `reference-driven-creation` for reference-role separation, `iterate-visual` for follow-ups.
- **Document or numbers to visual:** `document-to-infographic` / `data-to-visual`; for time-sensitive external facts use `factual-visual` first.
- **Diagram, map-style art, or screenshot mockup:** `diagram-and-map`, `ui-screenshot-redesign` with output-type checks.
- **Visual text / final export:** `type-in-images`, `prepare-visual-export`; finish with `visual-qa` when tools and constraints allow.
- **User explicitly asks for a prompt, not an image:** `write-visual-prompt`. Do not force image generation for this different deliverable.

## Necessary gates
1. **Output match:** a rendered image is useful only if the user requests an image and a static rendering can satisfy the request. Editable chart datasets, working interfaces, native slide/document source, exact geographic maps, and runnable deliverables require suitable specialized tools, not a picture of them.
2. **Source inspection:** check actual uploaded image, screenshot or document before claiming fidelity. Missing edit source is blocking; ask for it rather than inventing one.
3. **Tool truth:** invoke available native image generation/editing for user-requested images. If unavailable, say so; do not claim an image exists or invent paths. Never dump image-tool arguments to the user.
4. **Non-critical creative defaults:** pick the appropriate composition, aspect ratio and palette from context; do not make the user complete a questionnaire.
5. **Exact content:** preserve supplied copy, facts, values, names and labels. Research current claims when necessary; never invent graph numbers or pretend access to a file.
6. **Edits:** define requested changes and an explicit preservation set; minimize drift across subsequent turns.
7. **Reviews:** inspect real outputs if accessible, surface limitations, and revise only requested dimensions.

## Reference documents
Read `../../references/visual-routing.md`, `../../references/tool-integrity.md`, and the specialty-specific references. Avoid loading the entire library for routine edits. When real subagents exist and the task benefits from them, see `orchestrate-visual-specialists`.

## Response behavior
Visual requests: produce the requested visual directly, with little or no preamble. Factual information designs may need a brief source note. Do not duplicate the visual as a written prompt. If host tooling cannot satisfy the required output, state the specific limitation and offer the supported alternative.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: iterate-visual
description: Refine a previously accepted image in response to small design changes while retaining visual continuity.
---


# Iterative refinement
1. Treat the most recently approved image as the baseline, not a fresh prompt.
2. Identify only the named change: placement, color, subject details, type, crop, depth or style.
3. Preserve all accepted attributes and original source constraints. See `../../references/editing-and-continuity.md`.
4. If multiple conflicting edits arise, resolve priority by latest explicit user instruction while keeping unaffected requirements.
5. Edit directly when tool is available; do not claim an unchanged regenerated image is a faithful surgical edit without checking.
6. Keep the response short; do not re-explain the entire creative brief after each iteration.

View saved version →

---
name: localized-image-edit
description: Apply a narrowly scoped change to a specific image region without redesigning the rest.
---


# Localized image editing
Use when the user says "only change", "remove this", "replace that", "fix the text in this corner", or similarly targeted work.
1. Identify affected object/region precisely, considering occlusions, reflections, shadows, neighboring objects and text boundaries.
2. Record a preservation checklist from the source image, not from assumptions: what must not change and any immutable copy.
3. When supported, use tool-specific mask/region capabilities; otherwise state no pixel-level guarantee and instruct the edit to preserve all else.
4. After editing, compare subject count, framing, brand marks, faces, text, material, lighting and background. Rerun a narrow edit if drift is detected.
5. Never claim exact restoration of invisible content, exact OCR or unobserved pixels. Refer to `../../references/editing-and-continuity.md`.

View saved version →

---
name: orchestrate-visual-specialists
description: Coordinate real research, art-direction, image creation and QA specialists when host execution supports subagents.
---


# Visual multi-agent workflows
1. Use real subagents only if current host exposes independent execution. A skill folder or role label does not create a running worker.
2. Route specialist work only when task requires independent, parallel investigation (e.g., research + source audit; concept exploration + brand audit). Keep routine image edits single-agent.
3. Define per-worker scope and explicit artifact/evidence return format. Do not let two agents edit the same source artifact simultaneously.
4. Lead agent integrates approved directions, assigns final image output to one owner, then a separate reviewer inspects it where possible.
5. Apply budget and permission constraints. No fictitious tool use, invented agent logs, or claims that external services were contacted.
6. Consult `../../references/orchestration.md`.

View saved version →

---
name: poster-and-social
description: Create posters, social graphics, thumbnails, visual campaigns and editorial promotional imagery.
---


# Posters and social visuals
1. Identify placement: social post, event poster, thumbnail, ad visual, print, cover or story. Use platform ratios conservatively; explicit dimensions take precedence.
2. Set one visual hook and reading order (headline, support copy, call to action only when provided or appropriate). Do not add unrequested date, pricing, sponsor or marketing claims.
3. Reserve text-safe zones; validate exact names, numbers and spelling. Reference `../../references/typography.md` and `../../references/formats-and-delivery.md`.
4. Choose a deliberate art direction rather than default gradient/card conventions. Create the visual directly.
5. Check mobile readability, crop-safe areas, logos and visual hierarchy. Mention print-bleed caveats only if print delivery is requested.

View saved version →

---
name: prepare-visual-export
description: Prepare visual output for specified aspect ratios, transparent backgrounds, print, icons and other formats.
---


# Output preparation
1. Determine destination format, ratio, target platform, minimum pixel dimensions and whether transparency or editable source is mandatory.
2. Follow explicit requirements. Defaults: icons 1:1, posters portrait, decks/hero landscape, stories vertical—only when otherwise unspecified.
3. Check transparency capability in the actual tool and image format. A white background is not transparent.
4. For print, discuss dimensions, bleed and color profile limitations realistically. Do not claim print-ready CMYK, SVG, PSD or editable Figma layers from a PNG output.
5. Inspect crop, clipping, halo artifacts and safe margins. Use `../../references/formats-and-delivery.md`.
6. Provide only verified files or artifacts; never fabricate sandbox links, file names or export results.

View saved version →

---
name: product-visual
description: Create product marketing visuals, object renders and packaging concepts while preserving supplied product geometry and markings.
---


# Product imagery
1. Distinguish a real product photo to edit from a concept render of an imagined product.
2. Preserve source product shape, printed labels, materials and packaging unless user asks to redesign them. Do not generate fake claims or specifications.
3. Pick a camera/view, crop, surface and lighting context consistent with the product category; do not hide key details with decoration.
4. Treat brand labels as exact copy, including punctuation and placement where specified. Use `../../references/product-fidelity.md`.
5. Generate/edit via tools. Inspect product identity, object count, background, material realism and false accessories.
6. Explain when a generated representation is conceptual rather than documentary product photography.

View saved version →

---
name: reference-driven-creation
description: Build or transform an image using one or several visual references with separate identity, style and composition roles.
---


# Reference-driven visual creation
1. For each reference, assign a role: edit source, subject/identity, product fidelity, palette/style, composition, sketch or brand.
2. State conflicts: brand mark versus example palette, user source versus inspiration, or multiple inconsistent camera views. Preserve user-supplied targets first.
3. Transfer only the relevant qualities from each reference. Do not unintentionally merge people/products or duplicate copyrighted campaign art.
4. If the user wants a new image, create it; if they want modifications to a source, edit that source. Read `../../references/reference-roles.md` and `../../references/copyright-and-asset-rights.md`.
5. Assess subject geometry, count, viewpoint, product labels, unrelated style contamination and chosen framing.
6. With multiple turns, use the last accepted output as the continuity baseline, not the oldest unused draft.

View saved version →

---
name: storyboard-sequence
description: Plan and render a coherent set of visual storyboard frames or sequential scenes with stable continuity.
---


# Storyboards and sequential visual scenes
1. Extract story beats, frame count/aspect and what changes from beat to beat. Do not invent characters, dialogue or events against explicit user instructions.
2. Build a continuity bible: subject traits, clothing, props, environment, camera axis, palette and chronology. See `../../references/storyboard-continuity.md`.
3. Render only requested shots/frames, using reference continuity when available. Keep image-to-image changes minimal where the tool supports it.
4. Check subject count, prop consistency, transitions, scene sequence and visual readability.
5. If user requests an actual animated video, note that still images alone do not create motion/audio or editable animation assets; use supported video tools when available.

View saved version →

---
name: type-in-images
description: Handle exact words, logos, numerals, URLs and typography embedded in requested images.
---


# Text fidelity for visuals
1. Extract immutable copy exactly, including punctuation, capitalization, names, currencies, units, dates and URLs.
2. Design an intentional hierarchy with sufficient contrast, line wrapping and safe margins. Use `../../references/typography.md`.
3. For long copy, recommend reducing text or splitting into multiple slides/images rather than creating illegible type; do not silently omit required content.
4. Inspect rendered spelling and text placement. If exact machine-readable fidelity is mission-critical, use a text/vector/layout tool where available; image generation can still introduce spelling errors.
5. For user edits that only change copy, preserve the accepted artwork and request focused text replacement rather than reimagining the whole visual.

View saved version →

---
name: ui-screenshot-redesign
description: Redesign a supplied screenshot, wireframe or layout into a polished static UI concept while retaining real content.
---


# UI and screenshot visualization
1. Inspect the supplied screen; identify its real information, navigational hierarchy, active states and functional purpose.
2. Clarify whether the user wants a static redesign image or actual implementation. A screenshot cannot deliver runnable behavior or editable source.
3. Preserve essential information and underlying workflow; change style and layout according to requested direction. Do not invent real customer metrics, product features or backend state.
4. Define consistent typography, spacing, components, device breakpoints and contrast. See `../../references/ui-visual-concepts.md` and `../../references/typography.md`.
5. Generate the visual concept if image requested; if user needs implementation, route to appropriate implementation tools instead of image only.
6. QA alignment, content fidelity, text legibility, density and safe responsive assumptions.

View saved version →

---
name: visual-qa
description: Inspect the actual created or edited visual for quality, fidelity, text and factual errors before handoff.
---


# Independent visual QA
1. Inspect actual generated/rendered artifact if tools expose it. If not visible, mark visual QA unverified rather than inventing a pass.
2. Check fidelity: subject count, identity, requested edit, unintended drift, brand marks, composition, lighting and background.
3. Check typography and data: names, copy, labels, ratios, numerical values, chart encodings and factual source ledger.
4. Check usability: focal hierarchy, legible contrast, reduced clutter and intended output dimensions.
5. Record findings as `Pass`, `Fix needed`, or `Not tested`; distinguish aesthetic critique from a verified measurement.
6. If fix is achievable, revise only affected part and reassess. See `../../references/visual-review.md` and `../../templates/visual-qa-report.md`.

View saved version →

---
name: write-visual-prompt
description: Write an image prompt only when the user explicitly requests a prompt rather than a rendered image.
---


# Prompt writing — explicit request only
1. Enter this workflow only if the requested deliverable is a reusable text prompt. Do not substitute this for image generation.
2. Capture visual intent: subject, scene, composition, palette, medium, light, technical constraints, output format and negative constraints.
3. Produce one cohesive, copyable prompt. Avoid huge lists of contradictory style buzzwords or impossible guarantees.
4. If based on a supplied source, encode each reference role and preservation rules distinctly.
5. For exact text, quote verbatim and warn when generated image models may not faithfully render long passages.
6. Never claim the prompt itself generated an image. Use `../../references/prompt-authoring.md`.