wufei-png/animated-sticker-maker

Animated Sticker Maker

Transforme uma imagem de referência e um prompt de movimento em um adesivo animado transparente curto. Derive internamente o travamento de identidade, o plano de movimento, a temporização dos quadros, o plano de validação e as configurações de exportação; não force o usuário a preencher escolhas rotineiras de produção.

Resolva todos os scripts e caminhos de referência em relação ao diretório que contém este SKILL.md.

Entradas e limites

Exija apenas:

1. reference_image: uma imagem estática contendo um sujeito principal claro.
2. prompt: linguagem natural descrevendo a expressão, ação, texto, loop ou plataforma de destino pretendidos.

Suporte pessoas, animais de estimação, mascotes, ilustrações, objetos e logotipos. Se a imagem tiver vários sujeitos plausíveis e o prompt não identificar um, pergunte uma vez antes de gerar. Não prometa atuação multi-sujeito estável, animação de cena ou movimento de câmera.

Produza um adesivo por invocação. Para uma série de vários adesivos, mantenha as especificações de identidade compartilhada, a ordem do pacote, a nomenclatura de lançamento e os ativos da marca no projeto proprietário e, em seguida, invoque este Skill separadamente para cada adesivo. Não transforme a orquestração de pacotes específica do projeto em um recurso genérico do Skill.

Este é um pacote Agent Skills para hosts que suportam o padrão; não mantenha um segundo formato de instrução específico do host. O host deve fornecer uma capacidade de geração ou edição raster condicionada a referência que possa preservar a identidade do sujeito. Use a capacidade nativa do host e falhe antes da geração com uma mensagem de capacidade clara quando nenhuma estiver disponível. agents/openai.yaml é metadados opcionais de interface e invocação da OpenAI, não parte do contrato do fluxo de trabalho.

Use Python 3.10 ou mais recente, além dos pacotes em requirements.txt para processamento determinístico. Não torne o OpenCV uma dependência obrigatória.

Saída padrão

Crie esta estrutura, a menos que o prompt a substitua explicitamente:

output/<name>/
├── sticker.webp
├── source/
│   ├── frames/
│   │   ├── 000.png
│   │   └── ...
│   ├── rendered-frames/      # faixa de quadro renderizado validada opcional
│   ├── reference.json        # basename, hash e metadados da imagem
│   └── motion.json
├── validation/
│   ├── contact-sheet.png
│   └── report.json
└── exports/                  # apenas quando uma plataforma ou formato extra é solicitado
    └── <platform>/

Use um output/<name>/ local ao workspace, a menos que o usuário nomeie outro destino local. Derive <name> como um slug curto e seguro para sistemas de arquivos a partir do sujeito e da batida semântica principal. Se já existir, use -2, -3 e assim por diante; não sobrescreva um pacote existente por padrão. Honre um nome de lançamento ou público explícito quando o usuário fornecer um.

Use 1024×1024 RGBA para fontes raster de tom contínuo, ilustradas ou geradas. Para pixel art nativo ou outra grade de baixa resolução estrita, preserve a tela lógica de origem e defina motion.resampling como nearest; não force através de um redesenho não inteiro de 1024×1024. Use 4-8 quadros únicos, durações por quadro, uma duração total de cerca de 1,2-2,0 segundos e uma pausa de 400-700 ms no quadro semântico mais claro. Loop por padrão. Não crie preview.gif a menos que seja solicitado ou exigido pela plataforma de destino.

Fluxo de trabalho

1. Normalize a solicitação

• Confirme que uma imagem de referência e um prompt de movimento estão disponíveis. Extraia o sujeito principal, uma batida semântica, o texto exato, a intenção de loop e qualquer plataforma de destino nomeada.
• Se o sujeito for ambíguo, pergunte uma vez. Se a imagem de referência, o prompt ou a capacidade necessária do host estiver faltando, pare com um bloqueador claro antes de gerar.
• Se nenhuma plataforma for nomeada, produza o pacote neutro de plataforma. Uma plataforma nomeada é um ramo de exportação opcional após o pacote passar na validação.
• Selecione o slug de saída antes de criar arquivos, usando a regra de colisão acima.

2. Trave a identidade e planeje o movimento

Leia references/motion-plan.md. Inspecione a referência em tamanho real e tamanho de ícone pequeno, classifique os recursos reconhecíveis como fixos, flexíveis ou removíveis e escreva motion.json antes de produzir os quadros finais.

Comprometa-se com uma batida semântica primária, um pequeno conjunto de poses âncora, transições determinísticas, camadas de texto exatas, durações de quadro e comportamento de loop. Gere apenas o que não pode ser obtido com segurança por meio de transformações determinísticas. Escolha motion.resampling deliberadamente: lanczos para trabalho raster de tom contínuo ou ilustrado, e nearest para pixel art nativo ou outra grade lógica estrita.

Conclua este estágio somente quando o travamento de identidade for explícito e cada elemento semântico solicitado tiver um quadro planejado ou camada determinística.

3. Produza âncoras e ativos RGBA limpos

Leia as instruções de geração ou edição raster do host antes de gerar. Sempre inclua a referência original ao solicitar uma nova âncora, peça um sujeito isolado em transparência ou uma cor de trabalho plana de alta distância e gere o menor número de âncoras necessário.

Inspecione cada âncora imediatamente contra o travamento de identidade. Rejeite o desvio de identidade antes de construir os quadros temporais. Se uma âncora completa rejeitada contiver uma expressão local utilizável ou adereço, recupere-a apenas em uma base aprovada e estável de identidade; registre a origem do componente, a regra de extração e a base aprovada no plano de movimento. Nunca renomeie uma imagem completa rejeitada como aprovada.

Preserve o alfa limpo existente. Caso contrário, leia references/transparency.md, escolha uma cor de trabalho distante da paleta do sujeito e execute scripts/chroma_key.py. Mantenha as sombras separadas quando o prompt ou a plataforma precisar de controle de sombra independente.

Conclua este estágio somente quando cada âncora de quadro completo for utilizável, cada componente recuperado tiver uma função determinística limitada e cada ativo não tiver fundo opaco, derramamento de cor, franja brilhante, protrusão cortada ou contato com a borda da tela.

4. Componha a animação criada

Crie um PNG RGBA por quadro criado único. Preserve a proporção, a menos que o movimento solicitado exija deformação. Renderize o texto exato em camadas determinísticas e dê a cada quadro um propósito. Favoreça antecipação, ação, uma pausa semântica clara e uma recuperação curta em vez de movimento com tempo uniforme.

Quando um objeto companheiro pressiona, senta, carrega ou toca o sujeito, alinhe-o contra a silhueta local abaixo de sua pegada. Não use a borda da caixa delimitadora global do sujeito como o plano de contato quando a superfície for curva, entalhada ou deformada.

Conclua este estágio somente quando a sequência for lida sem nomes de arquivo ou explicação e o loop não tiver salto, flash ou redefinição de posição não intencionais.

5. Empacote e execute a validação técnica

Execute:

python <skill-dir>/scripts/package_sticker.py \
  --frames-dir <working-frames> \
  --motion <motion.json> \
  --reference-image <reference-image> \
  --output <output/name>

Passe --expected-size <LARGURAxALTURA> quando a tela de origem diferir de 1024x1024. Use --include-reference apenas quando o usuário quiser o original embutido; caso contrário, vincule seu basename, hash, dimensões, modo, formato e tamanho de bytes sem copiá-lo. Use sinalizadores de temporização ou contagem de quadros não padrão apenas quando o prompt substituir explicitamente os padrões. Não continue para exportação de plataforma quando a validação técnica falhar.

Leia references/validation.md para o contrato de relatório e verificações determinísticas. Mantenha o pacote transacional, trate o source/motion.json empacotado como a fonte de verdade independente, preserve as impressões digitais do artefato e mantenha technical_validation separado de visual_validation.

Se motion.render estiver presente, trate seus quadros ordenados explícitos como uma trilha de renderização validada separada e opcional. Mantenha os quadros-chave criados como padrão; nunca crie ou selecione a trilha de renderização silenciosamente. Leia as referências de movimento e plataforma para suas regras de temporização, recurso e exportação.

Conclua este estágio somente quando o WebP, as fontes normalizadas, os metadados de referência, o plano de movimento, a folha de contato, o relatório técnico primário e todos os relatórios de trilha de renderização aplicáveis existirem e todas as verificações técnicas aplicáveis passarem.

Cada novo empacotamento bem-sucedido cria um novo relatório com validação visual pendente. Execute novamente a validação visual após cada novo empacotamento; nunca preserve uma aprovação visual anterior em artefatos alterados.

6. Inspecione, registre e exporte opcionalmente

Leia references/validation.md e references/review-page.md. Gere uma nova Página de Revisão imediatamente antes da inspeção ou compartilhamento:

python <skill-dir>/scripts/generate_review.py <validation-report.json> \
  --reference-image <original-reference-image> \
  --language <en|zh>

Omita --reference-image quando o pacote contiver sua referência vinculada. Escolha zh para uma conversa em chinês e en caso contrário. Inspecione o destino de revisão codificado real, marcador de pausa semântica, Alfa nos fundos checker/claro/escuro, visualizações em tamanho real e ampliadas 50×50 e a folha de exposição do quadro. Os quadros criados ou renderizados são evidências de comparação; o WebP/GIF decodificado controla o pacote ou a página de exportação.

Registre o resultado com scripts/record_visual_validation.py. O relatório deve reter sua impressão digital exata do artefato, e deliverable_ready é verdadeiro somente quando a validação técnica e visual passam. Se o status final deve aparecer em uma Página de Revisão compartilhada, regenere a página após registrá-lo. Uma Página de Revisão é HTML derivado descartável, não evidência ou entregável.

Se uma plataforma for solicitada, leia references/platform-exports.md, verifique as restrições oficiais atuais e exporte apenas abaixo de exports/<platform>/ a partir do pacote validado. Use quadros-chave criados por padrão; selecione uma trilha de renderização declarada explicitamente apenas quando ela melhorar materialmente a saída solicitada. Cada exportação solicitada precisa de sua própria validação técnica e visual.

Antes da entrega, execute scripts/doctor.py nos relatórios exatos do pacote, trilha de renderização e exportação que serão entregues. Doctor é somente leitura; incomplete é esperado enquanto uma validação visual aplicável estiver pendente. Leia references/doctor.md para seleção de destino e saída JSON.

Regras de decisão e recuperação

• Decida detalhes rotineiros de temporização, posição, escala, limite de cor de trabalho, compressão e slug de saída sem interromper o usuário.
• Uma falha técnica ou visual causada por um problema seguro e reversível pode receber uma passagem de correção automática focada usando apenas esses ajustes seguros. Reempacote, regenere a Página de Revisão e reinspecione; cada reempacotamento redefine a validação visual.
• Se a correção ainda falhar, ou uma correção alterar a identidade, o significado, a geração de âncora ou uma saída pública explícita, pare e pergunte ao usuário. Nunca substitua uma barreira técnica falha por julgamento visual.
• Se o usuário participar, compartilhe a nova Página de Revisão e colete feedback na conversa. O usuário não precisa executar Python ou enviar um formulário.

Entrega final

Use o idioma da conversa atual e sempre reporte estes campos:

• status: ready, incomplete ou blocked;
• caminho do pacote e caminho do Relatório de Validação primário;
• caminho do relatório da trilha de renderização, quando existir;
• caminho da Página de Revisão, quando uma foi gerada;
• cada exportação solicitada e seu caminho de relatório;
• resultado do Doctor para cada relatório entregue exato;
• ressalvas não resolvidas, verificações visuais pendentes, requisitos de referência externa ou limitações específicas da plataforma.

Nunca chame um artefato de pronto a menos que seu relatório exato tenha technical_validation, visual_validation e deliverable_ready: true, e o Doctor relate healthy para o limite entregue. Não apresente HTML de Revisão como um artefato de pacote, evidência de validação ou entregável.

Regra de escalonamento

Pergunte ao usuário apenas quando uma escolha ausente alterar o sujeito pretendido, o significado solicitado ou a saída pública irreversível. Pergunte uma vez para um sujeito primário ambíguo; pare claramente quando uma entrada necessária ou capacidade do host estiver indisponível. Faça ajustes seguros no nível do projeto automaticamente dentro da regra de recuperação limitada acima.