demotion — 자동 시스템 데모 영상 제작

demotion — 실제 애플리케이션 UI로 만드는 자동 시스템 데모

최종 결과물: 하나의 .mp4 (1920×1080, 60fps, 1~2분)로서, 마치 전문 Screen Studio로 녹화한 듯한 실제 애플리케이션 데모 영상입니다. 하지만 Remotion 코드로 완전히 제어되므로 실제 녹화처럼 끊기지 않고, 반복 재현 가능하며, 기능이 변경되어도 쉽게 업데이트할 수 있습니다.

작업 언어: 한국어 (답변, 요약, 영상 캡션). Chrome을 열거나 로컬 애플리케이션에 로그인하여 UI를 "확인"하지 마십시오. UI의 진실 공급원은 코드이며, 결과는 Remotion 스틸/영상으로만 확인합니다.

절대 위반하지 말아야 할 원칙

1. 진짜 UI, 모조품이 아님. 애플리케이션 코드에서 마크업 + Tailwind 클래스 문자열 + 색상 토큰 + 폰트를 그대로 복사하십시오. UI 텍스트(제목, 레이블, 힌트, 메시지)도 정확히 복사합니다. "비슷하게" 다시 그리지 마십시오.
2. 제품 정보는 코드에서. 모든 캡션 주장(가격, 할당량, 기본값, 제한, 누가 무엇을 지불하는지)은 코드/설정 파일에서 읽어와야 하며, 기억이나 추측이 아니어야 합니다. 실제 예: "봇 테스트에 할당량 사용?" → API 경로와 사용량 추적 함수를 확인한 후 캡션을 작성합니다. 코드에 없는 내용은 주장하지 마십시오.
3. 모든 움직임은 영상 시간으로 계산. CSS 애니메이션/전환, setTimeout, 프레임 간 상태/캐시 없음: 각 프레임은 t에 대한 순수 함수여야 합니다. (병렬 렌더링은 프레임을 여러 탭에 분할합니다.)
4. 데모 데이터는 가상, 일관성, 안전. 하나의 가상 업체/인물, 플레이스홀더 번호/이메일/계좌, 모든 씬에서 동일한 숫자. 실제 고객 데이터를 사용하지 마십시오. "며칠 후" 통계는 "예시 데이터"라고 캡션을 답니다.
5. 1~2분 분량 (요청이 없으면): 대기 시간을 자르고, 타이핑/로딩 구간은 38배 속도로 가속하며 "4x" 배지를 표시합니다. 읽어야 할 부분은 12배 속도를 유지합니다. 캡션은 가속 후에도 최소 1.2초 이상 표시되어야 합니다.
6. 육안 검증: 주요 시점의 스틸을 렌더링하고 이미지를 읽어 확인합니다. 최종 렌더링 전에 반드시 수행합니다.

작업 흐름

0단계 — 탐지 및 목표 설정

• 기존 데모 찾기: **/src/demo/kit/stage.tsx. 있으면 → 새로 만들지 않고 "데모 업데이트" 모드로 전환합니다.
• 없으면 → 비디오 프로젝트가 필요합니다. 기본 위치: <repo>/video/ (별도 폴더; Next/ESLint를 사용하는 리포지토리라면 루트 tsconfig의 exclude와 ESLint의 globalIgnores에 추가하여 앱 빌드/CI가 검사하지 않도록 합니다).
• 추론 불가능한 내용만 한 번 질문: 목표 분량, 음성/내레이션 유무, 반드시 포함해야 할 부분. 기본값: 한국어 캡션, 음성 없음, 2분 이하, 처음부터 주요 기능까지의 사용자 여정.

1단계 — 제품 조사 (코드를 읽고, 추측하지 마십시오)

표시될 각 페이지/기능에 대해 다음을 읽습니다: 경로(app/**/page.tsx), 컴포넌트, UI 텍스트, 패키지/가격/할당량, 기본 규칙, 제한, 둘러보기/온보딩 텍스트 (이것이 최고의 제품 지식 소스입니다), 결제 흐름, 역할. 결과를 referensi/storyboard.md에 기록합니다. 형식: 페이지 → 보여줄 내용 → 캡션 → 검증된 주장 (파일:줄). 필요하다면 코드 읽기를 여러 서브 에이전트(Explore)에 분할하십시오. 최종 결정은 항상 사용자가 내립니다.

2단계 — 스토리보드

사용자 여정에 따라 8~14개의 씬을 구성합니다 (랜딩 → 가입 → 시작/온보딩 → 핵심 설정 → "와우" 모먼트 → 모니터링 → 결제/구독 → 행동 유도). 각 씬: 목표, 원래 시간, 커서 단계, 캡션. referensi/storyboard.md 참조 (캡션 패턴, 템포, 장 레이블 "N · 이름").

3단계 — 스캐폴드

node "$HOME/.claude/skills/demotion/skrip/scaffold.mjs" --dest <repo>/video --nama "제품명" --domain product.com --aksen "#3ddc97" --install

엔진(src/demo/kit/*), Root 프레임워크, 예제 씬, Tailwind v4 설정을 복사합니다. 그 후:

• 애플리케이션 CSS의 색상 토큰 + 컴포넌트 클래스를 src/demo/index.css로 복사합니다 (애니메이션/전환은 제거).
• src/demo/fonts.ts의 폰트를 애플리케이션에서 사용하는 폰트(@fontsource/<이름>)로 변경합니다. 사용된 모든 스타일을 로드합니다.
• config.ts에서 BRAND를 채웁니다 (이름, 도메인, 어두운 배경에서 악센트 색상).
• 테스트: REMOTION_FPS=30 npx remotion still src/demo/index.ts S-contoh out/uji.png --frame=270 --config=remotion.demo.config.ts. 실제 씬이 생기면 scenes/contoh.tsx를 삭제합니다.

4단계 — UI 포팅 및 씬 작성

• 제품 컴포넌트 → src/demo/pages/*.tsx (마크업/클래스 복사; 데이터 및 핸들러를 정적 props로 교체). 일반적인 아톰은 kit/atoms.tsx에, WhatsApp 휴대폰은 kit/phone.tsx에 있습니다.
• 하나의 씬 = DUR (원래 시간(초))과 컴포넌트를 내보내는 scenes/<id>.tsx 파일 하나; scenes/index.ts에 buat("<id>", Komp, DUR_X)로 등록합니다. 전체 패턴은 templat/src/scenes/contoh.tsx와 referensi/arsitektur.md (Stage API: 커서/스크롤/카메라/스포트라이트, data-cur, T 기준 이벤트 시간)를 참고하십시오.
• 사이드바/모달/둘러보기 = fixed 레이어 (스크롤되지 않음), 페이지 내용은 children입니다.
• 씬이 6개 이상이고 독립적이면 fork를 사용해 병렬화합니다 (referensi/brief-fork.md 참조). 공통 프레임워크(여러 씬에서 사용하는 데이터, 페이지)는 사용자가 먼저 작성합니다.

5단계 — 자르기 및 가속

모든 씬이 1배속에서 올바르게 동작하면 scenes/potong.ts를 채웁니다 (씬별로 S(a,b,v) 세그먼트). npx remotion compositions src/demo/index.ts --config=remotion.demo.config.ts로 전체 길이를 확인합니다 (Demo 지속 시간 열).

6단계 — 검증

1. npx tsc --noEmit -p tsconfig.json
2. 저렴한 미리보기: REMOTION_FPS=30 npx remotion render src/demo/index.ts Demo out/preview.mp4 --config=remotion.demo.config.ts --crf=26 --scale=0.5 --concurrency=10 --gl=angle
3. 연속 스틸: python "$HOME/.claude/skills/demotion/skrip/lembar-kontak.py" out/preview.mp4 --tiap 5 후 이미지를 읽습니다.
4. 확인할 사항: 텍스트 잘림, 캡션이 클릭할 버튼을 가림, 커서 위치 오류, 숫자 불일치, 잘못된 주장, 레이아웃 점프, 빈 시간/너무 긴 구간.

7단계 — 최종 렌더링 및 전송

powershell -File "$HOME/.claude/skills/demotion/skrip/bersihkan-proses.ps1"   # 기존 렌더링이 있으면 필수 (사용자가 Studio를 사용 중이면 -JanganStudio 추가)

cd <repo>/video && REMOTION_FPS=60 npx remotion render src/demo/index.ts Demo out/demo.mp4 --config=remotion.demo.config.ts --codec=h264 --crf=17 --concurrency=10 --gl=angle

백그라운드에서 실행(run_in_background), 작은 timeout 없이. 예상 시간: 약 12~18프레임/초 (GPU), 2분 60fps = 7,000프레임 ≈ 8분. 완료 후 ffprobe로 확인 (지속 시간, 1920×1080, 60fps) + 한 프레임 확인, 그런 다음 node ".../skrip/kompres.mjs" out/demo.mp4 out/demo-ringan.mp4 --crf 24 명령으로 30MB를 초과하면 압축하고 SendUserFile로 전송합니다 (30MB 제한; 전체 파일은 디스크에 유지하고 사용자에게 알립니다).

기존 데모 업데이트

git diff/git log로 변경된 페이지/텍스트를 확인 → 관련 씬과 pages/*만 업데이트 (코드에서 마크업 다시 복사), 캡션 주장 재확인, potong.ts 조정, 해당 씬의 스틸 검증, 전체 재렌더링.

이전에 발생했던 함정 (시작하기 전에 referensi/jebakan.md를 읽으십시오)

React is not defined (모듈 수준 JSX) · 프레임 간 캐시로 인한 커서 점프 · 고아 렌더링 프로세스가 CPU를 소모 · blur/backdrop-filter로 렌더링 3배 느려짐 · Tailwind 중단점이 헤드리스 창 너비를 사용 · sticky가 스크롤된 콘텐츠에서 비활성화 · 병렬 렌더링과 반쯤 완성된 파일이 번들을 손상 · Remotion ffmpeg에 fps/tile 필터가 없음 · 잘못된 기능 주장이 사용자에게 발견됨.

이 스킬의 참고 자료

• referensi/arsitektur.md — 엔진 API (Stage, 커서/스크롤/카메라/스포트라이트 단계, 시간 맵, 키트)
• referensi/jebakan.md — 함정 목록 및 해결 방법
• referensi/storyboard.md — 씬 구성 방법, 캡션, 템포, 조사 목록
• referensi/brief-fork.md — 하위 에이전트 포크로 병렬 씬을 작성하기 위한 브리프 템플릿
• referensi/render.md — 렌더링 명령, 속도, GPU, 압축, 전송
• templat/ — 스캐폴드가 복사하는 코드 · skrip/ — 스캐폴드, 프로세스 정리, 연속 스틸, 압축
• 실제 13개 씬 예제 (랜딩 + 스크롤, 스포트라이트 둘러보기 + 대화 상자, 휴대폰 QR 스캔, 대시보드 + 휴대폰 분할 화면, 페이지 이동 + 결제)는 작성자의 ChatGerCep 프로젝트에서 가져왔습니다. 패턴은 templat/src/scenes/contoh.tsx와 referensi/arsitektur.md에 있습니다.