@autoaiai/aicut 0.1.11 → 0.1.13

package/skills/image-story-video-wizard/references/workflow.md

@@ -1,203 +0,0 @@
-# Guided workflow contracts
-
-Use only the current stage section in user-facing interaction. The full sequence belongs to the Skill, not to the user.
-
-Each stage has five fields:
-
-- **Enter when:** required prior gate.
-- **Skill acts:** work performed without asking the user to manage it.
-- **Ask now:** only the minimum current input.
-- **Deliver:** artifact that proves the stage work happened.
-- **Gate:** explicit approval required before transition.
-
-## START
-
-**Enter when:** the Skill is invoked.
-
-**Skill acts:** locate or initialize `PROJECT_STATE.json`; inspect only the supplied project scope; identify host capabilities and existing artifacts; classify new versus resumed work.
-
-**Ask now:** if undiscoverable, ask for the project folder and whether this is new or continued work. Do not ask production questions yet.
-
-**Deliver:** current-state summary, confirmed host, missing capability list, and first actionable request.
-
-**Gate:** project root and resume point are correct.
-
-## BRIEF
-
-**Enter when:** START is confirmed.
-
-**Skill acts:** turn the user's idea into a production brief: topic, audience, audio-first versus visual-first, platform, aspect ratio, target duration, language, narrator count, release scope, and what success means for this sample.
-
-**Ask now:** ask at most three questions. Prefer: topic/audience, target platform/format, desired duration. Infer reversible defaults and show them for confirmation.
-
-**Deliver:** `BRIEF.md` using `assets/brief-template.md`.
-
-**Gate:** user confirms the brief. Channel creation, upload, or publishing is not included unless separately authorized.
-
-## BENCHMARKS
-
-**Enter when:** BRIEF is confirmed.
-
-**Skill acts:** first explain that benchmark selection will directly shape script quality and downstream presentation. Prioritize user-supplied benchmarks or selection criteria: ask for the accounts or works the user genuinely wants to learn from, or at least the direction and qualities they want screened. Analyze those materials when provided. Only when the user is unwilling or unable to provide either, perform a bounded public read-only search and return at least two benchmark candidates with clear reasons.
-
-**Ask now:** ask the user for specific learning targets or concrete screening direction. Make clear that this is a high-impact decision, not routine material collection. If the user cannot or does not want to provide them, say that the Skill can search and recommend candidates instead. Do not silently choose a direction and continue.
-
-**Deliver:** `BENCHMARKS.md` with source, role, evidence, learn/avoid decisions, recommendation, and rights boundary.
-
-**Gate:** user carefully confirms benchmark roles after seeing the evidence and recommendation. Do not start WRITING_PACK before this decision. Learning never means copying exact wording, images, audio, or finished footage.
-
-## WRITING_PACK
-
-**Enter when:** BENCHMARKS is confirmed.
-
-**Skill acts:** read [writing and review](writing-and-review.md), then use `assets/writing-pack-manifest.md` to build one self-contained package with the reusable writer rules, only the current channel/language profile and selected examples, and the episode task/materials. Read the channel's existing feedback before selecting examples. Preserve source evidence and mark what may enter narration. Supply needed information and causal relationships instead of prewritten editorial metaphors, forced paragraph formulas, or numerical style quotas.
-
-**Ask now:** ask only for source material that cannot be found in scope and one decision about the desired benchmark emphasis.
-
-**Deliver:** the populated writing package and manifest, as a merged file or archive with actual content. Record the package and channel-profile versions. Do not expose secrets or internal paths in public-facing materials.
-
-**Gate:** user confirms the package direction, not every line of source material.
-
-## SCRIPT
-
-**Enter when:** WRITING_PACK is confirmed.
-
-**Skill acts:** follow [writing and review](writing-and-review.md). Preserve the user's chosen writing model; when Kimi K3 is specified, use it if available or provide the user a self-contained handoff instead of silently substituting. Preserve one complete first draft. The original guiding conversation identifies concrete issues and protected passages, then provides one copyable, bounded edit list for the writer. When the revision returns, compare actual body changes with that list, check for new errors or damaged transitions, and stop after those issues are resolved; do not begin another general style review.
-
-**Ask now:** use the already stated preferences to review the draft and prepare the edit list without asking the user to find all problems. Give the user the ready-to-forward instruction when the writer is in another conversation. Request a user decision only for a necessary scope change, missing fact, or final acceptance. Do not ask the user to redesign the workflow.
-
-**Deliver:** preserved original body, `review/SCRIPT-REVIEW.md` with issues/actions/protected scope, the writer's complete revised `SCRIPT.md`, and a short result of the change comparison. Use fresh filenames if originals already exist. Keep counting and unresolved facts separate from narration, and record the user's actual feedback in the channel profile or project feedback file.
-
-**Gate:** the user confirms the final script before marking it `已确认`. A complete but slightly short draft may be accepted without padding; a hollow draft or necessary material gap is `需要返工` and returns to WRITING_PACK. Large restructuring needs a specific reason and the user's decision. Do not perform second-round padding.
-
-## VOICE
-
-**Enter when:** SCRIPT is confirmed.
-
-**Skill acts:** check whether a chosen TTS service is locally configured. If access is missing, guide the user through the current official application and local configuration path, verifying the official instructions when they may have changed; never request the plaintext key. For the established Doubao path, use current Seed-TTS 2.0 rather than a legacy generation. Select a representative approximately twenty-second sample and generate five to ten same-text voice auditions. After voice selection, generate a small set of rate auditions.
-
-**Ask now:** first ask whether access is configured, without requesting plaintext credentials. Then ask the user to choose the best voice; only after that ask for rate preference.
-
-**Deliver:** voice audition set, confirmed voice/rate record, final narration, and sentence- or word-level timestamps when available.
-
-**Gate:** user confirms voice and full narration. Do not treat model or parameter suggestions as acceptance.
-
-## STORYBOARD
-
-**Enter when:** VOICE is confirmed.
-
-**Skill acts:** use actual narration duration and timestamps to calculate image cadence and create `STORYBOARD.csv`. Each row includes shot ID, audio start/end, narration excerpt, visual intent, characters, text-card need, and status.
-
-**Ask now:** present two concrete cadence options with real counts. Recommended default for a first audio-first project is 10–12 seconds per image; offer 6–8 seconds when the user wants faster visual motion and accepts more images.
-
-**Deliver:** complete storyboard and count summary.
-
-**Gate:** user confirms cadence, image count, and representative storyboard sections.
-
-## VISUAL_STYLE
-
-**Enter when:** STORYBOARD is confirmed.
-
-**Skill acts:** request one to three reference images or propose two to three directions derived from the brief and benchmarks. Extract stable style variables: medium, palette, line/texture, lighting, composition, aspect ratio, negative constraints, subtitle style, and text-card style. Produce three to five pilot prompts or images.
-
-**Ask now:** ask the user to choose or reject the pilot. Ask one targeted follow-up about the largest visible problem when rejected.
-
-**Deliver:** `VISUAL_STYLE.md`, chosen pilot images, and frozen text treatment.
-
-**Gate:** user explicitly confirms image style and text treatment. Do not write the full image prompt manifest before this.
-
-## CHARACTER_ANCHORS
-
-**Enter when:** VISUAL_STYLE is confirmed.
-
-**Skill acts:** detect recurring characters and decide whether strict identity continuity is needed. For each strict character, create a face anchor and full-body anchor with age, body, clothing, footwear, and era details. Skip this stage for scenery-only or non-recurring characters.
-
-**Ask now:** ask the user to approve or adjust each main character's identity, not every incidental character.
-
-**Deliver:** `characters/` anchor images and character cards.
-
-**Gate:** required anchors are confirmed, or the stage is explicitly `已跳过`.
-
-## IMAGE_PROMPTS
-
-**Enter when:** VISUAL_STYLE and any required CHARACTER_ANCHORS are confirmed.
-
-**Skill acts:** create `IMAGE_PROMPTS.md` mapped one-to-one to storyboard IDs. Each prompt carries reference rules, identity constraints, frozen style, specific scene, composition, output format, and negative constraints. Start with a three-to-five-shot pilot manifest.
-
-**Ask now:** tell the user exactly which pilot prompts to run, where to run them, how to name results, and what to return for review.
-
-**Deliver:** pilot prompt manifest, then full manifest only after pilot approval.
-
-**Gate:** pilot prompts produce acceptable results before full prompt expansion.
-
-## IMAGE_GENERATION
-
-**Enter when:** pilot prompts are confirmed.
-
-**Skill acts:** route to manual or API mode. In manual ChatGPT mode, default to one prompt and one image per fresh conversation, issue manageable batches, and map each result to its shot ID. In API mode, explain estimated count/cost, verify authorization, run a small batch, then continue. Do not invoke video-generation models for this slideshow assembly stage.
-
-**Ask now:** ask the user to choose manual versus API only after showing the tradeoff. For logged-in browser work, confirm the correct account and allowed read/write boundary.
-
-**Deliver:** numbered generated images and generation ledger with failures or retries.
-
-**Gate:** all required images exist or missing shots are explicitly accepted.
-
-## ASSET_QC
-
-**Enter when:** the image batch is complete enough to inspect.
-
-**Skill acts:** check counts, IDs, dimensions, corrupt files, style drift, repeated composition, identity drift, era violations, embedded borders, and text baked into images. Generate a replacement list rather than silently accepting weak assets.
-
-**Ask now:** show only the replacement candidates and reasons; ask the user to approve replacements or accept specific exceptions.
-
-**Deliver:** frozen image manifest and `review/image-qc.md`.
-
-**Gate:** image set is confirmed for assembly.
-
-## MUSIC
-
-**Enter when:** ASSET_QC is confirmed.
-
-**Skill acts:** ask whether music is needed. If no, mark `已跳过`. If yes, generate or source two to three short audition candidates within the authorized tool path, then plan a low-presence bed or a few emotion components. Narration remains dominant.
-
-**Ask now:** ask whether to skip music; if not, ask the user to choose from auditions.
-
-**Deliver:** music choice and mix plan.
-
-**Gate:** music is confirmed or explicitly skipped.
-
-## PREVIEW
-
-**Enter when:** images are confirmed and music is confirmed or skipped.
-
-**Skill acts:** assemble the project, preferably with HyperFrames when available. In a host with the bundled HyperFrames skills, load the `hyperframes` mandatory entry point before touching the composition and follow its routing instructions. Align images, subtitles, text cards, and music to narration timestamps. Run structural checks and create a reviewable preview. Do not final-render yet.
-
-**Ask now:** tell the user what to review: opening minute, chapter transitions, character first appearances, text/subtitle collisions, and ending. Ask for specific changes or approval.
-
-**Deliver:** preview, review board or representative frames, and issue list.
-
-**Gate:** user approves preview. A general earlier “go ahead” is not sufficient.
-
-## FINAL_RENDER
-
-**Enter when:** PREVIEW is confirmed.
-
-**Skill acts:** render the master, validate container/audio/video properties, extract representative frames from the final file, and watch or request a full human watch. Preserve the editable project.
-
-**Ask now:** ask for acceptance after presenting the actual master and checks. Do not publish automatically.
-
-**Deliver:** master video, project files, check report, and delivery note.
-
-**Gate:** status is `已做待验` until the user accepts; then set `已验收`.
-
-## FEEDBACK
-
-**Enter when:** the user later provides real platform results.
-
-**Skill acts:** record actual production time, manual intervention, playback/retention/feedback data, and identify the smallest workflow change for the next episode. Follow [writing and review](writing-and-review.md) to retain actual wording corrections and user judgments in the channel profile; select only relevant, current lessons for later packs. For a new account with 7–15 days of weak results, review topic choice and script first, then present an evidence-based choice between changing the niche and repairing those inputs. After three to five stable, accepted scripts exist, offer to extract the channel's own writing template or Skill. Do not infer performance from render success, treat merely used scripts as gold samples, or freeze a channel template from one sample.
-
-**Ask now:** request only the available real results and the user's qualitative judgment.
-
-**Deliver:** next-episode change list and project-level defaults worth freezing after several episodes.
-
-**Gate:** no final gate; the next project starts from confirmed defaults rather than copying unverified assumptions.

package/skills/image-story-video-wizard/references/writing-and-review.md

@@ -1,60 +0,0 @@
-# 写作包与定点审稿
-
-版本：1.4（2026-09-14，材料分层、软目标与修稿作用保护）。供准备写作包、接收初稿和核对修改的原对话使用。读本页不启动写作或视频制作。写作模型只收到当前任务包与必要的修改指令，不把本页整份塞进包内。
-
-交付目标：初稿完整、接近可用；一次集中修稿后可直接定稿，或只需用户少量口气微调。沿用“写作包 → 完整初稿 → 一轮修改与核验 → 用户定稿”，不另增评分、检查表交付或多轮润色环节。一轮是收敛目标，材料缺口和事实硬伤仍按实际问题处理，不为满足轮数冒称定稿。
-
-## 准备一个完整、精简的包
-
-以 [assets/writing-pack-manifest.md](../assets/writing-pack-manifest.md) 组织本次交付，将 [Kimi 通用写作要求](../assets/writer-rules.md) 的实际内容放进包里。先沿用项目已指定的频道档案；未指定时，可查本机安装目录的 `references/local-channels.md`（存在才读，属用户本地索引，不随公开仓库分发）。保持这三个内容部分：
-
-- **通用要求**：复用短核心，不按每期重新发明规则；不自加跨频道统一的句数、点评位置、回收百分比、幽默数量、禁词数量或改稿比例。用户指定的频道目标按其范围带入；“约几处、酌情”保留为软目标，不变成必须凑齐的数量。
-- **当前频道与语言**：读频道现有的 `CHANNEL-WRITING.md`（或同等已知档案），只带本次适用的口气、听众背景、改编权限、开结场及范例。中文、英文各用对应范例；明确是原生写作还是忠实改编。缺少英文范例时不假称已有验证，也不把中文说书口气自动迁移过去。
-- **单集任务与材料**：说明要回答的问题、可用材料、必要关系和节点、篇幅预算。需要结构提示时写每部分应交代的新信息及因果，不预写金句、比喻、节目路线和机械段落表。人物心理、对白加工与来源口吻按本期体裁决定，不跨频道套用。
-
-材料先给写手足够讲故事的可用内容：必要背景、具体事件、原话及其准确含义、关系变化。转述对应好说话人、对象和时间，原文是否进入旁白由频道决定。组包人核实遗漏的重要背景，不让“摘要里没写”自动成为删掉有用内容的理由；撤掉不可靠逸闻后，检查剩余内容是否足以支撑本期的趣味与篇幅。反复出现的初稿问题优先在材料、范例和短写前要求中解决，不长期依赖审稿代写。
-
-已修正的问题直接给正确材料，核错过程与逐项反驳留在项目审核记录。可讲事件与出处说明、使用建议分开，避免整理备注被转成旁白；必要事实性质与不确定性集中简写，不把每段写成“可讲什么／不许怎样”。来源索引与原文仍可回查；“后台可查出处”与“听众需要知道是谁的说法”分别判断，不通过隐藏依据消除来源腔。
-
-材料区分可核事件、原文情节、推断、传闻及不用项，并保留可回查的依据。来源是否读进口播由实际题材决定；不把考据报告搬进正文，也不一律向写手隐藏需要判断的依据。用户明确要求的量化边界按其适用范围执行；不把软目标变硬约束，不从过去一次的字数或播出表现推导永久配额。
-
-范例选少量连续好段，篇章节奏确有需要时带完整样本；同时配适用的“旧句—采用的改句—原因”。标明 `明确喜欢`、`采用但仍有问题`、`明确否定`，仅看过差异而无用户评价时标 `对照观察`。播出、技术检查通过或审稿人建议，都不自动成为金样。旧句只与更好的表达成对提供；不把全部纠错历史或其他频道样本逐期累加进包。
-
-交付前检查：包内任务、示例和规则没有冲突；样本与材料是实际内容而非外部路径清单；合并版与压缩包来自同一版本。历史单集包保持归档，新包采用本规范，不继续复制旧公式。
-
-## 原对话审稿
-
-保留收到的完整正文及其版本，单列标题、自检和说明，比较正文时不混入这些内容。写作模型依用户选择；用户固定 Kimi K3 时继续沿用，不因审稿需要自动换作者或启动外调。
-
-先读当前频道的专用稿后检查项（如有），只供审稿使用，不整表转给写手。按“事实与原意 → 整个事件能否听懂 → 口气与重复”的顺序一次通读，指出已经成立且要保护的内容。判断缺信息时读相邻句和完整事件，不因一句省略就补写已交代的内容；有意保留的悬念、必要氛围、有效幽默和角色声音继续保留。只把有确定性收益的修改交给 Kimi：
-
-- 确定的事实、说话人、指代、时间、物件位置、知情或因果错误。
-- 需要回听才能理解的表达；反复讲同一判断；妨碍当前频道听感的生硬修辞、写作提示和过度解释。
-- 用户明确指出的其他问题。
-
-能说清当前版本的问题、预期改善和需要保留的内容，才列入修改单。仅属另一种写法或收益不确定的润色不列为必改；用户明确偏好可以直接落实，不反复要求其证明某词普遍不自然，也不把否定一种用法扩大为禁用整类表达。先辨认句子的作用：必要关系、承接、反差和幽默有作用就保护，有错改准；重复判断或制作说明无作用才删，不强配替换句。无事实错不等于自然有用，没有新增事实也不等于废句。没有实际问题就交用户确认，不制造返修。
-
-同类问题全篇一次找齐，合并说明修改原则，准确列出每个落点和必要例外；发出前消除意见之间的重复与冲突。不要只说“全文更口语”，也不要把诊断长文、候选词表和研究过程整份交给写手。包里旧公式与好表达冲突时，保护好表达，将包的问题另记。
-
-原对话交一份可直接转给 Kimi 的修改指令，内容保持短：
-
-> 基于【本次稿件/版本】修改。保留【原顺序、口气、有效场面及具体保护项】。  
-> 1. 原句或位置：【准确引用】。问题：【具体影响】。动作：【删/替换词句/补最短因果桥】。范围：【只到哪里】。  
-> ……只列实际需要的修改。涉及事实时附对应依据或明确待确认，不以猜测替换。  
-> 未列出的内容保持原样。相邻句确需改动才一并列明；未列入修改范围的开头、结构、材料、观点和结尾都不改，不顺手补字数。默认只交完整修订稿，不附自评；改动说明仅按本次需求另附。
-
-明确错词或指代可给准确替换；涉及表达时给目标和范围，让 Kimi 保留自己的顺口写法。替换建议也要对照完整上下文核对人物、时间、原意与听感，不能把含糊换成书面或重复。审稿人不另写一篇替代原作者。小改无法解决的结构或材料缺口单独说明；用户已授权的修复继续执行，未授权时不扩成整篇重写。
-
-## 修改返回后收稿
-
-原对话核对实际正文差异：①清单问题已解决；②未列出内容没有被顺手改；③修改未产生新错误、衔接断裂或语气损失。对删改的承接、幽默和反差，连读相邻段，在原核验记录简记其作用保留、已由别句承担或确实丢失；不按少了几句就判定变差。Kimi 的“其余未动”说明不代替差异核对。字数、明确禁词、重复文本可用工具定位；关键词、破折号或笑点数量不能裁决文采、语义和听感。
-
-这一步沿用初审标准，只核对本轮修改及其影响，不另换文风标准开启全面挑剔。改差的句子优先恢复原句，再作更小的修正；有新硬伤则只修新硬伤。通过后交用户听感确认或少量个人微调并停止。原对话核对通过、用户确认、已播出分别记录；用户尚未确认时不把脚本阶段标为 `已确认`。
-
-## 反馈留在频道档案，按需进入后续包
-
-原对话负责在频道 `CHANNEL-WRITING.md` 的反馈区记录“原句/修改动作、用户评价、适用范围、来源稿件或对话”。找不到频道档案时先留在项目 `review/WRITING-FEEDBACK.md`，不要替用户修改全局记忆。
-
-先判断问题出在材料、范例、规则还是本次执行；材料不足补材料，口气不合先调范例，偶发失手局部修。用户明确长期偏好直接更新；其余先归入已有类别，反复出现且能说明修改收益时再提炼短规则。外部研究只吸收有依据、适用的判断，替换示例先核上下文，不把候选词当模型指纹或固定禁词。
-
-反馈仍留在原记录，简记二稿能否直接定稿或仅需用户微调、是否改坏事实或口气；未回收二稿就记待验证。规则价值看能否减少实际返工，无收益或导致过改的规则调整或撤掉，不新增评分体系。更新现有条目优先于叠加；只把当前适用的要求与已确认范例带入下一包，不把审稿建议或研究示例直接当金样。平台表现另记，不据单期表现断言文风成败。

package/skills/ip-as-logo/SKILL.md

@@ -1,151 +0,0 @@
----
-name: ip-as-logo
-description: "Generate extremely simple, cute, personified square character images with rounded heavy forms, two purposeful character colors, one solid background color, and a dominant lower-corner composition. Use when creating an animal, creature, robot, ghost, plant, object, or other character image, including when the agent should infer three product-relevant directions and propose six independent candidates for approval. Runs in AICUT: the film is film.html, a page per shot, drawn by `aicut look` and `aicut render`."
-license: MIT
-source: "hosted/ip-as-logo-skill"
----
-
-# IP as Logo
-
-## Running it in AICUT
-
-AICUT's film is `film.html`: it cuts pages, footage, pictures and sound together on tracks. A page is a web page that
-sets `window.film = { frame(t) }` and draws that moment — no framework, no build step, no composition object, no
-`registerRoot`. Five shots are five pages cut together, not one page that changes scene, so each shot stays trimmable
-and replaceable in Studio.
-
-```sh
-npx -y @autoaiai/aicut@latest          # the manual: the format and the commands, always current
-npx -y @autoaiai/aicut@latest open .   # make this folder a film and print Studio's address
-npx -y @autoaiai/aicut@latest look     # a contact sheet of the whole film, its sound, and a determinism check
-npx -y @autoaiai/aicut@latest look 4.5 # one frame, full size — look at the PNG, not at the code
-npx -y @autoaiai/aicut@latest render   # the MP4, beside film.html
-```
-
-Run the manual before the first film: it is authoritative for the format, and this skill is about the method above it.
-
-Where the words below name another program's part, it becomes this:
-
-| elsewhere | in AICUT |
-|---|---|
-| composition, timeline, project file | `film.html`; tracks and clips inside it |
-| a scene, a sequence, a slide | a page (`pages/<name>.html`) cut onto a track |
-| `useCurrentFrame()`, `interpolate()` | `frame(t)` — the picture depends only on `t`, never on state or `Date.now()` |
-| a still, a screengrab | `aicut look <t>` |
-| `render` / `build` / `export` | `aicut render` (the person can also export from Studio) |
-| a dev server, a preview window | `aicut open` and the Studio address it prints |
-
-Hard rules that hold whatever the method says: the picture depends only on `t`; every value in the person's prompt is
-binding; look at the frames `look` writes before saying a film is done.
-
-
-Create the simplest possible cute IP character: a compact, lovable symbol that remains recognizable at `32 × 32`, not a detailed character illustration.
-
-## Workflow
-
-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 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. Before generation, require a top-tier image model: prefer GPT Image 2; also support Seedance 5.0 Pro, Nano Banana Pro (Gemini Image Pro), or Nano Banana 2 (Gemini Image Flash). If none is available, ask the user to enable a suitable tool or provide its API key. Never fall back to SVG generation. Use another available image model only with the user's explicit consent, and warn that its quality may not match the recommended models. Do not fabricate generated results.
-9. If the runtime supports subagents, parallelize the six independent candidates up to the available concurrency. Give every subagent the same product brief, shared constraints, and one assigned direction or variant; run remaining candidates in subsequent waves when capacity is limited. If subagents are unavailable, generate the candidates through separate image-generation calls or jobs.
-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. 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.
-- 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.
-
-## Shape language and composition
-
-- Use thick, rounded, weighty contours and broad color masses.
-- Forbid sharp corners, pointed ears or beaks, needle-like tails, thin antennae, thin smiles, narrow gaps, and acute flame or feather tips. Replace every necessary tip with a visibly blunt rounded end.
-- Show both members of paired identifying features, such as ears, horns, wings, gills, or bells.
-- Show the character upright and emerging from the assigned lower-left or lower-right corner, filling about `85–95%` of the canvas so the IP remains visually dominant.
-- Cropping at the bottom or assigned side is welcome when it strengthens the sense of emerging from that corner, but do not prescribe exact edge contact or a fixed crop.
-- Never center or bottom-center the character unless the user explicitly requests it.
-- Preserve both members of paired identifying features within the visible composition.
-- Keep the artwork upright; never rotate the canvas or tilt the main mark without an explicit request.
-
-## Simplicity and visual treatment
-
-- Start from large, clean semantic shapes and the strongest possible simple silhouette. The character should be understood immediately, before any internal feature is noticed.
-- Prefer fewer, larger, softer forms over extra definition. Do not add a feature merely to explain anatomy or material.
-- Keep facial marks tiny, simple, and subordinate. Do not add glossy hotspots or detailed cavity rendering to eyes, mouths, noses, or other small features.
-- Keep the named background color visually solid and uniform, without scenery, texture, halo, vignette, or lighting variation.
-- Ask for the subtle dimensional effect only with the single sentence used in the Prompt skeleton. Do not expand it into numerical strength or instructions for gradients, highlights, or shadows. Incidental gradients, shading, or mild dimensionality returned by the generator are acceptable and must not trigger filtering or retrying.
-- Keep the requested visual direction graphic and simple rather than asking for clay, inflatable, plastic, plush, toy-like, or photorealistic rendering.
-
-## Color and canvas
-
-- Default to exactly three semantic colors in the complete image: exactly two IP base colors plus exactly one background color.
-- Choose the two IP colors from the product context, subject identity, intended personality, and user request. Organize both into broad purposeful masses; reuse one for facial marks and keep the other in one continuous defining region rather than scattering decorative fragments.
-- Choose both subject colors independently from the background. Favor clear, lively subject colors when appropriate, but do not impose global saturation, OKLCH, hue-shift, or chroma bands on the IP.
-- Choose the background freely for the context or from a user-supplied palette. Unless the user asks for vivid color, gently mute the background by lowering its saturation a little; keep it clearly chromatic and intentional rather than vivid, gray, or muddy. Historical palettes and examples are suggestions only, never an allowlist or mandatory default palette.
-- Preserve clear visual separation between the dominant IP silhouette, its facial marks, and the background. If a user-supplied background causes weak separation, adjust the subject colors first rather than replacing the requested background.
-- Across a batch, vary the two-IP-color strategies deliberately instead of repeating the same neutral-heavy combination.
-- Treat the two character colors as semantic color families. Incidental tonal variation within either family does not invalidate an output.
-- Name the intended solid background color directly. Ask for it to fill every open area and the unoccupied corners while the assigned emergence corner is occupied by the character. Do not use image-mode terms such as `opaque`, `alpha`, or `transparency` in the generation prompt.
-- Generate a direct `1:1` square with square outer corners. Request approximately `1536 × 1536`; accept and preserve a native `1254 × 1254` result when that is the service output limit. Never resample merely to reach the requested number.
-
-## Prompt skeleton
-
-### Route constraints by generator capability
-
-Determine the available image model and its actual tool schema from runtime metadata, configured provider documentation, or an explicit user statement. Do not guess a model or invent unsupported parameters.
-
-Describe the requested visual as an image only. Never tell the image generator that the image is a `logo`, `brand mark`, `app icon`, `icon asset`, or intended for any of those uses. Do not prepend use-case or asset-type scaffolding that reveals such a use. This rule applies only to the generation prompt; the surrounding user conversation and Skill name may still describe the broader project.
-
-- For modern instruction-following image models such as GPT Image 2, Nano Banana Pro, Nano Banana 2, and Seedance 5.0 Pro, keep the complete positive prompt and express the minimal exclusions as the natural-language `Constraints:` line inside the main prompt. Do not create a separate negative-prompt payload for these models.
-- For an older model or runtime that explicitly exposes a dedicated parameter such as `negative_prompt`, keep every positive prompt line unchanged and deliver the minimal exclusions through that dedicated parameter in the syntax required by the available adapter. Omit the natural-language `Constraints:` line from the main prompt to avoid duplicating the same exclusions in both channels.
-- For an older model without a dedicated negative-prompt parameter, follow its documented prompt format. When only one prompt string is available, retain the concise natural-language `Constraints:` line.
-- Record the model or provider, the detected constraint-delivery mode (`main-prompt constraints` or `dedicated negative parameter`), and the exact constraint text or payload in the generation report.
-
-When a dedicated legacy negative-prompt parameter is available, adapt this minimal payload to its required syntax:
-
-```text
-text, watermark, borders, frames, cards, presentation masks, extra subjects, scenery, thin fragile lines, sharp tips, photorealistic materials, strong three-dimensional rendering, external cast shadows
-```
-For modern instruction-following models and single-prompt interfaces, use the following complete prompt:
-```
-```text
-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.
-
-## Delivery behavior
-
-- Treat generation as a stochastic draw, not a conformance test.
-- Generate the requested number of independent candidates once and deliver every returned image.
-- Do not inspect or report alpha, transparency, or background mode by default.
-- Do not block delivery, rank candidates as compliant or non-compliant, mark them as recommended or non-recommended, or automatically retry any result because of its background, colors, detail, composition, gradient, shading, or dimensionality.
-- Do not post-process a result to make it appear more compliant. If the user later requests another direction or replacement, generate a new independent candidate in response to that explicit request.
-
-## Source
-
-Rewritten for AICUT from [`hosted/ip-as-logo-skill`](https://github.com/hosted/ip-as-logo-skill)
-(MIT), SKILL.md. The method is that skill's own; the way it runs is AICUT's.

package/skills/ip-as-logo-s1dashu/SKILL.md

@@ -1,151 +0,0 @@
----
-name: ip-as-logo-s1dashu
-description: "Generate extremely simple, cute, personified square character images with rounded heavy forms, two purposeful character colors, one solid background color, and a dominant lower-corner composition. Use when creating an animal, creature, robot, ghost, plant, object, or other character image, including when the agent should infer three product-relevant directions and propose six independent candidates for approval. Runs in AICUT: the film is film.html, a page per shot, drawn by `aicut look` and `aicut render`."
-license: MIT
-source: "s1dashu/ip-as-logo-skill"
----
-
-# IP as Logo
-
-## Running it in AICUT
-
-AICUT's film is `film.html`: it cuts pages, footage, pictures and sound together on tracks. A page is a web page that
-sets `window.film = { frame(t) }` and draws that moment — no framework, no build step, no composition object, no
-`registerRoot`. Five shots are five pages cut together, not one page that changes scene, so each shot stays trimmable
-and replaceable in Studio.
-
-```sh
-npx -y @autoaiai/aicut@latest          # the manual: the format and the commands, always current
-npx -y @autoaiai/aicut@latest open .   # make this folder a film and print Studio's address
-npx -y @autoaiai/aicut@latest look     # a contact sheet of the whole film, its sound, and a determinism check
-npx -y @autoaiai/aicut@latest look 4.5 # one frame, full size — look at the PNG, not at the code
-npx -y @autoaiai/aicut@latest render   # the MP4, beside film.html
-```
-
-Run the manual before the first film: it is authoritative for the format, and this skill is about the method above it.
-
-Where the words below name another program's part, it becomes this:
-
-| elsewhere | in AICUT |
-|---|---|
-| composition, timeline, project file | `film.html`; tracks and clips inside it |
-| a scene, a sequence, a slide | a page (`pages/<name>.html`) cut onto a track |
-| `useCurrentFrame()`, `interpolate()` | `frame(t)` — the picture depends only on `t`, never on state or `Date.now()` |
-| a still, a screengrab | `aicut look <t>` |
-| `render` / `build` / `export` | `aicut render` (the person can also export from Studio) |
-| a dev server, a preview window | `aicut open` and the Studio address it prints |
-
-Hard rules that hold whatever the method says: the picture depends only on `t`; every value in the person's prompt is
-binding; look at the frames `look` writes before saying a film is done.
-
-
-Create the simplest possible cute IP character: a compact, lovable symbol that remains recognizable at `32 × 32`, not a detailed character illustration.
-
-## Workflow
-
-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 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. Before generation, require a top-tier image model: prefer GPT Image 2; also support Seedance 5.0 Pro, Nano Banana Pro (Gemini Image Pro), or Nano Banana 2 (Gemini Image Flash). If none is available, ask the user to enable a suitable tool or provide its API key. Never fall back to SVG generation. Use another available image model only with the user's explicit consent, and warn that its quality may not match the recommended models. Do not fabricate generated results.
-9. If the runtime supports subagents, parallelize the six independent candidates up to the available concurrency. Give every subagent the same product brief, shared constraints, and one assigned direction or variant; run remaining candidates in subsequent waves when capacity is limited. If subagents are unavailable, generate the candidates through separate image-generation calls or jobs.
-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. 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.
-- 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.
-
-## Shape language and composition
-
-- Use thick, rounded, weighty contours and broad color masses.
-- Forbid sharp corners, pointed ears or beaks, needle-like tails, thin antennae, thin smiles, narrow gaps, and acute flame or feather tips. Replace every necessary tip with a visibly blunt rounded end.
-- Show both members of paired identifying features, such as ears, horns, wings, gills, or bells.
-- Show the character upright and emerging from the assigned lower-left or lower-right corner, filling about `85–95%` of the canvas so the IP remains visually dominant.
-- Cropping at the bottom or assigned side is welcome when it strengthens the sense of emerging from that corner, but do not prescribe exact edge contact or a fixed crop.
-- Never center or bottom-center the character unless the user explicitly requests it.
-- Preserve both members of paired identifying features within the visible composition.
-- Keep the artwork upright; never rotate the canvas or tilt the main mark without an explicit request.
-
-## Simplicity and visual treatment
-
-- Start from large, clean semantic shapes and the strongest possible simple silhouette. The character should be understood immediately, before any internal feature is noticed.
-- Prefer fewer, larger, softer forms over extra definition. Do not add a feature merely to explain anatomy or material.
-- Keep facial marks tiny, simple, and subordinate. Do not add glossy hotspots or detailed cavity rendering to eyes, mouths, noses, or other small features.
-- Keep the named background color visually solid and uniform, without scenery, texture, halo, vignette, or lighting variation.
-- Ask for the subtle dimensional effect only with the single sentence used in the Prompt skeleton. Do not expand it into numerical strength or instructions for gradients, highlights, or shadows. Incidental gradients, shading, or mild dimensionality returned by the generator are acceptable and must not trigger filtering or retrying.
-- Keep the requested visual direction graphic and simple rather than asking for clay, inflatable, plastic, plush, toy-like, or photorealistic rendering.
-
-## Color and canvas
-
-- Default to exactly three semantic colors in the complete image: exactly two IP base colors plus exactly one background color.
-- Choose the two IP colors from the product context, subject identity, intended personality, and user request. Organize both into broad purposeful masses; reuse one for facial marks and keep the other in one continuous defining region rather than scattering decorative fragments.
-- Choose both subject colors independently from the background. Favor clear, lively subject colors when appropriate, but do not impose global saturation, OKLCH, hue-shift, or chroma bands on the IP.
-- Choose the background freely for the context or from a user-supplied palette. Unless the user asks for vivid color, gently mute the background by lowering its saturation a little; keep it clearly chromatic and intentional rather than vivid, gray, or muddy. Historical palettes and examples are suggestions only, never an allowlist or mandatory default palette.
-- Preserve clear visual separation between the dominant IP silhouette, its facial marks, and the background. If a user-supplied background causes weak separation, adjust the subject colors first rather than replacing the requested background.
-- Across a batch, vary the two-IP-color strategies deliberately instead of repeating the same neutral-heavy combination.
-- Treat the two character colors as semantic color families. Incidental tonal variation within either family does not invalidate an output.
-- Name the intended solid background color directly. Ask for it to fill every open area and the unoccupied corners while the assigned emergence corner is occupied by the character. Do not use image-mode terms such as `opaque`, `alpha`, or `transparency` in the generation prompt.
-- Generate a direct `1:1` square with square outer corners. Request approximately `1536 × 1536`; accept and preserve a native `1254 × 1254` result when that is the service output limit. Never resample merely to reach the requested number.
-
-## Prompt skeleton
-
-### Route constraints by generator capability
-
-Determine the available image model and its actual tool schema from runtime metadata, configured provider documentation, or an explicit user statement. Do not guess a model or invent unsupported parameters.
-
-Describe the requested visual as an image only. Never tell the image generator that the image is a `logo`, `brand mark`, `app icon`, `icon asset`, or intended for any of those uses. Do not prepend use-case or asset-type scaffolding that reveals such a use. This rule applies only to the generation prompt; the surrounding user conversation and Skill name may still describe the broader project.
-
-- For modern instruction-following image models such as GPT Image 2, Nano Banana Pro, Nano Banana 2, and Seedance 5.0 Pro, keep the complete positive prompt and express the minimal exclusions as the natural-language `Constraints:` line inside the main prompt. Do not create a separate negative-prompt payload for these models.
-- For an older model or runtime that explicitly exposes a dedicated parameter such as `negative_prompt`, keep every positive prompt line unchanged and deliver the minimal exclusions through that dedicated parameter in the syntax required by the available adapter. Omit the natural-language `Constraints:` line from the main prompt to avoid duplicating the same exclusions in both channels.
-- For an older model without a dedicated negative-prompt parameter, follow its documented prompt format. When only one prompt string is available, retain the concise natural-language `Constraints:` line.
-- Record the model or provider, the detected constraint-delivery mode (`main-prompt constraints` or `dedicated negative parameter`), and the exact constraint text or payload in the generation report.
-
-When a dedicated legacy negative-prompt parameter is available, adapt this minimal payload to its required syntax:
-
-```text
-text, watermark, borders, frames, cards, presentation masks, extra subjects, scenery, thin fragile lines, sharp tips, photorealistic materials, strong three-dimensional rendering, external cast shadows
-```
-For modern instruction-following models and single-prompt interfaces, use the following complete prompt:
-```
-```text
-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.
-
-## Delivery behavior
-
-- Treat generation as a stochastic draw, not a conformance test.
-- Generate the requested number of independent candidates once and deliver every returned image.
-- Do not inspect or report alpha, transparency, or background mode by default.
-- Do not block delivery, rank candidates as compliant or non-compliant, mark them as recommended or non-recommended, or automatically retry any result because of its background, colors, detail, composition, gradient, shading, or dimensionality.
-- Do not post-process a result to make it appear more compliant. If the user later requests another direction or replacement, generate a new independent candidate in response to that explicit request.
-
-## Source
-
-Rewritten for AICUT from [`s1dashu/ip-as-logo-skill`](https://github.com/s1dashu/ip-as-logo-skill)
-(MIT), SKILL.md. The method is that skill's own; the way it runs is AICUT's.