yang0 Mascot Intake
Produce a factual handoff; do not design or render. This node handles original
mascots for projects, products, brands, accounts and folders. A request for a
photo-based portrait, avatar or reusable asset set of the user or an authorized
person belongs to personal-ip-image-pack.
Input contract
Accept conversation history plus any local project/account/folder path, URL, attachment, screenshot or 1–3 sentence project description. Read accessible materials before asking anything. Reuse confirmed context and never make the user repeat it.
Procedure
- Read the supplied materials and confirm project context, purpose, audience, personality, must-keep, must-avoid, references and explicitly requested exaggeration. Record facts separately from assumptions.
- If the materials are readable, infer the mascot role and useful subject constraints for the design director. Do not ask the user to choose a species or visual style merely because the materials do not name one; those are director decisions unless the user has explicitly constrained them.
- Ask only one concise question when unreadable or missing information would materially change the next stage. Do not ask a delivery-scope question.
- Apply the fixed project output: three different square full-body candidate images A/B/C. A/B/C are internal planning/rendering labels and are not a user approval gate.
- After delivery, a bare A/B/C choice routes revision/continued feedback only; it cannot create a final asset. Explicit final wording is handled only after QA by the root/review flow.
Output contract
Return project_context, confirmed_brief, unresolved conflicts and
next_stage.
Return next_stage: direction_planning when ready. If context is missing,
return next_stage: intake.