Design and produce an approval-gated, reusable avatar or digital-employee IP system with identity masters, modular assets, scenes, motion, manifests, and QA.
Design and produce an approval-gated, reusable avatar or digital-employee IP system with identity masters, modular assets, scenes, motion, manifests, and QA.
--- name: produce-avatar-ip-system description: Design and produce a reusable avatar or digital-employee IP system across cute, chibi, stylized 3D, semi-real, or realistic directions, including identity masters, modular outfits and props, editable backgrounds, scene variants, loop videos, Figma components, manifests, and production QA. Use for character-system creation or refinement; do not use for application-code integration, pull requests, or product UI implementation. license: MIT metadata: version: '1.2.0' author: Edward-J-create repository: https://github.com/Edward-J-create/produce-avatar-ip-system --- # Produce Avatar IP System ## Scope boundary This Skill ends at reviewed source assets, Figma organization, prompt documentation, manifests, QA reports, and delivery packages. Do not edit application code, create branches, commit, push, open a pull request, or implement product UI under this Skill. Treat later product integration as a separate task with separate authorization. ## Inputs Collect these inputs before production. Propose safe defaults for low-risk omissions, but do not infer identity, anatomy, rights, or budget decisions. - The avatar purpose, audience, brand context, usage channels, and requested deliverable matrix. - Any identity, signature-look, composition, style, palette, logo, product, scene, or motion references, each assigned an explicit role. - Per-persona presentation and body construction, face, hair, signature outfit, wearables, props, palette, and composition choices. - Required aspect ratios, output sizes, transparent-background needs, Figma destination, filenames, and delivery location. - Rights status for supplied and generated materials, the approval owner, paid-generation budget, and target provider or model constraints. If no visual source exists, begin with two or three labeled parameter stacks. If a source exists, preserve its highest-resolution approved form and never replace it with a degraded derivative. ## Outputs A complete delivery contains the following evidence, not just final images: - A filled project brief, reference-role map, persona contracts, IP template selections, and versioned prompt contract. - One approved neutral construction master and one approved signature-look master for each persona. - Approved modular palettes, outfits, wearables, props, combinations, transparent subject masters, editable backgrounds, and composed scene previews. - Approved representative motion plus requested loop-video variants, with first-frame and model provenance. - Figma organization when requested, including verified nodes and replaceable backgrounds rather than flattened mock structure. - Resolved prompts, model and Action receipts, approval receipts, contact sheets, asset manifest, QA report, and a resumable acceptance ledger. ## Loadout capabilities Use only capabilities that are available and appropriate for the current route. The original workflow used OpenAI host ImageGen for much of the static production, Fal through Aident for explicit provider comparisons and motion, Figma for organization, and local Pillow and FFmpeg for deterministic media work. Host tools and Figma are not Loadout Actions unless the current environment exposes them that way. - List current Fal text-to-image models before selecting a non-default endpoint: <action-tag>direct:fal:fal_list_text_to_image_models</action-tag> - Generate a reviewed representative text-to-image candidate: <action-tag>direct:fal:fal_text_to_image</action-tag> - List current Fal image-edit models before selecting a non-default endpoint: <action-tag>direct:fal:fal_list_image_edit_models</action-tag> - Make a one-axis image correction from approved references: <action-tag>direct:fal:fal_edit_image</action-tag> - List current Fal image-to-video models before motion work: <action-tag>direct:fal:fal_list_image_to_video_models</action-tag> - Animate one approved representative scene, then batch only after approval: <action-tag>direct:fal:fal_image_to_video</action-tag> - Create a temporary provider-readable upload URL only when a local source file must be passed to a remote model: <action-tag>direct:file_storage_tools:file_create_upload_url</action-tag> Inspect the live schema and price before every paid generation. Ask for explicit approval before a paid call, a write to an external destination, a larger batch, or a model change. A timeout has an unknown outcome; inspect history before retrying. Never guess a model name. When the host result does not expose a concrete model ID, record `OpenAI host ImageGen`. When an endpoint is explicit, record the complete provider ID returned by the live catalog. ## Operating invariants - Separate `identity`, `style`, `presentation`, `scene`, `background`, and `motion`. Lock each upstream layer before multiplying downstream variants. - Resolve the idea through separately selectable style, head/body ratio, gender presentation, body construction, face, hair, outfit, wearable, prop, palette, and composition dimensions. - Do not infer anatomy from gender presentation. Select and preserve the body contract explicitly. - Classify every reference. A composition source cannot override an identity source. - Treat the latest approved high-resolution identity source as the source of truth for every identity-critical generation. - Lock one anchor persona before expanding the cast. Approve its neutral construction master and signature-look validation as a pair. - Treat approval as axis-scoped. An unqualified approval covers only the clearly labeled assets and axes shown in the current review board. - Change one axis at a time. A prop correction must not silently change face, hair, skin tone, outfit, crop, lighting, or background. - Generate real raster character material with an image model. Use Figma to organize, compose, document, expose variants, and keep backgrounds editable. - Deliver transparent subject, editable background, and composed preview separately whenever replacement is required. - Verify actual alpha, corners, edge matte, and hidden RGB. A checkerboard appearance is not proof of transparency. - Define held objects physically: front and back planes, hinges, labels, screens, grip, and hand contact. - Verify each uploaded or replaced Figma node with fill or hash evidence and a fresh screenshot. - Do not add logos, symbols, text, halos, or brand marks unless requested. ## Approval-gated workflow ### 1. Intake and direction approval Translate the brief into two or three materially different parameter stacks, or adopt an already approved stack. Label every changed dimension and show a compact direction board. Stop for the approval owner to select the style, proportion, presentation, body construction, palette, and overall character direction. Record the approved direction, source roles, non-goals, formats, budget, and provider constraints in the acceptance ledger. Do not begin a paid generation or cast batch at this stage without separate approval. ### 2. Anchor identity and signature-look approval Select one anchor persona. Produce a paired review board containing: 1. A forced front-facing neutral construction master that exposes proportions, face, hair, body contract, and silhouette. 2. A signature-look validation that reconstructs the supplied or approved outfit and accessory language without changing identity. Compare both directly with the highest-resolution identity source at detail and real product size. Record an axis-scoped approval receipt. Do not seed the cast from a composition-correct but identity-drifted candidate. ### 3. Cast approval Expand the remaining personas only from the approved anchor contract. Review the cast together for identity separation, family resemblance, scale, construction consistency, and presentation. Stop for cast approval before producing modular matrices. ### 4. Modular-system approval Reconstruct each approved signature outfit before inventing derived outfit families. Then vary palette, outfit, wearable, prop, and requested combinations one axis at a time. Return labeled contact sheets at detail and product size. Stop for explicit approval of the modules and combination matrix. ### 5. Scene and background approval From approved combinations, produce transparent subject masters, editable background plates or tokens, and composed previews. Verify alpha and edge quality. Stop for scene and background approval before animation. ### 6. Representative motion approval Choose the most failure-prone approved scene. List current video models, inspect the exact live schema and price, and ask for approval for one representative paid call. Use a true first-frame input. When supported, use the same approved frame as the end frame for a loop. Inspect identity, hands, props, seams, temporal stability, duration, resolution, frame rate, and first/last continuity. Stop for motion approval. ### 7. Approved batch, Figma organization, and delivery Batch only the explicitly approved matrix. Preserve prompt, model, Action, input, cost, and output receipts. Organize approved assets in the supplied Figma target without overwriting confirmed nodes. Package only approved files, manifests, receipts, contact sheets, and QA evidence. Approval of one stage never silently approves the next stage, a larger batch, a different model, or a different style version. ## Production and recovery rules - Run one representative sample before any batch. Estimate the number of paid calls and present the estimate for approval. - If identity drifts, return to the latest approved identity master and reapply only the intended axis. Do not repair from the drifted derivative alone. - If a prop or hand fails, isolate the object geometry and contact relationship in an image-edit pass while locking every unrelated attribute. - If transparency fails, normalize from the approved source and verify pixel alpha. Do not call a background-colored image transparent. - If a Figma replacement is uncertain, compare the intended node, applied fill or hash, and a fresh screenshot before continuing. - If an external call times out, treat the result as unknown and inspect provider or Loadout history before resubmitting. - If a required capability is unavailable, stop with a precise blocker and preserve resumable state. Do not substitute an unrelated App or Action. ## Delivery QA Before delivery, verify: - Every promised matrix cell exists once, uses the approved persona and style version, and has a unique manifest row. - Identity, anatomy, face, hair, skin tone, silhouette, signature look, composition, and requested axis match their approved contracts. - Transparent masters have real alpha and clean edges; editable backgrounds remain separate; composed previews point to both sources. - Every image opens and records format, bytes, dimensions, alpha state, and SHA-256 when bytes are available. - Every video opens and records model ID, Action, dimensions, duration, frame rate, audio state, first/last-frame inspection, and loop result. - Figma nodes resolve to the intended target and have fresh visual verification. - Prompt revisions, model revisions, approval receipts, provenance, and the acceptance ledger agree with delivered filenames. - No rejected or superseded candidate is labeled approved or delivered. Use the synced companion helpers for deterministic scaffolding, prompt assembly, contact sheets, image normalization, and delivery inspection. Run each helper with `--help`, write into a task-specific output directory, and never overwrite the last approved source before its replacement passes. ## Completion criteria The work is complete only when the requested system is approved stage by stage and another agent can resume from the brief, parameter selections, prompt contract, acceptance ledger, approval receipts, manifest, and approved files without relying on chat history. Report any blocked, proposed, or omitted matrix cell honestly; a contact sheet, storyboard, or upload acknowledgement is not a finished asset.
