Runtime environment: must be used in Codex. Image generation, reference image editing, and brand scene images depend on Codex's image generation tool (imagegen). When triggered in environments without image generation capability such as Claude Code, do not pass off SVG/code collages as concept drafts; directly tell the user to switch to Codex to execute; if only doing research, discussion, or diagnosis and no image output is needed, you may continue.
Turn user preferences into stable graphics, then turn the graphics into usable assets. Enter the appropriate stage based on current evidence, and do not turn every invocation into a full brand project.
The common route is: positioning and purpose → aesthetic exploration → direction exploration → layered convergence → application validation → refinement and lockup → asset delivery. If a solution already exists, continue directly from the corresponding stage; for application issues, first fall back to composition, and only fall back to exploration for direction issues. When the user actively requests discussion, discuss first, and do not substitute extensive image output for shared understanding.
First determine what to solve now
Read the current conversation, user selections, and existing artwork. Look at actual reference images, and do not judge by file names. Briefly state the goal of this round and what will be retained.
| Current request or evidence | Action this round | Completion criteria |
|---|---|---|
| New product, no direction yet | Fill in key positioning and conduct a clearly differentiated visual exploration | The user can compare and point out preferred directions/features |
| Requests research, or is dissatisfied after multiple rounds | Query first-hand design cases and propose testable diagnoses | Distinguish direction, form, composition, and presentation issues; provide validation variables for the next round |
| Has selected a direction or version | Fix the baseline and perform controlled refinement | It is clear which change was effective, and the original version can be retained for rollback |
| Wants a full brand presentation | Show lockups and scenarios using the same master version | Consistent style, with parts not yet production-ready marked |
| Wants to use, save, or export directly | Establish a vector/high-resolution master, export, and check | Has actual files, usage instructions, and accessible paths |
When the user only wants research, do not automatically generate images; when A has been selected, do not reopen all directions; when export has been requested, do not stop at a presentation board. Do not repeatedly ask for known information. For missing information, only ask what would change the next step, and continue work that does not depend on the answer.
The quantity and scope given by the user take priority over the default exploration method. "Make a random one" means choose one from a reasonable creative space.Design proposition with evidenceComplete directly, and do not require multiple directions; random is not shape assembly without reason. "Make three different styles" means differentiating on formal categories, such as wordmark/letter, abstract symbol, character, or badge, rather than changing the same composition into three colors.
Minimal design state
Short tasks may remain in the conversation; when spanning rounds or beginning file delivery, write into the project's design record. Save only necessary content:
- Product and purpose: Whom it serves and its core function; mainly which sizes and carriers it appears on.
- Personality to convey: A small number of distinguishable words, plus clearly disliked feelings.
- Baseline: Specific files and version identifiers; if from a reference board, specify which cell.
- Locked features: Silhouette, color relationships, expressions, etc. explicitly selected by the user.
- Layer status: Record expression direction, silhouette, internal elements, color relationships, composition, and wordmark separately as selected/tentative/to be verified; selection at one layer does not automatically approve other layers.
- Current assumptions and variables: Why changes are made this round, and what alone is changed.
- Results: What the user said, which interpretations are still only designer judgment, and which versions were rejected.
Do not expand "I like this image" into approval of a new font, new slogan, application replacement, or release. Do not record a version recommended by the model itself as the user's choice.
In the first concept, colors, font directions, logo types, and usage scenarios supplemented by the designer all belong todesign assumptions; do not record them as brand specifications before the user explicitly chooses.
Positioning and research
Positioning is used to choose expression; it does not require the Logo to depict functions item by item. Distinguish roles/mascots, brand marks, wordmark lockups, and app icons: they may share identity, but need not share the complete composition.
When the user requests online research, prioritize official brand guidelines, original case studies from design firms, and designer retrospectives. For each case, extract: the problem, the approach, and applicable conditions; then explain the inferences for the current work. Provide first-hand links, and distinguish factual sources from your own visual judgment. The number of cases should be based on what is needed to answer the question; do not pile up a reference wall.
When research thinking is needed, read according to the question references/design-research.md, separating source facts, transferable principles, and verification actions for this round. Research must end with a design decision or the next round of comparison; historical cases do not represent current platform specifications, and when encountering redirects or dead links, do not pretend they can still be verified.
Borrow methods and constraints; do not replicate distinctive silhouettes or compositions. Do not claim originality or that similar trademarks have been ruled out merely because something is "AI-generated." General exploration does not expand into legal review; conduct similarity searches only when the user requests them, and explain the scope.
Page design style can provide product context, but it cannot directly lead to what the Logo must look like. Do not default to equating a certain type of product with gradients, starbursts, code brackets, or robots.
Exploration and feedback diagnosis
When the request is vague, the user wants to discuss, or it is hard to describe the aesthetic, first read references/co-design.md. Each round, give the user specific objects they can judge, and communicate around one main question; do not use long questionnaires, and do not make the user alone bear the work of "explaining the aesthetic clearly."
Before the first image output or batch exploration, read references/exploration.md, which includes the design state before generation and the delivery check.
In the early stage, meaningful expression directions, such as letter marks, abstract symbols, and character types; choose according to the request, and avoid passing off the same graphic with different colors as different directions. Silhouette and black-and-white relationships usually come before materials and decoration; if the color relationship itself is the question to be verified, compare color relationships directly.
Before generating the first concept, clarify three things internally or in the delivery notes:
- Object of this round: A standalone symbol, a wordmark lockup, or an app icon; do not use one image to pretend that all three have been solved at the same time.
- Core visual mechanism: Use one sentence—"through what shape/relationship, expressing what brand attribute"—to state the design proposition; the generated result must still be explainable by this sentence.
- Potential misreading: Check for obvious and product-related false associations; if there is no obvious problem, there is no need to force one. Treat major misreadings as hypotheses to be verified, and do not forcibly dissolve them with design explanations.
After the user selects a direction, keep the baseline and compare around a small number of variables. Each version should have a stable number, the same reference conditions, and an explanation of what it changed; there is no need to always produce six or nine images.
Converge layer by layer as much as possible in the order of direction, silhouette, internal elements, color relationships, and composition, while allowing the order to be adjusted for the current problem. Liking a character does not mean liking the current color scheme; liking an inverted color does not mean approving a new silhouette. Small sizes and real carriers should participate in judgment as early as possible after candidates are formed, not wait until the entire brand presentation is complete.
"Empty," "weird," "ordinary," and "doesn't look like a logo" are feedback that needs explanation, not instructions to automatically add elements. First look at which carrier, size, and version it occurs in:
- Empty: may be internal center of gravity, graphic proportion, outer margins, or foreground/background relationship.
- Weird: may be silhouette junctions, facial feature positions, optical center of gravity, or the style simply not being suitable.
- Ordinary: may lack a distinctive silhouette, or the presentation method may simply have erased existing features.
- Doesn't look like a logo: distinguish between character illustration being too heavy, unstable recognition, insufficient application composition, and simply not liking it.
These are candidate explanations, not fixed diagnoses. Propose the fewest testable hypotheses and verify them in comparisons. When several consecutive rounds show no improvement, stop expanding the number of variants, return to the most recently approved baseline, and review whether the changes have gone out of control.
When actual prompts and regression cases are needed, read references/iteration.md。
Division of labor between generation and refinement
- For grid concept images, reference image editing, and brand scene images, use the image tools of the current environment; when available, follow the imagegen skill. Prompts should specify the baseline image, retained features, single change, and elements not to be added. Do not use code processing to bypass the environment's image editing rules.
- Check the actual output each round: whether text, background, silhouette, color, and thumbnail match; correct when presentation glare/perspective and other interference hinder comparison, and do not treat presentation techniques as design improvements.
- Before delivering concept drafts, perform a lightweight check according to references/exploration.md . When image tools violate key constraints, make controlled corrections around a single problem; gradients, textures, or geometric drift that still cannot be eliminated after repeated attempts must be clearly disclosed, and a high-resolution PNG must not be treated as close to production-ready.
- Generated images cannot prove exact dimensions, pixel consistency, or true small-size performance. Do not claim that a generated comparison board is an experiment with strictly controlled variables.
- At the usable asset stage, prioritize existing editable sources; when the user authorizes production assets, pure path vectors may be rebuilt. Explain that the rebuild and the original raster are not pixel-for-pixel identical, and perform a side-by-side check. Do not embed bitmaps into SVG and pass them off as vectors.
- Once there is a master, size and color variants and production previews should be deterministically exported from the same master, no longer relying on multiple generations to stay consistent.
Application and delivery
Brand presentation should be selected according to the user's purpose: primary mark, wordmark combination, light and dark backgrounds, monochrome, app icon, or actual usage scenarios. Do not automatically add business cards, slogans, and a full set of marketing materials for "a logo set." The wordmark is an independent design decision, and the typeface in a generated draft does not automatically become the official typeface.
When judging an app icon, look at the actual dimensions, foreground/background, margins, and platform handling; a full character can have a different composition from the icon. Icon variants should preserve identity, not mechanically fill in details like the mouth or chest badge.
Before delivery, read references/delivery.md. Make sure preview drafts are kept separate from the final assets, and links point to project files that actually exist. After the user selects a direction, you may continue with the authorized refinement and export, but replacing the app, publishing, and trademark applications are additional actions.