name: motion-sticker-pack description: Create an animated sticker pack from a supplied character image or a text-defined character by collecting a style and Emoji or short reaction descriptions, generating and approving a static sheet, then routing video generation, cleanup, splitting, and packaging. Also process existing static sheets or grid videos. Use for animated emoji or sticker-pack production, not for designing a separate character identity artifact or general video editing.

Motion Sticker Pack｜动态表情包制作器

Create a usable animated sticker pack, not merely a video preview. Preserve the supplied character identity and produce independently looping stickers, transparent first frames, a machine-readable report, and a ZIP.

IP identity and prompt principles

• Before writing a generation prompt, inspect the supplied image and derive the IP's visible identity features: face, hair or fur, silhouette and proportions, colors, clothing, accessories, existing props, pose language, scene cues, and overall mood.
• Build the prompt from those observed features plus the user's selected style and reactions. Preserve the supplied IP's appearance and source-specific details by default; change them only when the user asks for a change.
• Unless the user requests another presentation, use the default static-sheet treatment: a 3×3 illustrated reaction-card grid with no white border or heavy outline, subtle local background accents in each cell, and a consistent overall color tone. This changes the visual treatment, not the transparent-alpha and cell-isolation requirements.
• Interpret each Emoji or text reaction semantically. Offer a compact choice for short reaction text: default to avoiding text, while allowing the user to opt in. This is a preference, not a rejection gate—if the model adds text despite the default, keep the sheet eligible for review and let the user decide whether to keep it. When it helps the expression read clearly, add a small number of matching decorative accents—such as hearts, music notes, sparkles, tears, blush marks, sweat drops, motion lines, or stars—using the selected style's visual language. Use them selectively rather than forcing the same accents into every cell, and do not turn them into unrelated large props.
• Do not add unsolicited moral, modesty, sexualization, age, wardrobe, pose-cleanup, or scene-removal instructions. In particular, do not insert wording such as “改成得体、日常、非性感化的简化服装” or “不要保留汽车、夜景、原照片背景或暧昧姿势” unless the user explicitly requests that transformation.
• Keep the source reference label neutral (for example, 所附图像 or 附件中的角色参考图). Do not encode an unrequested redesign into reference_label.
• A transparent sticker sheet may require removing the source background as a technical canvas operation, but do not otherwise remove existing clothing, props, setting cues, or pose characteristics unless requested. If the user wants the original scene retained, preserve it within each cell where technically feasible.

Pre-generation fidelity check

Before writing a prompt or an intake/confirmation message, explicitly check that no unrequested transformation has been introduced. Remove any wording or instruction that asks to make the character more “得体、日常、非露骨、非性感化”, to simplify or replace clothing, clean up the pose, remove scene cues, or make the result “适合公开分享”. These are not defaults. Preserve the supplied character's observed appearance, clothing, pose language, props, setting cues, and mood unless the user requests a change or a higher-priority platform safety rule requires one. If a safety-driven change is required, state only the necessary constraint and do not broaden it into an aesthetic redesign.

Ambiguous-request confirmation

• When the user supplies a character image but does not specify a style, reactions, or both, do not generate immediately. First present a concise confirmation card with the proposed defaults: 3D 卡通风, the illustrated reaction-card treatment, a practical set of nine chat reactions (开心、喜欢、委屈、惊讶、亲亲、谢谢、加油、困困、点赞), and the default 3×3 layout.
• When no character image is supplied, accept a named or text-defined character and use the same intake defaults when style or reactions are missing. After confirmation, generate the complete static sheet directly. Do not insert a separate single-character concept image, identity card, or character-approval stage.
• State that the prompt will be derived from the image's observed IP features and the selected style, with the character's appearance and source details preserved by default. Do not add redesign or moralizing constraints.
• Accept either an explicit confirmation (确认 / 开始生成) or a revision such as 风格改为写实还原 or 表情改为 🎸😍🥹😘🥰. After a revision, show the updated summary and wait for confirmation again. Once confirmed, generate the static sheet directly, then follow the normal layout inspection and static-review gate before any video generation.
• If the user already supplied both a clear style and reactions, skip this intake confirmation and proceed to static generation. The post-generation static-review approval before video remains mandatory.

Non-negotiable invariants

• Treat the image model's requested grid as a preference, not observed fact. After image generation, inspect the returned sheet and write detected_layout; every later stage must use that result.
• Compile every static request with image_generation_request.arguments.background and image_generation_request.arguments.output_format. Select the background policy by input mode: reference-image generation uses an opaque, uniform #00FF00 source first because the current Codex image_gen runtime does not reliably return native Alpha with a reference image; text-defined generation uses transparent-first because it can emit native Alpha. Pass the resolved fields when the callable image_gen schema exposes them; when it does not, omit only unsupported fields and record them in static-generation.json. In both modes, inspect returned pixels, reject checkerboards and non-uniform backgrounds, and locally convert only an accepted native Alpha or uniform key to the final real Alpha sheet. Do not override the reference-image policy by merely adding a transparent prompt.
• Express layout unambiguously as columns × rows. Derive count = columns * rows; never mix 3×3 with 12 items or 4×3 with 9 items.
• If automatic layout confidence is below 0.75, inspect the overlay/report and confirm or override the grid before animation or cropping.
• When this Skill generated the static illustrated-card sheet, never generate video until the user explicitly approves that exact sheet. Regeneration invalidates the old approval and all downstream artifacts.
• Persist the review revision with scripts/manage_job_state.py. Hash verification is mandatory before bundled Provider execution; a conversational “approved” flag alone is insufficient.
• Keep the camera fixed. Each cell moves only inside its own bounds. Do not invent characters, new captions, large props, scenery, or cross-cell effects. Preserve any text or symbols already present in the approved source, including when they were model-generated. Small semantic reaction accents are allowed when they support the requested emotion and remain inside the cell. Preserve source elements when they already exist in the approved source unless the user asks to remove them or transparent-sheet/cell-isolation requirements make that technically necessary.
• Do not trust a video model or adapter's claimed transparency. Decode the returned video with the local Alpha probe. Prefer real alpha when detected; otherwise use a uniform key that contrasts with the character (chroma such as green or magenta, not a near-black or near-white plate) and deterministic local matting.
• For Grok image-to-video, the output contract is stricter: use #00FF00, never a checkerboard or simulated transparency. The input sent to Grok must already have real alpha (or a verified uniform green plate), and scripts/grok_build_video_adapter.py must pass every native returned frame through background QC. Each execution makes exactly one Grok call (max_retries: 0) and must never fall through to local animation. A user-requested new execution is allowed only after a separate, explicit retry approval bound to the same approved inputs and route; it is never an implicit replay.
• For Grok image-to-video, compile a compact execution prompt from the approved per-cell tile-plan.json: keep the grid dimensions, identity lock, fixed-camera rule, one action per cell, green-screen contract, and loop timing, while removing repeated prose. Keep the final adapter instruction below 3,800 UTF-8 bytes so Grok's 4,096-byte CLI limit is not reached; reject early with a local validation error if a custom tile plan still exceeds the budget.
• Never put credentials in prompts, config files, reports, command arguments, or logs. Configuration refers to environment-variable names only.
• Keep every generated artifact for one character under works/<character-slug>/ in this skill directory. Do not write new job files to the skill root or a shared work/ folder. Resolve the directory with scripts/character_workspace.py --name <角色名> before static generation.
• Treat assets/sticker-production.default.json as the single editable production-default file. Validate it with scripts/sticker_production_config.py; copy it into each work directory as sticker-production.json so generation and post-processing use the same immutable job snapshot. Do not duplicate duration, size, fps, color-budget, key-color, or GIF-budget defaults in prompts or scripts.
• Treat each static image-generation attempt as a billable, non-idempotent operation. Before calling the image tool, claim it with scripts/static_generation_guard.py claim; immediately before the call, mark it invoked. After the call, resolve the result before considering any retry. The current image tool may return a top-level image_url and output_hint, a data URL/image bytes, or an image block under content; absence of content alone is never a failure. Copy or materialize the first usable result to static-sheet-source.png, then mark the attempt accept. Only an explicit provider failure with no artifact, or a local normalization/QC rejection recorded with reject, may unlock the bounded fallback attempt. Keep static-generation-attempts.json beside static-generation.json.

Workflow

1. Inspect the input and choose an entry mode:
   • personal IP handoff → read references/personal-ip-handoff.md, run scripts/import_personal_handoff.py <handoff.json> --work-dir <work_dir>, and use the imported character.json as the job-local identity/style/reaction manifest; never copy the original photo or edit the personal card;
   • character reference → read references/intake-and-approval.md; if the request is vague, present the default proposal and wait for confirmation before generating the static sticker sheet;
   • named or text-defined character without an image → compile that definition and generate the full static sheet directly; do not generate a separate character image first;
   • static sheet → detect the actual grid;
   • grid video → obtain the source sheet/layout or extract a representative frame with ffmpeg -y -i input.mp4 -frames:v 1 representative-frame.png, then detect the grid;
   • separate static stickers → do not invent a grid; run scripts/process_independent_stickers.py <input-dir> <output-dir> --manifest <work_dir>/artifact-manifest.json;
   • user-supplied static sheet → create state with --source-type user-supplied and skip the explicit approve step; it is already the selected source.
2. Choose a short character name and resolve the work directory with scripts/character_workspace.py --name <角色名>. For a personal handoff, import first and keep the received handoff.json plus character.json in that work directory; use the verified absolute anchor, resolved_style, and resolved_reactions from character.json, and do not route through the generic photo intake. For other entry modes, compile the confirmed style and reactions into <work_dir>/static-prompt.json: use --reference-image <source-image> when supplied, or --character-description <definition> when no image exists. The no-image route goes straight to one complete sheet. Inspect the callable image_gen schema and run scripts/prepare_image_gen_call.py, repeating --supported-argument for its exposed fields. The compiled contract automatically selects opaque-green-first for reference images and transparent-first for text-defined characters; static-generation.json records the source mode, resolved policy, passed/omitted fields, bounded retry, and single-call execution protocol. Create the attempt ledger and claim attempt 1 with scripts/static_generation_guard.py; mark it invoked immediately before the one image call. Resolve the returned object in this order: top-level image_url/output_hint, top-level data URL or bytes, then content image block. Do not call again merely because the host did not render the result. Save the first usable raw result as <work_dir>/static-sheet-source.png and mark it accepted. A reference-image request must use a backend that accepts that exact image; a text-defined request may use text-only generation.
3. Run scripts/normalize_static_sheet.py <work_dir>/static-sheet-source.png <work_dir>/static-sheet.png --report <work_dir>/static-alpha.json. Native alpha is preserved for text-defined generation when present. Reference-image generation is expected to be opaque: accept only a uniform, high-contrast chroma key (normally #00FF00) suitable for deterministic local matting. Simulated checkerboards/two-tone previews, light plates, gradients, scenery, and ambiguous backgrounds fail closed. If local normalization rejects the accepted raw result, mark attempt 1 reject with the QC reason, then claim and invoke the recorded opaque fallback exactly once; never replay an unresolved attempt. Save the retry result as the new raw source, mark it accepted, and re-run normalization; if it still fails, stop and request regeneration rather than sending the bad sheet to video. Inspect only the normalized <work_dir>/static-sheet.png with scripts/inspect_sticker_sheet.py, then create the hash-bound static-review state.
4. For a generated or regenerated sheet, show the normalized sheet, detected layout, text_policy, and static-alpha.json warnings. If text appeared, report it as an observation only; do not reject or auto-regenerate for that reason. Offer 确认，继续生成视频 or 重新生成. Stop and wait. Do not route or call video generation while the sheet is unapproved. For a user-supplied sheet, report the detected layout and continue without asking for a duplicate approval.
5. After explicit approval of a generated sheet, record it with scripts/manage_job_state.py approve; for a user-supplied sheet, use the already static-approved state created with --source-type user-supplied. In both cases use the exact source image. For animation prompt rules, read references/prompt-contract.md and write a tile-plan.json with exactly one vision-informed entry per detected cell. Compile it with scripts/prompt_compiler.py. Do not use generic motions unless explicitly accepting the lower-quality fallback.
6. For backend discovery and selection, read references/runtime-routing.md. Inspect callable tools/skills in the current runtime first and record their exact names, reference-image support, video support, and cost status in <work_dir>/runtime-tools.json. Then run scripts/prepare_workflow.py --character <角色名> --skill-root /Users/bingo/Documents/ChatGPT/motion-sticker-pack when working from this repository, so video-providers.json, video-task.json, and artifact-manifest.json land in the same works/<slug>/ directory; use --provider <id> and repeated --fallback-provider <id> for task-level selection instead of editing the shared template. Use those same files for probe, route, and execute. Routing creates attempt-ledger.json; review the route preflight before any external execution.
7. Execute the selected mode:
   • native-video (native-tool in provider configuration): run manage_job_state.py verify first, then use a callable local Agent video tool with the approved image and prompts.json; after the host call returns, register that exact video through scripts/execute_video_route.py --native-video <host-video>, which applies the common QC, result receipt, ledger, and Manifest path;
   • external-video: execute one selected AI SDK or command route with scripts/execute_video_route.py; never execute all attempts automatically and never delete/edit attempt-ledger.json to replay an attempt. A failed/rejected/uncertain attempt needs either explicit selection of the next numbered route or a user-requested, hash-bound retry approval passed with --retry-approval; the latter is a new billable execution. Only a submitted/uncertain xAI attempt with a persisted request ID may use --resume, which continues that same remote request. When Grok is required, set provider: grok-build-local and allow_fallback: false; a failed green-screen QC is a failed Grok job, not permission to use local animation;
   • keypose-local: when image generation is callable but video is not, compile scripts/compile_keypose_plan.py with the approved image/layout/state, validate generated 2×2 pose sheets with scripts/prepare_keyposes.py --plan <keypose-plan>, then assemble the exact four contract poses per sticker with scripts/render_keypose_pack.py --image <approved-sheet> --state <job-state> --plan <keypose-plan> --preparation-report <keypose-preparation>. Read references/keypose-workflow.md for the auditable flow;
   • light-motion-local: run manage_job_state.py verify, then use scripts/light_motion_fallback.py --state <job-state> only as the zero-generation-cost affine fallback. Describe it as light motion, never as synthesized character articulation. Accept transform-local only as a deprecated configuration alias;
   • postprocess-only: process a supplied video without generation. If no layout is supplied, extract a representative frame first with ffmpeg -y -i input.mp4 -frames:v 1 representative-frame.png, then inspect it.
   • prompt-only: when no video or local image-processing capability exists, run scripts/assemble_prompt_only.py, deliver its prompt artifacts, and stop without claiming a generated video.
8. Split and matte a grid video with scripts/process_emoji_grid.py --layout <layout.json> --settings <work_dir>/sticker-production.json. Probe the actual returned duration, select the matching configured profile, and run native-frame matting, instance assignment, and safety QC before duration sampling. Whole-grid registration is disabled by default because per-frame integer correction can create micro-jitter; use --registration auto only when visual inspection confirms actual camera drift. Request duration comes from generation.provider_duration_seconds; the shipped map is grok-build-local: 6 and xai-direct: 3, with both outputs at 240×240 and 8 fps. A direct API result matching 3 seconds is preserved as-is and is never duration-compressed. For Grok, preserve the complete 6-second result as the root version and also create 3s/ from the initial 24 sampled frames. Record endpoint pose difference for audit, but do not reject or retime the 3-second derivative when the first and last poses differ. Never replace or discard the full Grok result. First run --trial for the configured cell (default 01) and require both Grok variants to pass encoded-frame and 1 MiB GIF-budget checks. If they pass, reuse the same source grid video for the complete pack—never make a second Grok call. Later full-pack GIF overages are warnings rather than pack blockers; encoded-frame failures remain hard failures. Grok grid inputs are repacked from each cell's real Alpha bounding box with at least a 10% two-sided green corridor. Animated WebP stays lossless; GIF gets an adaptive binary-alpha threshold; both are decoded again for hard frame QC before packaging. A seam crossing is not itself a failure. Treat a balanced, inseparable cross-cell component as a bad native-frame run; only a short bounded run (up to 0.2 seconds) may be repaired from temporally adjacent safe frames, with frame numbers recorded in processing.json. Longer or identity-ambiguous merges remain withheld. Only an inseparable merge is withheld, while successful cells and the failure report remain deliverable.
9. Read references/output-contract.md before delivery. Run scripts/assemble_delivery.py --cleanup-media-dir so media and job-state.json, prompts.json, and route.json are collected into one canonical delivery directory and ZIP, then the intermediate media directory is removed only after packaging succeeds. Composite each GIF onto a light background before showing it. Report any low-confidence layout, alpha damage, interior holes, loop discontinuity, residual hold jitter, provider fallback, or failed cell instead of hiding it.

When processing generated video, pass --manifest <work_dir>/artifact-manifest.json to process_emoji_grid.py so accepted processed outputs extend the job's SHA-256 lineage.

Grid layout safety is a hard default: target each cell's combined foreground bounding box at approximately 70%–75% of the cell, never above 75% in the static prompt contract or video repack, and keep at least a 10% two-sided corridor. The static sheet prompt records this contract; Grok/keypose/local input preparation enforces the 75% maximum even when a source cell is fuller.

For public style evidence, keep gallery/styles/<id>/provenance.json in sync with the media by running scripts/build_gallery_provenance.py --verify-only. Legacy gallery cases are allowed only with an explicit legacy-evidence-partial status and a declared approval/manifest gap.

Routing behavior

Use this fixed order unless the user explicitly selects a provider:

1. callable native/local image-to-video capability;
2. configured external providers that satisfy the task, in configured priority order;
3. key-pose generation plus local assembly;
4. transform-only local animation when key-pose generation is unavailable;
5. prompt-and-plan-only output when neither video nor local image processing is possible. Deliver the prompts and route artifacts and stop without claiming a generated video.

Before the first external-provider call, state which provider will receive the image and that the request may incur charges, unless the user already explicitly selected that provider and authorized external generation. Run only attempt 1; a later route attempt requires a failed prior result and another explicit execution step. If the user actively asks to retry after a failed, rejected, or uncertain attempt, pause for a retry approval card naming the provider, explaining that a new request may incur another charge, and asking for an explicit confirmation. After confirmation, create a hash-bound retry approval with scripts/manage_job_state.py approve-video-retry, then pass it as --retry-approval to the executor. A plain request to continue, silence, or an earlier static approval is not retry authorization.

Retry only another configured route or the affected sticker. Do not repeatedly charge the same external provider without a clear transient failure and a bounded attempt count.

For a Grok-mandated task, the route must be explicit (provider: grok-build-local, allow_fallback: false, max_retries: 0). One approved sheet produces one Grok video; no local route and no automatic paid regeneration is eligible as a substitute. Read generation duration from generation.provider_duration_seconds for the executing provider and resolution from the job's sticker-production.json snapshot (shipped defaults: Grok 6 seconds, xAI 3 seconds, 720p). Preserve the complete returned Grok duration, add the configured 3-second derivative, and apply only the configured uniform 8 fps sampling after native-frame QC. A direct 3-second API result remains a single full-duration output.

Included commands

python3 scripts/character_workspace.py --name '小黑猫'
python3 scripts/compile_static_prompt.py --style 3d --expressions '🎸😍🥹😘🥰' --layout 3x3 --reference-image source.png --output works/小黑猫/static-prompt.json
python3 scripts/compile_static_prompt.py --style 3d --expressions '开心、喜欢、委屈、惊讶、亲亲、谢谢、加油、困困、点赞' --layout 3x3 --character-description '金发、深色西装、红领带的公众人物漫画形象' --output works/角色/static-prompt.json
python3 scripts/prepare_image_gen_call.py --static-prompt works/小黑猫/static-prompt.json --supported-argument prompt --supported-argument referenced_image_paths --output works/小黑猫/static-generation.json
python3 scripts/normalize_static_sheet.py works/小黑猫/static-sheet-source.png works/小黑猫/static-sheet.png --report works/小黑猫/static-alpha.json
python3 scripts/inspect_sticker_sheet.py works/小黑猫/static-sheet.png --output works/小黑猫/layout.json --overlay works/小黑猫/layout-overlay.png
python3 scripts/manage_job_state.py create --image works/小黑猫/static-sheet.png --layout works/小黑猫/layout.json --static-prompt works/小黑猫/static-prompt.json --output works/小黑猫/job-state.json
python3 scripts/manage_job_state.py approve --state works/小黑猫/job-state.json --image works/小黑猫/static-sheet.png --layout works/小黑猫/layout.json --confirmed-by-user
python3 scripts/prompt_compiler.py --layout works/小黑猫/layout.json --tile-plan works/小黑猫/tile-plan.json --static-prompt works/小黑猫/static-prompt.json --output works/小黑猫/prompts.json
python3 scripts/prepare_workflow.py --character '小黑猫' --image "$PWD/works/小黑猫/static-sheet.png" --layout "$PWD/works/小黑猫/layout.json" --prompts "$PWD/works/小黑猫/prompts.json" --state "$PWD/works/小黑猫/job-state.json" --tile-plan "$PWD/works/小黑猫/tile-plan.json"
python3 scripts/probe_video_capabilities.py --config works/小黑猫/video-providers.json --tool-manifest works/小黑猫/runtime-tools.json --output works/小黑猫/capabilities.json
python3 scripts/route_video_provider.py --config works/小黑猫/video-providers.json --capabilities works/小黑猫/capabilities.json --task works/小黑猫/video-task.json --output works/小黑猫/route.json
python3 scripts/execute_video_route.py --config works/小黑猫/video-providers.json --task works/小黑猫/video-task.json --route works/小黑猫/route.json --attempt 1 --output works/小黑猫/video-result.json
python3 scripts/process_emoji_grid.py animation.mp4 works/小黑猫/trial --layout works/小黑猫/layout.json --settings works/小黑猫/sticker-production.json --trial
python3 scripts/process_emoji_grid.py animation.mp4 works/小黑猫/output --layout works/小黑猫/layout.json --settings works/小黑猫/sticker-production.json --trial-report works/小黑猫/trial/processing.json
python3 scripts/render_keypose_pack.py keyposes works/小黑猫/output --image works/小黑猫/static-sheet.png --state works/小黑猫/job-state.json --layout works/小黑猫/layout.json --plan works/小黑猫/keypose-plan/keypose-plan.json --preparation-report works/小黑猫/keyposes/keypose-preparation.json --fps 8 --size 240 --manifest works/小黑猫/artifact-manifest.json
python3 scripts/light_motion_fallback.py works/小黑猫/static-sheet.png works/小黑猫/output --state works/小黑猫/job-state.json --layout works/小黑猫/layout.json --fps 8 --size 240 --manifest works/小黑猫/artifact-manifest.json
python3 scripts/process_independent_stickers.py stickers works/小黑猫/output --fps 8 --size 240 --manifest works/小黑猫/artifact-manifest.json
python3 scripts/assemble_prompt_only.py --static-prompt works/小黑猫/static-prompt.json --tile-plan works/小黑猫/tile-plan.json --prompts works/小黑猫/prompts.json --route works/小黑猫/route.json --output works/小黑猫/prompt-only
python3 scripts/assemble_delivery.py --media-dir works/小黑猫/output --audit-dir works/小黑猫 --output works/小黑猫/delivered --require-job-state --require-prompts --require-route --cleanup-media-dir

Use paths relative to this skill directory when invoked from elsewhere. On Windows, run the same scripts with py -3 (or python) if python3 is not on PATH; prepare_workflow.py rewrites example python3 adapter commands to the current interpreter.

Motion Sticker Pack｜动态表情包制作器

English · MIT · Release notes

把一张角色图或一段角色描述，变成经过静图确认、可审计、可打包的循环动态表情包。

motion-sticker-pack 是面向 Codex 的 Agent Skill。默认交付透明 PNG、lossless Animated WebP、兼容 GIF、处理报告和 ZIP；普通用户不需要手动运行脚本。

30 秒开始

在 Codex 中安装 Skill 后上传角色图，发送：

$motion-sticker-pack
用附件角色做 3×3 动态表情包。
风格选 soft-plush，表情是：开心、喜欢、委屈、惊讶、亲亲、谢谢、加油、困困、点赞。
先给我确认静图，再生成动画。每格独立、小幅、可循环。

没有角色图也可以直接描述角色；流程会直接生成完整静图板，不先制造一张中间角色图。

交互顺序：

1. 提供图片或角色描述。
2. 选择风格和表情。
3. 检查静态网格。
4. 明确回复“确认，继续”。
5. 选择可用的视频路线。
6. 下载 WebP/GIF/PNG 与 ZIP。

三档动态路线

transform-local 和 keyframe-local 仍作为旧配置兼容别名，但新 route 统一输出 light-motion-local。

没有视频或本地图像能力时，prompt-only 只交付提示词和审计文件，不会伪造媒体。

16 个风格效果图

下面是同一只狐狸、同一套服装与配饰的 16 张静态风格探索图，适合直接横向比较视觉方向。它们是风格效果参考，不等同于动态路线证据；真实九格处理、GIF、Animated WebP、layout、route、processing 和 provenance 证据见 gallery/。

最近生成的动态表情包 GIF

下面是最近完成的“暖尾狐狸”九宫格案例：9 个独立表情均为原始 240×240、8 fps、3 秒可循环 GIF，已通过透明度、边界和编码检查。完整来源与 SHA-256 记录见 manifest.json；13 个风格的长期验证证据仍见 gallery/。

查看或验证选择器：

python3 scripts/style_selector.py --format markdown
python3 scripts/style_selector.py --format core
python3 scripts/style_selector.py --style clay-cute
python3 scripts/style_selector.py --style soft-plush
python3 scripts/style_selector.py --verify-only

其中 cute 是兼容保留的规范 ID，soft-plush 是推荐的可读别名；两者解析到同一份真实验证证据。

v0.3.1 的核心目录目标为 16 个方向；--format core 会同时显示已验证和待受控验证的状态，普通 --format markdown 只显示已通过证据门槛的风格。待受控验证的核心风格可以在用户明确指定时编译，但会在合同中标记为未验证。核心目录之外的文化媒介、印刷、复古 UI 或混合风格，请使用 custom 描述，不会被硬编码成未经验证的 preset。

$motion-sticker-pack
风格 custom：水墨留白、干湿笔触，保留角色身份；不要添加整格背景。

完整证据见 gallery/，完整 gallery 媒体按版本发布到 GitHub Releases。旧版完整案例包已迁移至 GitHub Release asset。

静图与透明度

首选 GPT-image-2 等能返回真实 Alpha 的图像工具。静图请求按输入模式选择：参考图路线先生成不透明纯绿 #00FF00 源图，文字定义路线先尝试透明 RGBA PNG；两者都必须经过本地像素检查，失败时才进行一次有界重试。

• 棋盘格是可见背景，不是透明度。
• 不假设模型真的返回了请求的 3×3；必须重新检测实际布局。
• 低于 0.75 的布局置信度需要人工确认。
• 静图确认后，图片或 layout 的任一字节变化都会使审批哈希失效。

自动幕布

Grok 路线保持严格 #00FF00 合同。

非 Grok 路线会从绿、蓝、品红、青四个候选中计算前景冲突，选择距离主体颜色最远的幕布。候选分数、每个 Provider 的颜色和确定性铺底输入都记录在 video-task.json 与 artifact-manifest.json。用户仍可显式传入 --key-color。

统一输出

所有新本地路线默认：

• 240×240；
• 8fps；
• lossless Animated WebP 为首选；
• GIF 为兼容格式；
• PNG 为干净首帧；
• 编号按实际检测布局的 row-major 顺序；
• 同一个 delivered/ 目录与一个 sticker-pack.zip。

works/<character-slug>/delivered/
├── 01.webp … NN.webp
├── 01.gif  … NN.gif
├── 01.png  … NN.png
├── preview.png
├── layout.json
├── processing.json
├── job-state.json
├── prompts.json
├── route.json
├── attempt-ledger.json
├── artifact-manifest.json
└── sticker-pack.zip

完整规范见 output contract。

安全与审计

• 静图审批由 SHA-256 绑定。
• 付费 attempt 首次只提交一次；用户主动要求再次生成时，必须先创建绑定当前输入和 route 的重试批准，不会静默重放。
• xAI request id 支持恢复同一个远端任务。
• 输出目录采用可恢复事务，拒绝输入/输出重叠。
• artifact-manifest.json 记录静图、提示词、pose、route、视频和交付的依赖谱系。
• 每个原生视频帧都经过幕布、Alpha、跨格实例与编码后 QC。

更多说明：Routing and audit。

安装

在 Codex 对话中安装（推荐）

在 Codex 中发送以下消息：

$skill-installer
请从 GitHub 仓库 `kobingogo/motion-sticker-pack` 安装 `motion-sticker-pack` Skill。
Skill 位于仓库根目录（路径 `.`），安装名设为 `motion-sticker-pack`。

安装器完成后，在下一轮 Codex 消息中发送 $motion-sticker-pack 验证；例如：

$motion-sticker-pack
确认已加载该 Skill，并告诉我可用的入口和当前版本。

如果发送 $skill-installer 后提示未找到该 Skill，可发送下面的兜底请求（需要当前 Codex 会话具备终端权限）：

请不要调用 `$skill-installer`。请直接从
https://github.com/kobingogo/motion-sticker-pack.git 获取仓库，并将包含 `SKILL.md` 的仓库根目录安装到
`$CODEX_HOME/skills/motion-sticker-pack`；如果未设置 `$CODEX_HOME`，使用 `~/.codex/skills/motion-sticker-pack`。
安装完成后报告实际路径，并在下一轮消息中加载该 Skill。

本地脚本环境（可选）

如果只在 Codex 对话中调用，使用上面的安装流程即可。需要本地运行脚本或参与开发时，再执行：

git clone https://github.com/kobingogo/motion-sticker-pack.git
cd motion-sticker-pack
python3 -m pip install -r requirements.txt
npm ci --ignore-scripts

Skill 的执行合同见 SKILL.md。

高级文档

• Provider、凭据与 ZDR
• 路由、ledger 与 artifact manifest
• 完整 CLI 参考
• 仓库媒体策略、Release gate 与历史瘦身评估
• 风格库策略与 v0.4 候选
• 提示词合同
• 关键姿势工作流
• 对抗性审计

开发验证

python3 -m unittest discover -s tests -v
npm test
python3 scripts/style_selector.py --verify-only
python3 scripts/check_repository_policy.py

CI 在 Python 3.10/3.12 和 Node 22 上运行。正式版本只能通过 release workflow 从通过完整验证的 main 创建 tag 和 Release。

License

MIT。角色肖像、商标和生成媒体的使用权由使用者自行确认。