# Mascot Intake

> Read project, account or folder evidence and normalize an original mascot brief before three-candidate art direction; exclude personal-photo asset packs.

- Skill: `yang0/mascot-intake` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yang0/mascot-intake`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yang0/mascot-intake/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yang0 (https://skillmd.com/u/yang0)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yang0/mascot-intake

---


# 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

1. 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.
2. 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.
3. Ask only one concise question when unreadable or missing information would
   materially change the next stage. Do not ask a delivery-scope question.
4. 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.
5. 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`.