{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

IP as Logo

设计在 32px 下仍清晰可读的极简可爱 IP 吉祥物标志。

Skill 元数据

参考：完整 SKILL.md

IP as Logo Skill

创造尽可能简单的可爱 IP 角色：一个紧凑、讨喜、在 32 × 32 下仍可辨认的符号，而不是一幅精细的角色插画。

Hermes 适配说明（本文其余部分为上游工作流，原样保留——为 s1dashu/ip-as-logo-skill 提交 b1bf517c 的快照， 2026 年 8 月 20 日，MIT——见 LICENSE）：

• 图片生成路径：用内置 image_generate 工具，aspect_ratio="square"。当前后端由用户配置——不要挑或切换模型。现代指令遵循型后端（GPT Image、Seedream、FLUX、Grok Imagine）接受完整提示词骨架加自然语言 Constraints: 行；image_generate 不暴露 negative_prompt 参数，所以始终用下文的主提示词约束模式。
• 并行候选：上游文本说"subagents"之处，仅当用户要速度且批次很大时，才用 delegate_task（每个候选一个任务）；否则在一轮里顺序 image_generate 调用更简单，且所有结果都留在本对话里。
• 保存结果：image_generate 返回 URL 或文件路径。把每个候选连同其标签交付给用户（适用平台文件交付惯例）；不要重新托管或后处理。
• QA：按下面的交付规则，不要自动检查/重试/过滤候选。仅当用户明确要求合规检查时才对某个结果跑 vision_analyze。

何时使用

当用户想为产品、仓库、app 或社区要一个吉祥物、IP 角色、品牌角色或"可爱 logo"时使用。

前置条件

• 为内置 image_generate 工具配置好图片生成后端；用 hermes tools 检查，若工具报告无后端就在那里启用一个。
• vision_analyze 仅用于明确要求的合规检查；delegate_task 仅用于用户要速度的大批次。

流程

1. 从请求中解析出明确的 IP 主体和可用的产品上下文。除非用户明确想控制，否则不要让他们选颜色模式。
2. 当用户没指定 IP 主体、且当前工作区是一个产品仓库时，在提问前先检查相关只读上下文。优先 README、产品文档、包或 app 元数据、落地页文案、manifest、设计 token。当能合理确信产品用途、主要受众和预期性格时，就认为上下文已足够。
3. 当产品上下文不足时，问一轮合并的背景问题，覆盖产品做什么、服务谁、应该什么感觉。不要开第二轮背景问卷。回答后按最有依据的解释继续。
4. 上下文一旦足够，生成前总是先摆出三个简洁方向，并明确建议一批生成六个独立候选。在用户同意前不要生成——除非当前请求已明确授权六个输出，或要求 agent 不再确认就继续。
5. 刻意选择提出的三个方向：
   • 用户明确指定 IP 主体时，保留该主体，基于剪影处理、次要色块、标志性特征或性格强调提出三种不同设计处理。
   • 用户没指定 IP 主体时，提出三个真正不同的 IP 主体或隐喻。每个绑一个不同的产品属性或品牌承诺；不要甩三个没有理由的随便动物。
6. 精确解读用户回复：
   • 用户接受全部三个方向和六图提议：每个方向生成两个独立变体，标为 A1、A2、B1、B2、C1、C2。把 A1、B1、C1 分配到左下角，A2、B2、C2 到右下角，让每个方向从两侧各测一次。
   • 用户选一个方向但接受六张图：生成该方向的六个受控变体，标为 A1 到 A6。奇数变体给左下角，偶数给右下角。
   • 用户拒绝提议的数量、方向或分布：照用户的替代指示做，不为默认值争辩。
   • 对预先授权的缩减批次（例如"正好生成 2 个"）且用户没选方向时，倾向用一个方向配 N 个变体，标 A1..AN；在报告里说明方向和理由。当请求已授权特定批次并禁止再确认时，跳过三方向提议轮——第 4 步"总是摆出三个方向"的规则只在能提议时适用。
   • 对其他任何偶数默认批次，候选在左下和右下之间均分。奇数批次则刻意把多出来的候选分给某一侧，并记录这种不平衡。除非用户明确要求，否则不要用底部居中。
7. 每个候选默认整图恰好三个语义色：恰好两个 IP 基色加恰好一个背景色。把两个 IP 色复用到面部标记上，而不是引入额外语义色。用户明确要别的色数时照办。让必需的产品线索、识别特征、复杂度限制和提供的调色板保持足够一致，以便有用对比。
8. 在承诺输出前确定可用的图片生成路径。在 Hermes 里这是 image_generate 工具；若它报告无配置后端，让用户启用一个（hermes tools），而不是编造结果。
9. 若批次很大且用户要速度，通过 delegate_task 并行候选（每个任务一个候选，同一产品简报和共享约束，各分一个方向或变体）。否则通过分开的 image_generate 调用生成候选。
10. 若用户给了背景调色板，把每个提供的颜色留给背景，除非他们明确说不。为主体和上下文独立选恰好两个 IP 基色，除非用户也指定了主体色。不要把任何历史或示例调色板当作允许背景的封闭清单。
11. 用下面的复杂度预算抽象每个主体。每个候选作为独立的全分辨率方形素材生成；绝不要让图片模型拼联系表、网格或多图表。测试纯提示词可复现性时，不要把之前的候选当图片参考。
12. 把每批当作一遍过的创意绘制。每个要求的候选生成一次，然后原样保留并交付每个返回结果。不要检查输出以阻断交付、不把它们分推荐/不推荐、不自动重试、不用后处理修。
13. 保留并标注每个生成结果。报告每个标签、IP 方向和理由、分配的角落、保存路径、提示词/颜色映射和尺寸（当后端只返回 URL 无像素大小时，报告"backend-native square"——别为量尺寸去检查图片）。把所有结果一起呈现；仅当用户明确要求再画时，才生成精修或替换。

生成前提方向时，每个用一行紧凑描述：<IP 主体> — <产品关联> — <标志性剪影>。结尾直接提议用上面的分布生成六张图。别把探索阶段变成一场漫长的品牌工作坊，除非用户要。

复杂度预算

• 用大约 4–7 个大的基本几何形状构建一个主导的连续外剪影。合并或删除任何不承载身份、表情或识别度的形状。
• 最多用一个物种标志性特征：例如一个大袋喙、一对卷角、或一个宽面罩。对无肢或无特征主体（蛇、鬼、blob），标志性特征可以是一个剪影姿态——一圈饱满的盘绕、一道波浪下摆——成对特征规则就简化为两只眼睛。
• 最多用两个宽泛内部色块，对应两个 IP 基色。脸只保留两只眼睛，仅当表情需要时加一个小嘴。省略眉毛、高光、鼻孔、纹理、描边和装饰标记，除非对识别必不可少。
• 去掉重复的羽毛、鳞片、毛簇、甲片、纽扣、螺丝、数字、标签和其他插画细节。
• 把简化、可爱和讨喜的婴儿般性格作为决定性品质。适合主体时，偏好大头、紧凑比例、软脸颊、间距宽的简单眼睛、平静友善的表情。
• 要求在 32 × 32 下有可读的黑色剪影和可识别度。若某特征在那个尺寸消失或变成噪点，放大、合并或删掉它。

形状语言与构图

• 用粗、圆、有分量的轮廓和大块色面。
• 禁止尖角、尖耳朵或尖喙、针状尾、细触角、细微笑、窄缝、锐角火焰或羽毛尖。每个必要的尖端都换成明显钝圆的末端。
• 成对识别特征的两个都要出现，例如耳朵、角、翅膀、鳃或铃。
• 角色直立，从分配的左下或右下角冒出来，填满约 85–95% 画布，让 IP 保持视觉主导。
• 底部或分配侧的裁切在能加强从该角冒出之感时是受欢迎的，但不要规定精确的边缘接触或固定裁切。
• 除非用户明确要求，否则绝不把角色居中或底部居中。
• 在可见构图内保留成对识别特征的两个。
• 作品保持直立；除非明确要求，绝不旋转画布或倾斜主标志。

简洁与视觉处理

• 从大而干净的语义形状和最强的简单剪影起步。角色应在注意到任何内部特征之前就被立刻理解。
• 偏好少而大、软的形态，而非额外的界定。不要为了解释解剖或材质而加特征。
• 面部标记保持小、简单、从属。不要在眼睛、嘴、鼻或其他小特征上加高光斑或精细腔体渲染。
• 命名的背景色保持视觉上实心均匀，无风景、纹理、光晕、暗角或光照变化。
• 仅用提示词骨架里那一句话要微妙的立体感。不要展开成数值强度或渐变/高光/阴影指令。生成器顺带返回的偶然渐变、阴影或轻微立体感是可接受的，不得触发过滤或重试。
• 让要求的视觉方向平面、简单，而不是要黏土、充气、塑料、毛绒、玩具感或照片级渲染。

颜色与画布

• 默认整图恰好三个语义色：恰好两个 IP 基色加恰好一个背景色。
• 从产品上下文、主体身份、预期性格和用户请求选两个 IP 色。把两者组织成有目的的大块；一个复用到面部标记，另一个留在一个连续的标志性区域，而不是撒装饰碎片。
• 两个主体色都独立于背景选。适合时偏好清晰、活泼的主体色，但不要对 IP 强加全局饱和度、OKLCH、色相偏移或色度区间。
• 为上下文自由选背景，或从用户提供的调色板选。除非用户要鲜艳色，否则通过稍微降低饱和度让背景柔和一些；让它明显有色相、有意图，而非鲜艳、灰或脏。历史调色板和示例只是建议，绝不是允许清单或强制默认调色板。
• 主导 IP 剪影、面部标记和背景之间保持清晰视觉分离。若用户提供的背景导致分离弱，先调主体色，而不是换掉要求的背景。
• 在一批内，刻意变化两 IP 色策略，而非重复同样的中性偏重组合。
• 把两个角色色当作语义色系。任一色系内偶然的色调变化不使输出作废。
• 直接命名想要的实心背景色。要求它填满每块开放区域和空角，而分配的冒出角由角色占据。生成提示词里不要用 opaque、alpha、transparency 这类图像模式术语。
• 生成直接的 1:1 方形，方角（image_generate 里 aspect_ratio="square"）。原样接受后端原生方形分辨率；绝不为凑某个像素数而重采样。

提示词骨架

把要求的视觉只描述成一张图。绝不告诉图片生成器这张图是 logo、brand mark、app icon、icon asset，或用于任何这类用途。不要加透露此类用途的用例或素材类型脚手架。这条规则只适用于生成提示词；周围的用户对话和 skill 名仍可描述更广的项目。

image_generate 只吃一个提示词字符串，所以始终把自然语言 Constraints: 行放在主提示词里（没有单独的负提示词通道）。在生成报告里记录每个候选用的提示词和颜色映射。

Create one complete full-bleed 1:1 square image.
Background: fill the entire square with solid <background>. Keep <background> visible in every open area and in the corners not occupied by the character; the assigned emergence corner must be occupied by the character.
Subject: place one extremely simplified, cute, endearing <subject> IP character on the background, reduced to one soft rounded continuous silhouette and one defining feature.
Complexity: use only 4–7 large basic shapes and at most two broad internal color regions. Use two simple eyes and add one tiny mouth only when it helps the expression. Remove every nonessential line, outline, anatomical detail, texture, and decoration. Keep the character readable at 32 × 32.
Color behavior: use exactly three semantic colors in the complete image: exactly two IP base colors plus the background color. Choose the two IP colors from the subject and context, organize both into broad purposeful masses, and reuse them for facial marks. Choose the background independently or follow the user's supplied background. Unless the user asks for vivid color, lower the background saturation slightly so it feels gently muted and restrained while remaining clearly chromatic, clean, and intentional rather than gray or muddy. Keep the IP, facial marks, and background clearly separated. Treat any example palette as optional inspiration, never as an allowlist.
Composition: keep the character upright and emerging from the assigned <lower-left or lower-right>, filling about 85–95% of the square so it remains visually dominant. Cropping at the bottom or assigned side is welcome when it strengthens the corner emergence. Preserve both paired identifying features. Never center or bottom-center the character.
Style: make simplification, cuteness, and lovable baby-like appeal the strongest qualities. Use large soft forms, compact proportions, thick rounded contours, and an ultra-clean graphic treatment. Prefer one clear shape over several explanatory details. Add an extremely, extremely subtle, almost imperceptible sense of depth through a barely-there neo-skeuomorphic treatment.
Finish: show only the character on the full-canvas background, with clean surfaces and normal square outer corners.
Constraints: Use no text or watermark. Add no borders, frames, cards, or presentation masks. Include one character only, with no extra subjects or scenery. Use no fragile lines, sharp tips, unnecessary outlines, tiny details, or decorative marks. Add no photorealistic material, dramatic bevel, glossy hotspot, deep occlusion, extrusion, strong three-dimensional rendering, or external cast shadow. Keep the background solid and uniform, with no texture, vignette, or lighting variation.

交付行为

• 把生成当作随机抽取，而非一致性测试。
• 生成要求数量的独立候选一次，交付每个返回的图。
• 默认不检查或报告 alpha、透明度或背景模式。
• 不因某个结果的背景、颜色、细节、构图、渐变、阴影或立体感而阻断交付、把候选分合规/不合规、标推荐/不推荐，或自动重试。
• 不要后处理结果让它显得更合规。若用户之后要另一个方向或替换，响应该明确请求生成一个新独立候选。

常见坑

• 最大的失败模式是细节蔓延：模型加描边、纹理、额外颜色和风景。提示词骨架的 Constraints: 行是承重的——绝不要删。
• 在生成提示词里把素材叫"logo"或"icon"会触发展示框架（徽章、卡片、样机）。提示词保持纯图像。
• 一次调用要网格/联系表变体，会得到小而不一致的角色。永远一次一个候选。
• 若一批里两个候选几乎一样，那是正常随机行为——两个都交付；不要静默重生成。

验证

• 每个交付候选在最终报告里都有标签、方向理由、分配角落、提示词/颜色映射和文件路径或 URL。
• 批次数量与用户批准一致；没有候选被扣留、重试或后处理。