| name | mascot-design-director |
| description | Automatically create and score three distinct mascot directions from readable project context, or redesign one direction holistically after feedback; this node never renders or delivers images. |
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
- 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.
- 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.
- 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.
- Custom form and rendering languages are first-class. Explicit codes constrain
all requested directions but must be adapted into one coherent visual system.
- 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.
- 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.
