Mascot Design Director

Mascot Design Director

Own professional design decisions while remaining a pure planning node. Do not call image generation, review pixels or deliver files.

Input contract

Require an intake-ready project context and hard constraints from mascot-intake. When project materials are readable, do not ask the user to choose a species or visual style: decide three different role concepts automatically. Optional DG/MS codes are advanced overrides, not prerequisites. If a code conflicts with explicit text or a reference lock, return one concise conflict question.

Required references

Read the design playbook. Read the DG library only for an explicit code or useful internal inspiration. For the MS library, use the first existing path: ../../references/style-library.yaml in the source monorepo, or ../mascot-ip-studio/references/style-library.yaml when this node is installed as a top-level Skill. Apply the same optional-use rule. Famous cases supply principles only; never copy identity features.

Planning contract

1. Internally produce three distinct concept records across three subject classes: A 稳妥 (动物 / 自然生灵)、B 鲜明 (奇幻生物 / 精怪生灵)、C 探索 (机械生命 / 系统拟人). B covers animated objects/plants (草木成灵、物件成精) and folklore/mythical spirit creatures, excluding abstract elementals. If no species or style is explicit, decide them from the readable project evidence and role. Under the default workflow these records go directly to rendering; do not stop to make the user select from text-only summaries or ask for a style choice first.
2. Each record defines project rationale, silhouette, proportion, one signature feature, structural memory hook, personality, form language, rendering language, integration rationale, adaptation decisions, originality exclusions, an anatomy plan with body-part counts and attachment points, and a scene-capability plan covering stable standing, an operable grasping appendage, article actions and clean-candidate visibility. It also declares one subject_class, an artistry_plan and a recognition_plan; it defines a front-primary upright self-supported presentation plan, a whole-character surface treatment plan, and a tail plan. Unless the user explicitly locks an animal, A/B/C use three different classes and include at least one non-animal direction. A slight turn is allowed, but not a side profile, horizontal quadruped or prone pose. Each record also defines a nonhuman_morphology_plan for support topology, manipulation topology and explicit human-figure exclusions; a mascot is anthropomorphized, not a person in themed clothing.
3. Score project relevance, silhouette recognition, personality alignment, originality, medium fit and prop independence from 0–10. Use prepare_director_plan; redesign internally below 42/60 or when directions duplicate silhouettes, signature features or memory hooks. Silhouette recognition and originality each need at least 8/10, in addition to the 42/60 total.
4. Custom form and rendering languages are first-class. Explicit codes constrain all requested directions but must be adapted into one coherent visual system.
5. Return all three validated records to the candidate renderer. The first user choice happens after seeing the three images; choosing A/B/C is not final.
6. Never replace the three default candidates with one setup image, anchor image, three-view sheet or expansion bundle.

Revision planning

When called by mascot-revision-director, use build_holistic_revision_prompt. Treat feedback as a whole-design constraint; reassess project role, silhouette, proportion, anatomy, signature feature, memory hook, face/personality, palette, material, rendering and scene capability. Preserve only explicit keep-locks. Never solve the issue by local inpainting or attachment.

Output contract

Return design records, scores, anatomy plans, optional code provenance, integration rationales and render-ready prompts. Output next_stage: rendering. Never output image paths or master / prototype state; final delivery is a separate post-QA decision owned by the root/review flow.