explainloop은(는) 무엇을 하나요?
제공된 텍스트의 주장, 순서, 비교, 변화를 설명하는 독창적이고 읽기 쉬운 애니메이션을 만듭니다. 출처의 사실적 상태와 사용자가 선택한 섹션, 개수, 스타일, 크기, 대상 위치를 보존합니다. 시각적 참조는 디자인 어휘이며, 장면별로 복사할 템플릿이 아닙니다.
입력 및 선택
- 제공된 전체 텍스트를 읽습니다. URL의 경우 사용 가능한 브라우징 도구를 사용하고, 본문을 가져올 수 없으면 텍스트를 요청합니다. 로컬 Markdown/TXT의 경우 파일과 인접 캡션을 읽습니다.
scripts/outline.mjs --input /absolute/path/article.md [--section "Heading"]은 제목 범위, 문자 수, 확장된 내부 개요가 유용한지 보고합니다. 제목만으로 문서 내용을 추론하지 마십시오. - 사용자가 제목, 단락, 인용문 또는 범위를 지정하면 해당 구절만 GIF 주제로 선택하고, 주변 텍스트는 문맥 해석에만 사용합니다. 그렇지 않으면 애니메이션화할 가치가 있는 최대 세 개의 관계를 식별합니다. 관찰 가능한 사건, 전/후, 원인/결과, 비교 또는 수치 변화를 슬로건보다 선호합니다. 1~3개의 GIF를 생성하고, 약한 주제로 개수를 채우지 마십시오.
- 각 GIF에 대한 간결한 증거 맵을 구축합니다: 정확한 출처 구절 또는 단락 위치, 주장 상태(사실, 측정, 보고된 결과, 제안 또는 의견), 초점 개체, 시각적으로 변하는 것, 한 문장 결론. 단위와 한정어를 유지합니다. 정지 프레임으로는 명확하지 않은 변화를 가르칠 때만 GIF를 선택합니다. 데이터, 제품 UI, 인용문 또는 결과를 조작하지 마십시오. 하나의 주제에 대해 여러 가로세로비 버전이 있는 경우 이 맵을 유지해야 합니다.
- 마크업 제거 후 선택한 본문이 6000자를 초과하거나 또는 5개 이상의 최상위 섹션이 있는 경우, 가장 강력한 1~3개의 GIF를 선택하기 전에 확장된 내부 주제 개요를 만듭니다. 자동으로 계속 진행하며, 요청된 구절이나 중요한 주장이 출처를 읽은 후에도 모호한 경우에만 질문합니다. 특정 선택된 섹션은 자체적으로 측정됩니다.
주제 선택 또는 불확실성 처리 시 content-planning.md를 참조하십시오. 이 스킬은 전체 나레이션 비디오 스크립트나 음성 승인이 필요하지 않습니다.
시각적 결정
- 장면을 구성하기 전에 scene-recipes.md와 visual-quality.md를 읽으십시오. 지원되는 관계, 초점 개체, 읽기 순서, 유형 계층, 위젯 상태 및 모션 비트를 설정합니다. 먼저 완전한 결과 프레임을 디자인한 다음, 초기 모션이 이를 이끌도록 합니다. 새 장면의 경우, 두 가지 실질적으로 다른 썸네일 구성을 내부적으로 비교한 다음, 경쟁하는 세부 정보가 적은 것으로 출처를 설명하는 구성을 선택합니다. 주제별 시각적 패밀리를 선택할 때 design-directions.md를, 캔버스 처리를 선택할 때 backgrounds.md를 읽으십시오. 스타일 프리셋은 토큰을 제공하지만, 장면에는 여전히 고유한 레이아웃이 필요합니다. 모든 주제를 동일한
kit.page머리글/본문/바닥글 배열 안에 넣지 마십시오. - 사용자의 시각적 지침에서 시작합니다. 하나의 요청으로 여러 GIF 또는 가로세로비를 생성하는 경우, 장면을 작성하기 전에 하나의 배치 스타일을 선택합니다: styles.md의 단일 프리셋과 공유 배경, 팔레트, 글꼴 역할, 선/반경 처리 및 모션 특성. 해당 배치의 모든 장면은 동일한
meta.style과 공유 핵심styleOverrides를 사용하며, 각 주제를 설명하기 위해 구성과 의미 개체를 다양화합니다. 각 GIF마다 새 프리셋을 선택하지 마십시오. 사용자가 명시적으로 요청한 경우에만 혼합 스타일을 사용합니다. - 타이포그래피가 장면을 이끄는 경우, font-catalog.md를 읽으십시오. 설치된 두 글꼴 쌍을 구절과 비교하고 장면에서 선택된 역할을 기록합니다. 렌더링하기 전에 실제 해석된 CJK 얼굴과 글리프를 확인하고, 누락된 디스플레이 글꼴을 자동으로 대체하지 마십시오. 카탈로그에는 선택적으로 독립적으로 설치된 오픈 글꼴도 나열됩니다. 이 스킬은 글꼴을 다운로드하거나 번들로 제공하지 않습니다.
- components.md를 사용하여 구체적인 개체(사람, 메시지, 문서, 작업, 타임라인, 측정값 및 관계)를 구성합니다. 설명에 UI 세부 정보가 필요한 경우 더 풍부한 이메일, 캘린더 또는 메시지 위젯을 사용하고, 실제 제품의 인터페이스를 발명하지 마십시오. 친숙한 작은 아이콘을 위해 패키지된 Lucide 하위 집합을 사용합니다. 외부 아트웍을 추가하기 전에 sources-and-licenses.md를 참조하십시오.
- 기본적으로 원본 벡터 개체를 사용합니다. 제공된 이미지, 적절히 라이선스된 일러스트레이션 또는 생성된 비트맵 아트는 벡터 구성 요소로 구체적인 주제를 명확하게 설명할 수 없는 경우에만 사용합니다. 이미지는 선택한 스타일과 일관성을 유지하고 출처를 기록합니다. 특정 실제 주제에 대해 일반 아이콘을 자동으로 대체하지 마십시오.
- 모든 보이는 동작은 무엇이 변경되었는지, 개체가 어디로 갔는지, 또는 결과가 어떻게 따르는지에 답해야 합니다. 관련 부분이 하나의 단위로 움직일 때 하나의 모션 진행에서 관련 부분을 드러내고, 중요한 정보가 의도적인 순서로 정착하도록 하며, 종료 시에는 그 순서를 반대로 합니다. 초점 개체와 텍스트를 위한 명확한 영역을 확보한 후에만 backgrounds.md의 10가지 캔버스 처리 중 하나를 선택하고, 그 기하학을 문서의 관계와 일치시키며, 카탈로그의 거부 조건을 사용합니다. 문서 너비에서 텍스트를 읽을 수 있게 유지합니다. 출처 데이터 없이 차트 값을 표시하지 마십시오. 긴 정적 유지와 갑작스러운 첫/마지막 프레임 점프는 루프가 깨진 것처럼 느껴지게 하므로 피합니다. 유사한 결함을 검토할 때 failure-cases.md를 참조하십시오.
장면 소스 및 렌더링
기본 산출물은 1600×900, 16:9, 30fps, 4~7초 무음 GIF입니다. 사용자 기본 설정이 이 기본값을 덮어씁니다. 다른 내장 출력 프로필은 4:3(1200×900), 1:1(1200×1200), 9:16(900×1600)입니다. 사용자 정의 픽셀 크기도 허용합니다. 요청된 비율만 출력하고, 명시되지 않은 경우 16:9를 사용합니다. 파일 크기를 줄이기 위해 해상도나 fps를 자동으로 낮추지 마십시오.
meta와 draw(t, kit)를 내보내는 .scene.mjs 파일을 작성합니다. meta.width/height는 논리적 디자인 캔버스이며, --output-size는 래스터 픽셀을 설정합니다. draw는 경과 초를 받아 kit.page(...) 또는 kit.svg(...)에서 완전한 SVG를 반환합니다. 증거 맵을 meta.sourceRefs에 넣습니다. 소스는 결정론적이어야 합니다: 동일한 장면과 시간에 동일한 SVG. scene-format.md, assets/examples/message-filter.scene.mjs, assets/examples/multi-ratio/를 참조하십시오.
하나의 요청에 여러 비율이 있는 경우, 각 비율에 대해 별도의 편집 가능한 장면을 만들고 요청된 모든 버전을 렌더링합니다. 정사각형 또는 세로 공간에 맞게 레이아웃을 재구성하고, 최종 결과물로 가로 장면을 늘리거나, 자르거나, 레터박스 처리하지 마십시오. 좁은 프레임에 맞게 화면 복사본을 축소할 수 있지만, 동일한 증거, 숫자, 주장 상태 및 요점은 유지합니다. 모든 버전에서 애니메이션의 인과적 순서를 일관되게 유지합니다.
사용자가 다른 대상을 선택하지 않는 한, 단일 16:9 출력의 경우 현재 작업 디렉토리 아래 generate/images/에 <article-slug>-01.gif와 <article-slug>-01.scene.mjs(연속 주제 번호 사용)를 저장합니다. 다중 비율 요청의 경우 두 확장자 앞에 -16x9, -4x3, -1x1, 또는 -9x16을 추가하고, 사용자 정의 비율에는 -WIDTHxHEIGHT를 사용합니다. 작업 프레임은 임시 디렉토리에 보관합니다. 장면 소스는 편집 가능한 산출물입니다. 생성된 PNG 프레임을 그 옆에 두지 마십시오.
로드된 스킬 경로에서 이 스킬의 디렉토리를 SKILL_ROOT로 확인합니다.
두 개 이상의 장면 배치의 경우, 먼저 node "$SKILL_ROOT/scripts/check-batch.mjs" --scene /absolute/first.scene.mjs --scene /absolute/second.scene.mjs를 실행합니다(각 장면에 대해 --scene 반복). 렌더링 전에 프리셋 또는 공유 토큰 불일치를 수정합니다. 이는 장면 메타데이터를 확인합니다. 이미지 인식이 가능한 경우, 동일한 --scene 인수로 scripts/preview-batch.mjs를 실행하고 장면별 색상, 글꼴, 위젯 세부 정보 및 배경 처리를 위해 실제 결과 프레임을 비교합니다. 사용자가 명시적으로 혼합 스타일을 요청한 경우에만 배치 스타일 검사를 건너뜁니다.
각 요청된 GIF를 렌더링하고 검사합니다:
node "$SKILL_ROOT/scripts/render.mjs" --scene /absolute/path/to/name.scene.mjs --out /absolute/path/to/name.gif --output-size 1600x900
node "$SKILL_ROOT/scripts/inspect.mjs" /absolute/path/to/name.gif
render.mjs는 Node, rsvg-convert, ffmpeg, ffprobe가 필요합니다. 가용성을 확인하고 도구를 설치하지 않고 누락된 도구를 보고합니다. 요청된 출력 크기는 장면의 논리적 캔버스와 동일한 가로세로비를 가져야 하며, 각 픽셀 차원은 최대 4096입니다. 정지 미리보기가 유용한 경우 --poster /absolute/path/to/preview.png를 사용합니다.
품질 중심 생성을 위해 scene-recipes.md의 조건부 미리보기 및 수정 워크플로를 따릅니다. 이 에이전트가 실제로 이미지 픽셀을 볼 수 있는 경우, node "$SKILL_ROOT/scripts/preview.mjs" --scene /absolute/path/to/name.scene.mjs --temporal-strip [--display-width 720]을 실행하고 네 개의 키 프레임과 여덟 개의 샘플 프레임을 검사한 후, 최종 렌더링 전에 구체적인 시각적 결함을 수정합니다. 최대 2회의 시각적 수정 라운드를 수행합니다. 에이전트가 이미지 픽셀을 볼 수 없는 경우, 시각적 검토와 미리보기를 건너뛰고, 기술적 검사만을 위해 렌더링하고 inspect.mjs를 실행합니다. Playwright는 필요하지 않습니다. inspect.mjs는 치수, 프레임 수, 지속 시간, 전체 디코드, 반복 프레임 및 가장 긴 정확한 정적 실행을 확인하며, 시각적 완성도를 판단할 수 없습니다.
전달
각 GIF와 해당 장면 소스를 링크합니다. 설명된 출처 구절, 중요한 추론, 선택된 스타일, 실제 치수/fps/지속 시간/파일 크기를 명시합니다. 입력 섹션이 지정된 경우, 모든 장면이 해당 섹션에서 비롯되었는지 확인합니다. 렌더링된 출력 또는 시각적 검토가 실제로 완료되지 않은 경우 주장하지 마십시오. 시각적 검토가 불가능했던 경우 명시적으로 언급합니다.
이 스킬은 짧은 무음 GIF를 위한 것입니다. 단일 정적 아키텍처 이미지에는 정적 다이어그램 워크플로를, 나레이션 MP4에는 비디오 워크플로를 사용하십시오.