애니메이션 스티커 메이커

애니메이션 스티커 메이커은(는) 무엇을 하나요?

참조 이미지 한 장과 모션 프롬프트 하나를 입력받아 짧고 투명한 애니메이션 스티커 하나를 만듭니다. 신원 잠금, 모션 계획, 프레임 타이밍, 검증 계획 및 내보내기 설정은 내부적으로 결정합니다. 사용자가 일상적인 제작 선택을 하도록 하지 마십시오.

모든 스크립트 및 참조 경로는 이 SKILL.md가 포함된 디렉터리를 기준으로 확인하세요.

입력 및 경계

다음만 필요합니다:

1. reference_image: 명확한 주요 피사체가 포함된 정적 이미지 한 장.
2. prompt: 의도된 표정, 동작, 텍스트, 루프 또는 대상 플랫폼을 설명하는 자연어.

사람, 반려동물, 마스코트, 삽화, 사물, 로고를 지원합니다. 이미지에 여러 가능한 피사체가 있고 프롬프트가 하나를 식별하지 못한 경우, 생성을 진행하기 전에 한 번 질문하세요. 다중 피사체 연기, 장면 애니메이션 또는 카메라 움직임을 약속하지 마십시오.

호출당 스티커 하나를 생성하세요. 여러 스티커 시리즈의 경우 공유 신원 사양, 팩 순서, 릴리스 이름 지정 및 브랜드 자산을 소유 프로젝트에 유지하고 각 스티커에 대해 이 Skill을 개별적으로 호출하세요. 프로젝트별 팩 오케스트레이션을 일반 Skill 기능으로 전환하지 마십시오.

이는 표준을 지원하는 호스트를 위한 하나의 Agent Skills 패키지입니다. 두 번째 호스트별 명령 형식을 유지하지 마십시오. 호스트는 피사체의 신원을 보존할 수 있는 참조 조건부 래스터 생성 또는 편집 기능을 제공해야 합니다. 호스트 네이티브 기능을 사용하고, 사용 가능한 기능이 없으면 생성 전에 명확한 기능 메시지와 함께 실패 처리하십시오. agents/openai.yaml은 선택적인 OpenAI UI 및 호출 메타데이터이며, 워크플로 계약의 일부가 아닙니다.

결정론적 처리를 위해 Python 3.10 이상과 requirements.txt의 패키지를 사용하세요. OpenCV를 필수 종속성으로 만들지 마십시오.

기본 출력

프롬프트가 명시적으로 재정의하지 않는 한 다음 구조를 생성하세요:

output/<name>/
├── sticker.webp
├── source/
│   ├── frames/
│   │   ├── 000.png
│   │   └── ...
│   ├── rendered-frames/      # 선택적 검증된 고프레임 트랙
│   ├── reference.json        # 기본 파일명, 해시 및 이미지 메타데이터
│   └── motion.json
├── validation/
│   ├── contact-sheet.png
│   └── report.json
└── exports/                  # 플랫폼 또는 추가 형식이 요청된 경우에만
    └── <platform>/

사용자가 다른 로컬 대상을 지정하지 않는 한 작업공간 로컬 output/<name>/을 사용하세요. <name>은 피사체와 주요 의미 박자(semantic beat)로부터 짧고 파일 시스템에 안전한 슬러그(slug)로 도출하세요. 이미 존재하는 경우 -2, -3 등을 사용하십시오. 기본적으로 기존 패키지를 덮어쓰지 마십시오. 사용자가 명시적 릴리스 또는 공개 이름을 제공하는 경우 이를 존중하십시오.

연속 톤, 삽화 또는 생성된 래스터 소스의 경우 1024×1024 RGBA를 사용하세요. 네이티브 픽셀 아트 또는 다른 엄격한 저해상도 그리드의 경우 논리적 소스 캔버스를 보존하고 motion.resampling을 nearest로 설정하십시오. 정수가 아닌 1024×1024 리드로우를 강제하지 마십시오. 4–8개의 고유 프레임, 프레임별 지속 시간, 약 1.2–2.0초의 총 지속 시간, 가장 선명한 의미 프레임에서 400–700ms 홀드를 사용하세요. 기본적으로 루프합니다. 요청되거나 대상 플랫폼에서 필요하지 않는 한 preview.gif를 생성하지 마십시오.

워크플로

1. 요청 정규화

• 참조 이미지 한 장과 모션 프롬프트 하나가 사용 가능한지 확인합니다. 주요 피사체, 하나의 의미 박자, 정확한 텍스트, 루프 의도 및 명명된 대상 플랫폼을 추출합니다.
• 피사체가 모호한 경우 한 번 질문합니다. 참조 이미지, 프롬프트 또는 필요한 호스트 기능이 없는 경우 생성 전에 명확한 차단 메시지와 함께 중지합니다.
• 플랫폼이 명명되지 않은 경우 플랫폼 중립 패키지를 생성합니다. 명명된 플랫폼은 패키지가 검증을 통과한 후의 선택적 내보내기 분기입니다.
• 위의 충돌 규칙을 사용하여 파일을 생성하기 전에 출력 슬러그를 선택합니다.

2. 신원 잠금 및 모션 계획

references/motion-plan.md를 읽으세요. 참조를 전체 크기와 작은 아이콘 크기로 검사하고, 인식 가능한 특징을 고정, 유연 또는 제거 가능으로 분류하며, 최종 프레임을 생성하기 전에 motion.json을 작성합니다.

하나의 주요 의미 박자, 소수의 앵커 포즈, 결정론적 전환, 정확한 텍스트 레이어, 프레임 지속 시간 및 루프 동작에 전념합니다. 결정론적 변환을 통해 안전하게 얻을 수 없는 것만 생성합니다. motion.resampling을 의도적으로 선택하십시오: 연속 톤 또는 삽화용 래스터 작업에는 lanczos, 네이티브 픽셀 아트 또는 다른 엄격한 논리 그리드에는 nearest를 사용합니다.

신원 잠금이 명시적이고 요청된 각 의미 요소가 계획된 프레임 또는 결정론적 레이어를 가질 때만 이 단계를 완료합니다.

3. 앵커 생성 및 깨끗한 RGBA 자산

생성하기 전에 호스트의 래스터 생성 또는 편집 지침을 읽으세요. 새 앵커를 요청할 때는 항상 원본 참조를 포함시키고, 투명도 위에 격리된 피사체 또는 평평한 고거리 작업 색상을 요청하며, 필요한 최소 앵커만 생성합니다.

생성된 모든 앵커를 신원 잠금에 대해 즉시 검사합니다. 시간적 프레임을 구축하기 전에 신원 이탈을 거부합니다. 거부된 전체 앵커에 유용한 로컬 표정이나 소품이 포함된 경우, 승인된 신원 안정 베이스에만 이를 구제하고, 모션 계획에 구성 요소 소스, 추출 규칙 및 승인된 베이스를 기록합니다. 거부된 전체 이미지를 승인된 것으로 다시 레이블링하지 마십시오.

기존의 깨끗한 알파를 보존합니다. 그렇지 않으면 references/transparency.md를 읽고, 피사체 팔레트에서 먼 작업 색상을 선택한 후 scripts/chroma_key.py를 실행합니다. 프롬프트나 플랫폼에서 독립적인 그림자 제어가 필요한 경우 그림자를 분리하여 유지합니다.

모든 전체 프레임 앵커를 사용할 수 있고, 모든 구제된 구성 요소가 제한된 결정론적 역할을 가지며, 각 자산에 불투명한 배경, 색상 번짐, 밝은 프린지, 잘린 돌출부 또는 캔버스 가장자리 접촉이 없는 경우에만 이 단계를 완료합니다.

4. 저작된 애니메이션 구성

저작된 각 고유 프레임당 하나의 RGBA PNG를 만듭니다. 요청된 모션에 변형이 필요하지 않는 한 종횡비를 보존합니다. 결정론적 레이어에 정확한 텍스트를 렌더링하고 각 프레임에 하나의 목적을 부여합니다. 균일한 타이밍의 모션보다 예측 동작, 액션, 하나의 명확한 의미 홀드 및 짧은 회복을 선호합니다.

동반 객체가 피사체를 누르거나, 앉거나, 나르거나, 접촉하는 경우, 해당 객체의 발자국 아래 있는 로컬 실루엣에 맞춰 정렬합니다. 표면이 곡선이거나, 노치가 있거나, 변형된 경우 피사체의 전체 경계 상자 가장자리를 접촉면으로 사용하지 마십시오.

파일 이름이나 설명 없이 시퀀스가 읽히고 루프에 의도치 않은 점프, 플래시 또는 위치 재설정이 없는 경우에만 이 단계를 완료합니다.

5. 패키징 및 기술 검증 실행

다음을 실행하세요:

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

소스 캔버스가 1024x1024와 다른 경우 --expected-size <WIDTHxHEIGHT>를 전달하세요. 사용자가 원본을 포함하기를 원하는 경우에만 --include-reference를 사용하십시오. 그렇지 않으면 복사하지 않고 기본 파일명, 해시, 치수, 모드, 형식 및 바이트 크기를 바인딩합니다. 프롬프트가 명시적으로 기본값을 재정의하는 경우에만 비표준 타이밍 또는 프레임 카운트 플래그를 사용하십시오. 기술 검증이 실패하면 플랫폼 내보내기를 계속하지 마십시오.

보고서 계약 및 결정론적 검사를 위해 references/validation.md를 읽으십시오. 패키지를 트랜잭션 방식으로 유지하고, 패키지된 source/motion.json을 독립적인 진실 공급원으로 취급하며, 아티팩트 지문을 보존하고, technical_validation을 visual_validation과 분리하여 유지하십시오.

motion.render가 있는 경우, 명시적 순서가 있는 프레임을 선택적이고 별도로 검증된 렌더 트랙으로 처리하십시오. 저작된 키프레임을 기본값으로 유지하고, 렌더 트랙을 자동으로 생성하거나 선택하지 마십시오. 해당 타이밍, 리소스 및 내보내기 규칙에 대해 모션 및 플랫폼 참조를 읽으십시오.

WebP, 정규화된 소스, 참조 메타데이터, 모션 계획, 콘택트 시트, 기본 기술 보고서 및 모든 적용 가능한 렌더 트랙 보고서가 존재하고 모든 적용 가능한 기술 검사가 통과된 경우에만 이 단계를 완료합니다.

모든 성공적인 재패키징은 시각 검증이 보류된 상태로 새 보고서를 생성합니다. 재패키징 후에는 항상 시각 검증을 다시 실행하십시오. 변경된 아티팩트에 대해 이전 시각 통과를 절대 유지하지 마십시오.

6. 검사, 기록 및 선택적 내보내기

references/validation.md 및 references/review-page.md를 읽으십시오. 검사 또는 공유 직전에 새 리뷰 페이지를 생성하세요:

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

패키지에 바인딩된 참조가 포함된 경우 --reference-image를 생략하십시오. 중국어 대화의 경우 zh를 선택하고 그 외의 경우 en을 선택하십시오. 실제 인코딩된 리뷰 대상, 의미 홀드 마커, 체커/밝음/어두움 배경의 알파, 실제 크기 및 확대된 50×50 뷰, 프레임 노출 시트를 검사하십시오. 저작 또는 렌더 프레임은 비교 증거이며, 디코딩된 WebP/GIF가 패키지 또는 내보내기 페이지를 제어합니다.

scripts/record_visual_validation.py로 결과를 기록하십시오. 보고서는 정확한 아티팩트 지문을 유지해야 하며, deliverable_ready는 기술 및 시각 검증이 모두 통과된 경우에만 true입니다. 최종 상태가 공유 리뷰 페이지에 표시되어야 하는 경우, 기록 후 페이지를 다시 생성하십시오. 리뷰 페이지는 폐기 가능한 파생 HTML이며, 증거나 전달물이 아닙니다.

플랫폼이 요청된 경우, references/platform-exports.md를 읽고 현재 공식 제약 조건을 확인한 후 검증된 패키지에서 exports/<platform>/ 아래에만 내보내십시오. 기본적으로 저작된 키프레임을 사용하십시오. 요청된 출력을 실질적으로 개선하는 경우에만 선언된 렌더 트랙을 명시적으로 선택하십시오. 각 요청된 내보내기에는 자체 기술 및 시각 검증이 필요합니다.

전달 전에 전달될 정확한 패키지, 렌더 트랙 및 내보내기 보고서에 대해 scripts/doctor.py를 실행하십시오. Doctor는 읽기 전용입니다. 적용 가능한 시각 검증이 보류 중인 동안 incomplete가 예상됩니다. references/doctor.md에서 대상 선택 및 JSON 출력에 대한 내용을 읽으십시오.

결정 및 복구 규칙

• 일상적인 타이밍, 위치, 배율, 작업 색상 임계값, 압축 및 출력 슬러그 세부 사항은 사용자를 방해하지 않고 결정합니다.
• 안전하고 되돌릴 수 있는 문제로 인한 기술 또는 시각적 실패는 안전한 조정만을 사용하여 한 번의 집중된 자동 수정을 받을 수 있습니다. 재패키징하고, 리뷰 페이지를 다시 생성하고, 다시 검사하십시오. 모든 재패키징은 시각 검증을 재설정합니다.
• 수정이 여전히 실패하거나, 수정이 신원, 의미, 앵커 생성 또는 명시적 공개 출력을 변경하는 경우 중지하고 사용자에게 문의하십시오. 실패한 기술 게이트를 시각적 판단으로 재정의하지 마십시오.
• 사용자가 참여하는 경우 새 리뷰 페이지를 공유하고 대화에서 피드백을 수집하십시오. 사용자가 Python을 실행하거나 양식을 제출할 필요는 없습니다.

전달 핸드오프

현재 대화 언어를 사용하고 항상 다음 필드를 보고하세요:

• status: ready, incomplete 또는 blocked;
• 패키지 경로 및 기본 검증 보고서 경로;
• 렌더 트랙 보고서 경로(있는 경우);
• 생성된 리뷰 페이지 경로(있는 경우);
• 요청된 각 내보내기 및 해당 보고서 경로;
• 전달된 각 정확한 보고서에 대한 Doctor 결과;
• 해결되지 않은 주의 사항, 보류 중인 시각 검사, 외부 참조 요구 사항 또는 플랫폼 사양 제한 사항.

해당 보고서에 technical_validation, visual_validation 및 deliverable_ready: true가 있고 Doctor가 전달된 경계에 대해 healthy를 보고하지 않는 한 아티팩트를 준비 완료라고 부르지 마십시오. 리뷰 HTML을 패키지 아티팩트, 검증 증거 또는 전달물로 제시하지 마십시오.

에스컬레이션 규칙

누락된 선택이 의도된 피사체, 요청된 의미 또는 되돌릴 수 없는 공개 출력을 변경하는 경우에만 사용자에게 문의하십시오. 모호한 주요 피사체에 대해 한 번 질문하고, 필수 입력 또는 호스트 기능을 사용할 수 없는 경우 명확하게 중지하십시오. 위의 제한된 복구 규칙 내에서 안전한 프로젝트 수준 조정을 자동으로 수행하십시오.