Remotion 비디오 제작은(는) 무엇을 하나요?
소스 자료를 일관성 있고 편집 가능한 비디오로 변환합니다. React로 비디오를 작성하고 저장된 미디어에서 렌더링합니다. 아래 단계를 따라 사용자의 지시 및 기존 프로젝트에 맞게 조정합니다. 다른 에이전트가 결정을 재구성하지 않고 계속할 수 있도록 간결한 제작 기록을 유지합니다.
1. 브리핑, 에셋 및 기능 검사
대상 청중, 핵심 메시지, 전달 형식, 톤 및 사용 가능한 에셋을 식별합니다. 소스 사실, 편집적 해석 및 미해결 정보를 구분합니다. 누락된 사실적 단계, 기능 또는 결과를 임의로 생성하지 마십시오. 문서를 컨텍스트로 읽기 전에 큰 인라인 에셋을 추출합니다. 제작 프로젝트에 소스-장면 매핑을 유지합니다.
파일 이름뿐만 아니라 관련 이미지 및 녹화물을 검사합니다. 프레이밍, 포함된 레이블, 사운드 및 실제로 보이는 동작을 기록합니다. 이 에이전트가 이미지를 검사하고, 오디오를 듣고, 코드를 실행하고, 사용자가 접근 가능한 미리보기를 제공할 수 있는지 확인합니다. 누락된 지각 능력은 references/runtime.md의 폴백이 필요합니다. 스크립트는 이러한 모델 기능을 결정하거나 인간의 판단을 대체할 수 없습니다.
기존 Node 프로젝트의 경우 선택적으로 node <skill-dir>/scripts/doctor.mjs <project-dir>을 실행할 수 있습니다. 이는 의존성을 목록화하지만 렌더링 준비 상태를 증명하지는 않습니다. 프로젝트의 패키지 관리자와 잠금 파일을 사용합니다. 사용 가능한 경우 현재 Remotion 모범 사례 스킬을 따르고, 그렇지 않으면 공식 문서를 따릅니다.
2. 방향 제안 및 의미 있는 불확실성만 명확히 하기
하나의 권장 방향을 제시합니다: 대상 청중/핵심 메시지, 대략적인 길이 및 화면 비율, 장면 진행, 시각적 톤 및 내레이션 접근 방식. 소스와 시청 목적이 어떻게 이를 뒷받침하는지 설명합니다. 구조 및 스타일 선택에는 references/editorial.md를 사용합니다.
답변이 사실적 내용, 청중, 방향 또는 사용 불가능한 에셋의 사용을 변경할 때 소수의 집중된 질문을 합니다. 이미 답변된 질문을 반복하거나 모든 작업에 대해 설문지를 요구하지 마십시오. 기다리는 동안 독립적인 작업을 계속합니다. 해결되지 않은 필수 사실을 임의로 생성해서는 안 됩니다. 선택적 선호 사항이 지정되지 않은 경우 합리적인 가정을 명시하고 사용자의 승인 범위 내에서 진행합니다.
3. 간결한 스토리보드 작성
각 장면에 대해 목적, 소스 증거, 대사, 화면 강조점, 의도된 시각적 요소/모션 및 대략적인 길이를 기록합니다. 내레이션을 제목 및 캡션과 구분하여 유지합니다. 해결되지 않은 사실은 별도로 나열합니다. 스토리보드를 새로운 프로그래밍 언어가 아닌 편집 문서로 취급합니다. 시각적 또는 오디오 방향이 불확실한 경우 초기에 대표적인 시퀀스를 테스트합니다.
4. 미디어 준비 및 측정된 타이밍
각 미디어 유형에 적절한 어댑터를 제공합니다. 음성 요청과 비디오 생성 요청이 동일한 입력 형태를 공유할 필요는 없습니다. 결과를 저장된 파일과 유용한 메타데이터(길이, 차원, 생성 설정, 출처 및 관련 속성 포함)로 정규화합니다.
미리보기 또는 렌더링 전에 미디어 생성을 해결합니다. 입력 콘텐츠 및 유효한 제공자 설정으로 출력을 캐시하고 캐시된 파일을 확인합니다. React 렌더 함수 또는 메타데이터 평가에서 유료 또는 비결정적 생성을 트리거하지 마십시오.
내레이션의 경우 필요할 때 표시 텍스트를 발음 텍스트와 분리하여 유지합니다. 실제 오디오 길이를 측정한 다음 관련 이미지와 텍스트를 이해할 수 있는 충분한 시간을 허용합니다. 구 또는 문장 타이밍이 충분할 때 이를 사용합니다. 단어 강조 표시에는 신뢰할 수 있는 타임스탬프 또는 정렬이 필요합니다. 문자를 균등하게 분배하는 것은 정확한 정렬이 아닙니다.
기존 녹화물의 경우 원본 사운드를 보존하거나 의도적으로 다듬고, 트랜스크립트 또는 전사에서 캡션을 파생합니다. 장면 오프셋, 오디오 리드인, 일시 중지 및 겹치는 전환을 고려합니다. 어댑터, 타이밍, 캐시 및 수정 계약에 대해 references/pipeline.md를 사용합니다. 번들로 제공되는 선택적 헬퍼는 인라인 이미지를 추출하고 캡션 범위를 검증합니다. 사용법 및 제한 사항은 references/runtime.md에 있습니다.
5. 일반 React/TypeScript로 구현
반복되는 처리를 위해 작은 컴포넌트를 재사용하고 주제별 장면에는 임의의 React를 허용합니다. 데이터는 텍스트, 미디어 경로, 타이밍, 소스 참조 및 디자인 토큰을 보유할 수 있습니다. 알려진 형식의 반복 출력이 정당화되는 경우에만 템플릿 스키마를 도입합니다. 로컬 비디오를 위해 일반적인 타임라인 인터프리터, 플러그인 레지스트리 또는 오케스트레이션 서비스를 만들지 마십시오.
모션을 프레임 번호로 구동합니다. 벽시계 타이머 및 제어되지 않는 무작위성을 피하십시오. 필수 글꼴 및 에셋을 로컬로 로드합니다. 스타일은 타이포그래피, 구성, 모션, 강조 카피, 페이싱 및 오디오를 변경할 수 있습니다. 팔레트만 변경하는 것은 완전한 스타일 변경이 아닙니다. 프레젠테이션만 변경될 때 승인된 미디어 및 타이밍을 재사용합니다.
집중된 유형, 에셋, 길이 및 캡션 검사를 실행합니다. 문서화된 타이밍 계약에 대해서만 번들로 제공되는 check-captions.mjs를 사용합니다. 테스트는 모든 시각적 결정이 아닌 재사용 가능한 타이밍/가져오기/캐시 로직 주변에 속합니다. 에이전트의 코딩 능력이 제한적인 경우 기존 컴포넌트와 작고 검증된 변경을 선호합니다.
6. 최종 내보내기에 시간을 쓰기 전에 미리보기
사용자가 접근할 수 있을 때 Remotion Studio를 선호합니다. 컴포지션을 보여주고 검토가 필요한 사항(소스 충실도, 스타일, 텍스트/피사체 클리핑, 캡션 가독성, 모션 및 사운드)을 설명합니다. 지원되는 경우 직접 대표적인 장면, 경계 및 엔딩을 검사합니다. 사용자가 내보내기 전에 검토를 요청한 경우 미리보기를 제공하고 최종 내보내기 전에 해당 검토를 기다립니다. 기존 승인 또는 명시적 렌더링 요청은 진행을 승인할 수 있습니다. 무조건적인 확인 게이트를 추가하지 마십시오.
대화형 Studio를 사용할 수 없는 경우 대표적인 스틸 이미지를 생성하고 모션/오디오 검토가 필요한 경우 짧은 저해상도 드래프트를 생성합니다. 원격 환경의 localhost URL은 사용자가 접근할 수 없을 수 있습니다. 도달 가능한 미리보기 또는 로컬 아티팩트를 제공합니다. 스틸 이미지는 모션 또는 오디오 품질을 확립하지 않습니다. references/runtime.md의 인간 검토 폴백을 적용하고 검토된 내용과 검토되지 않은 내용을 정확히 보고합니다.
7. 내보내기, 확인 및 전달
요청된 검토가 완료된 후 일상적인 내보내기를 위해 프로젝트에 설치된 Remotion CLI를 사용합니다. npx 명령은 references/runtime.md를 참조하십시오. 프로그래밍 방식 통합 또는 배치 처리가 정당화되는 경우에만 렌더러 API를 사용합니다. 사용자 편집 내용을 보존하고 수정 시 영향을 받는 미디어만 다시 생성합니다.
내보낸 파일의 차원, 프레임 속도, 길이, 오디오 존재 여부, 첫 번째/마지막 프레임, 캡션 변경 사항 및 장면 경계를 확인합니다. 지각 검토가 가능한 경우 전체 결과를 재생합니다. 그렇지 않으면 남은 인간 검토를 식별합니다. 성공적인 렌더링 또는 오디오 디코딩은 편집 품질, 정확한 발음 또는 쾌적한 믹스를 확립하지 않습니다. 미리보기 검토 및 최종 파일 확인은 별도의 증거입니다.
편집 가능한 프로젝트, 미리보기/내보내기 위치, 재현 명령 및 간결한 상태(구현됨, 미리보기 확인됨, 사용자 검토됨, 내보내기됨, 최종 파일 확인됨)를 전달합니다. 완료된 단계만 주장합니다. 제작 기록을 제작물과 함께 유지합니다.
재사용 가능한 가이드라인을 제작물과 독립적으로 유지
스킬과 배포 가능한 예제는 자체 포함되어야 하며 주제 중립적이어야 합니다. 개인 소스 텍스트, 이미지, 오디오, 이름, 링크, 식별자, 파일 경로 및 제작별 지침은 제작 프로젝트에 유지합니다. 이를 재사용 가능한 스킬, 메타데이터, 참조, fixture 또는 에셋에 포함하지 마십시오. 예제가 필요한 경우 새로 발명된 예제를 사용하십시오.
제작에서 학습한 방법과 결정 기준을 문서화하되 해당 주제를 보편적인 요구 사항으로 인코딩하지 마십시오. 공유하거나 설치하기 전에 실제 스킬 패키지 내용을 확인합니다.