mascot-ip-studio

name	mascot-ip-studio
description	Coordinate original mascot requests for projects, accounts, or folders, directly producing three distinct complete IP candidates; exclude personal-photo asset packs.

Mascot IP Studio Orchestrator

Act only as workflow controller. Maintain state, resolve what the user's latest message actually confirms, and route one specialist node. Do not perform art direction, render images, review images or expand assets inside this Skill.

This is the implicit entry point for a request to create an original mascot for a project, product, brand, account or folder. It is not the personal-photo asset-pack workflow: requests to turn the user's or an authorized person's photos into portraits, avatars or a reusable photo asset set belong to personal-ip-image-pack. An original non-human mascot requested for an account or folder still belongs here.

Read the workflow state contract before routing. Use the existing scripts/workflow_state.py helpers for state and output-contract transitions.

Nodes

Each node is independently callable when its input contract is satisfied:

1. mascot-intake — evidence, subject and hard constraints.
2. mascot-design-director — three scored concept directions or one holistic redesign brief; no image calls.
3. mascot-candidate-renderer — renders A/B/C as three different complete IP images.
4. mascot-delivery-review — visual and anatomy QA, delivery, revision guidance and mandatory gallery links.
5. mascot-revision-director — turns every user correction into a coherent whole-character redesign.

Routing rules

1. Start with intake unless current conversation state already satisfies it.
2. Intake reads the supplied project/account/folder materials first. When the materials are readable, do not ask the user to choose a species or visual style; pass the evidence to the design director, which decides three different role concepts automatically. Ask one concise question only when unreadable or missing information would materially change the work.
3. Route the brief to the design director for internal A/B/C planning, then route its three records directly to the renderer. A/B/C are internal planning labels, not a text-only approval step and not a reason to ask the user to choose before rendering.
4. Generate and validate the internal contract with scripts/workflow_state.py::build_default_output_contract. It contains exactly three separate square full-body IP images: A, B and C. This automatic guard must not create another user confirmation step. Every new direction must also define visible support and manipulation structures so the mascot can later stand and interact in article scenes. Unless the user explicitly locks a specific subject class, A/B/C defaults to three distinct subject classes: A (动物 / 自然生灵)、B (奇幻生物 / 精怪生灵)、 C (机械生命 / 系统拟人)，ensuring maximum concept and material diversity. B direction covers animated objects/plants (草木成灵、物件成精) and folklore/mythical spirit creatures, excluding abstract elementals. Every direction must prove its artistry and recognition through an intrinsic form/surface plan that remains readable at thumbnail size. The clean candidate is front-primary with only a slight turn and upright self-support; it need not use feet or a bipedal human skeleton. Horizontal quadrupeds, prone poses and side profiles are invalid.
5. Route every generated image to delivery review before showing it as a valid candidate. Every A/B/C delivery must immediately include the guided footer: reassure users who do not know how to revise that they can browse the DG form and MS rendering template libraries, show both clickable links, and explain that replying with only a code or vague preference is enough.
6. A bare A/B/C choice is not a final decision. After delivery, it selects the direction for continued revision or combination; short assent such as “可以” or “好” is not enough to finalize.
7. Only an unambiguous final confirmation paired with a candidate, such as “满意 A”, “A 就这个” or “C 定稿”, after QA authorizes final delivery. Copy exactly that one QA-approved candidate to <target-project-root>/assets/mascot-ip/mascot.png, where the target root is the project/account/folder supplied by the user. Never write the final image into the installed Skill directory. Do not create any other final asset and do not use master or prototype state.
8. Route all modification feedback to the revision director. After it returns a redesigned direction, use scripts/workflow_state.py::build_revision_output_contract and regenerate only the affected A/B/C candidate.

Non-negotiable boundaries

• The delivery is three different complete IP candidate images.
• This project does not produce anchor images, turnarounds, three-view sheets, or derivative asset packs. Do not suggest or inherit them from another Skill.
• A revision regenerates the affected candidate only.
• A/B/C selection alone is never final; explicit final wording is required before the single assets/mascot-ip/mascot.png delivery.
• Do not ask for or declare a master or prototype; neither term has workflow meaning here.
• Do not skip visual QA. Creativity never excuses duplicated tails, limbs, ears, wings, horns, fused anatomy or unclear attachment points.
• Every new candidate and revision must visibly support stable standing and object manipulation. Hands are optional; claws, wing-hands, fins, tentacles or another non-human equivalent are valid only when their grasping mechanism and attachment are clear.
• Surface treatment must be globally coherent: preserve natural markings across the whole character or redesign them across the whole character, never mix natural patches with unrelated body blocks. A tail is either absent or one proportional anatomical appendage with a clear root.
• Do not default to animals. Non-animal object, mechanical/system and abstract-symbol lifeforms are first-class mascot identities and must not acquire arbitrary animal anatomy.
• Do not default to people or human skeletons. Anthropomorphism may come from expression, gesture or symbolic behavior, not a human head-torso-two-arms-two-legs body template.
• Every delivered image must leave the user a guided revision path. A revision is holistic redesign, not local patching.

Shared sources

The design director owns the DG form library and design playbook. The renderer may read the root MS rendering library only through an art-direction record. The review node owns the mandatory post-delivery gallery links. Keep specialist knowledge in its node instead of growing this orchestrator.