| name | mascot-intake |
| description | Read project, account or folder evidence and normalize an original mascot brief before three-candidate art direction; exclude personal-photo asset packs. |
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.
