Ip As Logo

IP as Logo Skill

Create the simplest possible cute IP character: a compact, lovable symbol that remains recognizable at 32 × 32, not a detailed character illustration.

Hermes adaptation notes (the rest of this document is the upstream workflow, kept intact — snapshot of s1dashu/ip-as-logo-skill commit b1bf517c, Aug 20 2026, MIT — see LICENSE):

• Image generation path: use the built-in image_generate tool with aspect_ratio="square". The active backend is user-configured — do not pick or switch models. Modern instruction-following backends (GPT Image, Seedream, FLUX, Grok Imagine) take the full prompt skeleton with the natural-language Constraints: line; image_generate exposes no negative_prompt parameter, so always use the main-prompt constraints mode described below.
• Parallel candidates: where the upstream text says "subagents", use delegate_task with one task per candidate ONLY if the user wants speed and the batch is large; otherwise sequential image_generate calls in one turn are simpler and keep all results in this conversation.
• Saving results: image_generate returns a URL or file path. Deliver every candidate to the user with its label (platform file-delivery conventions apply); don't re-host or post-process.
• QA: per the delivery rules below, do NOT auto-inspect/retry/filter candidates. Only run vision_analyze on a result if the user explicitly asks for a compliance check.

When to Use

Use when a user wants a mascot, IP character, brand character, or "cute logo" for a product, repo, app, or community.

Prerequisites

• An image-generation backend configured for the built-in image_generate tool; check with hermes tools and enable one there if the tool reports no backend.
• vision_analyze only for an explicitly requested compliance check; delegate_task only for large batches where the user wants speed.

Procedure

1. Parse the request for an explicit IP subject and available product context. Do not ask the user to choose a color mode unless they explicitly want to control it.
2. When the user has not specified an IP subject and the current workspace is a product repository, inspect relevant read-only context before asking questions. Prefer the README, product docs, package or app metadata, landing-page copy, manifests, and design tokens. Treat context as sufficient when the product purpose, primary audience, and intended personality can be inferred with reasonable confidence.
3. When product context is insufficient, ask one consolidated round of background questions covering what the product does, who it serves, and how it should feel. Do not start a second background questionnaire. Continue with the best supported interpretation after the answer.
4. Once context is sufficient, always present three concise directions before generation and explicitly propose generating six independent candidates in one batch. Do not generate until the user agrees, unless the current request already explicitly authorizes six outputs or asks the agent to proceed without another confirmation.
5. Choose the three proposed directions deliberately:
   • When the user explicitly specifies an IP subject, keep that subject and propose three distinct design treatments based on silhouette treatment, secondary color region, defining feature, or personality emphasis.
   • When the user does not specify an IP subject, propose three genuinely different IP subjects or metaphors. Tie each one to a different product attribute or brand promise; do not return three arbitrary animals with no rationale.
6. Interpret the user's response exactly:
   • If the user accepts all three directions and the six-image proposal, generate two independent variants per direction and label them A1, A2, B1, B2, C1, and C2. Assign A1, B1, and C1 to the lower-left and A2, B2, and C2 to the lower-right so every direction is tested once from each side.
   • If the user selects one direction but accepts six images, generate six controlled variants of that direction and label them A1 through A6. Assign odd-numbered variants to the lower-left and even-numbered variants to the lower-right.
   • If the user rejects the proposed quantity, directions, or distribution, follow the user's replacement instructions without arguing for the default.
   • For a pre-authorized reduced batch (e.g. "generate exactly 2") where the user did not pick directions, prefer one direction with N variants labeled A1..AN; state the direction and rationale in the report. Skip the three-direction proposal round whenever the request already authorizes a specific batch and forbids further confirmation — the "always present three directions" rule in step 4 applies only when a proposal round is possible.
   • For any other even default batch size, split candidates equally between lower-left and lower-right. For an odd batch, assign the extra candidate to either side deliberately and record the imbalance. Do not use bottom-center unless the user explicitly requests it.
7. Default every candidate to exactly three semantic colors in the complete image: exactly two IP base colors plus exactly one background color. Reuse the two IP colors for facial marks rather than introducing additional semantic colors. Follow an explicit user request for another color count. Keep required product cues, identifying features, complexity limits, and any supplied palette consistent enough for useful comparison.
8. Determine the available image-generation path before promising output. In Hermes this is the image_generate tool; if it reports no configured backend, ask the user to enable one (hermes tools) instead of fabricating results.
9. If the batch is large and the user wants speed, parallelize candidates via delegate_task (one candidate per task, same product brief and shared constraints, one assigned direction or variant each). Otherwise generate candidates through separate image_generate calls.
10. If the user supplies a background palette, reserve every supplied color for backgrounds unless they explicitly say otherwise. Choose exactly two IP base colors independently for the subject and context unless the user also assigns subject colors. Do not treat any historical or example palette as a closed list of allowed backgrounds.
11. Abstract each subject using the complexity budget below. Generate every candidate as a separate full-resolution square asset; never ask an image model to compose a contact sheet, grid, or multi-image sheet. Do not use previous candidates as image references when testing prompt-only reproducibility.
12. Treat each batch as a one-pass creative draw. Generate every requested candidate once, then preserve and deliver every returned result as-is. Do not inspect outputs to block delivery, classify them as recommended or non-recommended, retry them automatically, or repair them with post-processing.
13. Preserve and label every generated result. Report every label, IP direction and rationale, assigned corner, saved path, prompt/color mapping, and dimensions (when the backend returns only a URL with no pixel size, report "backend-native square" — do not inspect the image just to measure it). Present all results together; generate refinements or replacements only when the user explicitly asks for another draw.

When proposing directions before generation, describe each in one compact line: <IP subject> — <product connection> — <defining silhouette>. End with a direct proposal to generate six images using the distribution above. Do not turn the discovery phase into a long branding workshop unless the user asks for one.

Complexity budget

• Build one dominant continuous outer silhouette from roughly 4–7 large basic geometric shapes. Merge or delete any shape that does not carry identity, expression, or recognition.
• Use at most one species-defining feature: for example, one large pouch beak, one pair of curled horns, or one broad visor. For limbless or featureless subjects (snakes, ghosts, blobs), the defining feature can be a silhouette gesture — one plump coil, one wavy hem — and the paired-features rule reduces to the two eyes.
• Use at most two broad internal color regions corresponding to the two IP base colors. Keep the face to two eyes and, only when needed for the expression, one tiny mouth. Omit eyebrows, highlights, nostrils, texture, outlines, and decorative marks unless essential for recognition.
• Remove repeated feathers, scales, fur tufts, armor plates, buttons, screws, numbers, labels, and other illustrative detail.
• Make simplification, cuteness, and an endearing baby-like personality the decisive qualities. Favor a large head, compact proportions, soft cheeks, widely spaced simple eyes, and a calm friendly expression when appropriate to the subject.
• Require a readable black silhouette and recognizability at 32 × 32. If a feature disappears or becomes noise at that size, enlarge, merge, or remove it.