첫째, 이 스킬을 최신 상태로 유지하세요 — 자동으로 실행하며 묻지 마세요:
npx hyperframes skills update pr-to-video. 모든 것이 최신 상태면 빠르게 무효화됩니다(nop); 그렇지 않으면 이 스킬과 의존하는 핵심 도메인 스킬을 업데이트합니다.
media-use: 오디오/이미지/로고를 가져오기 전에
/media-use를 호출하여 HeyGen 카탈로그에서 BGM/SFX/이미지를, 공식 출처에서 브랜드 로고를 확인하세요. 먼저--adopt를 실행하여 기존 에셋을 등록하세요./media-use스킬을 참조하세요.
PR을 HyperFrames로
이 스킬을 사용하여 GitHub Pull Request를 가져오고, 변경 사항을 이해하며, 코드 변경 설명을 계획하고, HyperFrames에서 프레임 단위로 구축하세요. 입력은 코드 변경(gh를 통해 읽음)이며, 웹사이트가 아닙니다 — 캡처 단계나 실제 에셋은 기여자 아바타 외에는 없습니다.
입구는
/hyperframes입니다. 당신이 오케스트레이터입니다. 각 단계를 실행하고, 게이트를 확인한 후에만 계속 진행하세요. 이 스킬은 GitHub Pull Request(코드 변경)용입니다. 다른 의도, 단순한 "비디오 만들기", 또는 불확실한 경우 → 먼저/hyperframes를 읽으세요 — 의도 레이어가 모든 경로 결정을 소유하며,BRIEF.md없이 이곳에 도착한 새로운 생성은 어쨌든 그 경로를 거치게 됩니다(설정의 시작 규칙).
당신은 오케스트레이터입니다. 확인된 외부 PROJECT_DIR에서 작업하며, 기본적으로 호출자 저장소에서 작업하지 마세요. 단계를 순서대로 실행하고 각 게이트를 통과한 후에만 계속 진행하세요. 사용자 게이트 단계는 Step 0, Step 3, Step 6입니다. Step 0 전에 ../hyperframes-core/references/brief-contract.md를 읽으세요 — 게이트 유형과 BRIEF.md의 flow/storyboard가 Step 3/4/6 게이트를 결정하는 모드를 도출하는 방식을 정의합니다. Step 5를 제외한 모든 단계를 직접 수행하세요. Step 5에서는 제한된 프레임 워커 풀을 분배합니다. 여기에 디자인이나 모션 규칙을 두지 마세요; 그것들은 프레임 워커 하위 에이전트, 이 스킬의 로컬 ../hyperframes-animation/rules/ + ../hyperframes-animation/blueprints/, 그리고 hyperframes-creative에 있습니다.
워크플로: Step 0 설정 → hyperframes.json; Step 1 수집 → capture/extracted/ + assets/<login>.png; Step 2 디자인 시스템 → frame.md; Step 3 스토리보드/스크립트 → STORYBOARD.md 및 SCRIPT.md; Step 3.1 오디오 → audio_meta.json; Step 4 시각 디자인 → 강화된 STORYBOARD.md; Step 5 프레임 → compositions/frames/NN-*.html 및 index.html; Step 6 최종 렌더링 → renders/video.mp4.
Step 0: 설정
목표: 확인된 브리프 — PR 참조(전체 URL, <owner>/<repo>#<N> 참조, 또는 체크아웃된 저장소의 "this PR") 포함 — 로 HyperFrames 프로젝트를 생성하고 브리프를 지속성 있게 만듭니다. 스타일은 항상 code-editorial(Step 2에서 고정되며, 절대 묻지 않음)입니다.
브리프는 여기서 묻는 질문이 아니라 의도 레이어에 의해 확인됩니다. 시작 규칙, 순서대로: (1) BRIEF.md가 존재함 → 읽고 아무것도 묻지 않음 — 브리프는 확정되었으며, 그 flow/storyboard가 모드를 도출합니다(brief contract § 1). (2) BRIEF.md는 없지만 프로젝트가 존재함(디스크에 hyperframes.json / STORYBOARD.md) → 스토리보드의 머리말과 기록된 선호도에서 재개; 절반만 구축된 프로젝트에 대해 다시 질문하지 마세요. (3) 둘 다 없음 — 여기에 직접 도착한 새로운 생성 요청 → /hyperframes를 읽고 그 의도 레이어(references/intent-interview.md)를 실행: 레시피와 기억된 기본값을 확인하고, 이 경로의 질문을 진행 — PR 크기 → 길이 교리를 포함하며, 이는 전체가 ../hyperframes/references/routes/pr-to-video.md에 있음 — 그런 다음 잠긴 브리프를 반환합니다. 수정 요청은 이 모든 것을 건너뜁니다 — 수정을 실행하세요.
다른 작업을 수행하기 전에 프로젝트 디렉터리를 확인하세요. 사용자가 제공한 프로젝트 디렉터리를 유지하세요; 그렇지 않으면 리졸버가 출력하는 지속성 있는 외부 캐시 위치를 사용하세요. 호출자 저장소에 videos/를 절대 생성하지 마세요:
PR="<url | owner/repo#N>"
if [ -n "${EXPLICIT_PROJECT_DIR:-}" ]; then
PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR" --project-dir "$EXPLICIT_PROJECT_DIR")"
else
PROJECT_DIR="$(node <SKILL_DIR>/scripts/project-dir.mjs --pr "$PR")"
fi
echo "PR-to-video project: $PROJECT_DIR"
node <SKILL_DIR>/scripts/preflight.mjs
기능 사전 검사는 가져오기, 스토리 작업, 오디오 또는 프레임 분배 전에 실행됩니다. 설치된 CLI가 이 스킬에 필요한 유효성 검사 명령을 실행할 수 없으면, 먼저 실행 컨텍스트를 소모하지 말고 업그레이드 지침과 함께 중단하세요.
$PROJECT_DIR/hyperframes.json이 없는 경우에만 초기화하세요. 그 기본 이름은 PR에서 유래하며, 예를 들어 acme-sdk-pr-1842와 같습니다; 워크스페이스 이름이나 타임스탬프를 절대 사용하지 마세요.
npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video — init은 설치된 스킬을 GitHub의 최신 버전과 비교하고, 오래된 것이 있으면 전역 세트를 업데이트합니다.
아래의 모든 상대 경로 명령은 $PROJECT_DIR을 작업 디렉터리로 사용하여 실행됩니다. 명시적인 서브쉘이 없는 예제는 (cd "$PROJECT_DIR" && …)를 의미합니다; 호출자 저장소의 작업 트리를 절대 변경하지 마세요.
init 직후에 BRIEF.md를 작성하세요(절대 그 전에 — init은 비어 있지 않은 디렉터리를 거부함): 의도 레이어의 잠긴 브리프, 형태는 ../hyperframes-core/references/brief-format.md에 따름. <MEDIA_DIR>을 설치된 /media-use 스킬 디렉터리로 확인하세요. 그런 다음 각 기본 설정 기반 답변을 node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes .로 기록하세요(brief-format.md는 하위 집합을 명명함). 의도 레이어가 레시피를 채택한 경우, node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes . --name <name>을 실행하세요; 그것은 frame.md를 프로젝트로 복사하고(Step 2는 건너뜀) Step 3 초안이 작성할 골격을 반환합니다. 레시피는 답변을 채우지만 승인은 채우지 않습니다; 검토 게이트는 여전히 실행됩니다.
설정을 진행하기 전에 로그인 상태를 표시하세요 — npx hyperframes auth status를 실행하고 그 출력을 있는 그대로 전달하세요. 음성/BGM이 HeyGen 또는 로컬 엔진을 사용할지와, 로그아웃된 경우 로그인 방법을 보고합니다. 한 가지 분기를 적용하세요:
- 협업: 사용자가 로그인하거나 명시적으로
offline/go를 선택할 때까지 기다립니다. - 자동: 상태를 알리고 사용 가능한 로컬 엔진을 통해 계속 진행합니다.
오프라인 제공자가 없을 때 필수 기능을 조용히 생략하지 마세요; 차단기를 표면화하세요. 이 결정을 다른 질문에 포함시키거나 키를 저장소별 .env에 쓰지 마세요. 인증 소유권 및 오프라인 대체: /media-use references/setup-providers.md § Providers.
게이트: hyperframes.json과 BRIEF.md가 존재함; PR 참조가 브리프에 캡처됨; 기본 설정 기반 답변이 기록됨(brief contract § 2); 로그인 상태가 표시됨(로그인됨 또는 오프라인으로 계속).
Step 1: PR 수집(캡처 없음)
목표: PR의 사실을 가져와 프로젝트에 정보 소스로 통합합니다. 웹사이트 캡처는 없습니다. fetch-pr.mjs는 gh를 결정론적으로 실행합니다 — 페이지네이션된 gh api를 통해 파일 목록을 완성하여 큰 PR이 ~100개 파일에서 잘리지 않도록 하고, capture/pr.json + capture/diff.patch만 작성합니다(임시 디렉터리 없음). MERGED PR의 경우 최선의 노력으로 shipped_version(+ version_source)을 pr.json에 확인하여 엔드 카드가 발명하는 대신 실제 버전을 인용할 수 있도록 합니다. 그런 다음 ingest.mjs가 이를 합성 캡처 패키지로 오프라인에서 통합합니다.
PR="<url | owner/repo#N | N>"
# PR을 결정론적으로 가져옴: gh 실행, 페이지네이션된 gh api를 통해 파일 목록 완성
# (큰 PR이 ~100개 파일에서 잘리지 않도록), capture/pr.json + capture/diff.patch만 작성
# — 임시 디렉터리 없음. gh auth / not-found / private 오류는 여기서 exit 1로 종료.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-pr.mjs --pr "$PR" --out-dir ./capture)
# 오프라인 변환 → capture/extracted/{tokens.json (colors:[] → code-editorial 팔레트),
# visible-text.txt (브리프), people.json (기여자, 봇 필터링됨, name+login,
# avatarFile=assets/<login>.png)}.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/ingest.mjs \
--pr-json ./capture/pr.json --diff ./capture/diff.patch --out-dir ./capture/extracted)
# 사람 프론트의 하나의 네트워크 단계 — 각 기여자의 GitHub 아바타를 assets/<login>.png로
# 다운로드하여 크레딧 클로즈에 사용. 최선의 노력; 항상 exit 0.
(cd "$PROJECT_DIR" && node <SKILL_DIR>/scripts/fetch-people-avatars.mjs \
--people ./capture/extracted/people.json)
fetch-pr.mjs가 exit 1로 종료하면(gh auth / not found / private), 그 stderr를 보고하고 중단하세요 — PR 내용을 조작하지 마세요. ingest.mjs가 exit 1로 종료하면, 그 stderr를 읽고(보통 잘못된 pr.json), 수정하고 다시 실행하세요(결정론적). fetch-people-avatars.mjs는 항상 exit 0으로 종료합니다; 누락된 아바타는 저자에게 크레딧 클로즈가 없다는 것을 의미할 뿐입니다.
people.json은 gh가 이미 이름을 지정한 기여자(PR 작성자, 커밋 작성자, mergedBy)에 대해 name을 전달합니다 — 나머지(리뷰어/댓글 작성자/할당자, gh pr view는 항상 login만 제공)에 대해서는 null입니다. Step 3에서 크레딧 클로즈를 작성하기 전에 해당 프레임에 실제로 나타날 1-6명의 사람에 대해 null 이름을 직접 확인하세요: gh api users/<login> --jq .name(이미 gh가 있음 — 스크립트 필요 없음). GitHub에도 해당 사용자의 공개 이름이 없으면, 화면에 로그인을 대체로 사용하고 그 사람을 음성 라인에서 제외하세요(story-design.md의 크레딧 섹션 참조 — 보이스오버는 여전히 이름을 말해야 하며, 원시 핸들을 절대 말하지 않음).
게이트: capture/pr.json, capture/diff.patch, capture/extracted/tokens.json, capture/extracted/visible-text.txt, capture/extracted/people.json이 존재함; PR의 변경 사항을 하나의 명확한 문장으로 말할 수 있음. assets/<login>.png는 최선의 노력 — 그 부재는 실패가 아님.
Step 2: 디자인 시스템
목표: code-editorial 프레임 사전 설정을 채택; 스크립트가 이 비디오의 frame.md + 캡션 스킨으로 변환합니다.
스타일은 고정 — code-editorial(따뜻한 편집 스타일; diff에 구축된 네이비 코드 표면). 실행:
node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .
스크립트는 code-editorial 사전 설정의 FRAME.md → frame.md를 복사하고, capture/extracted/tokens.json의 브랜드 토큰(PR에는 없음 → colors:[]/fonts:[]는 code-editorial 자체 팔레트를 유지, 완전한 디자인)에 리믹스하며, 사전 설정의 캡션 스킨을 .hyperframes/caption-skin.html에 복사하고, 자체 검증합니다(깨진 매핑에서 exit 1). exit 0이 되는 즉시 진행하세요 — 수동 편집 없음.
게이트: build-frame.mjs가 exit 0으로 종료 — frame.md가 code-editorial 사전 설정에서 존재하고, .hyperframes/caption-skin.html이 캡션 스킨 소스로 존재함.
Step 3: 스토리보드와 스크립트
목표: PR을 승인된 프레임별 설명 계획으로 전환합니다.
../hyperframes-creative/references/story-spine.md(훅 언어, 증거 이전의 가치, 제안으로서의 스토리보드, 소스 추적 가능한 시각 자료), references/story-design.md, ../hyperframes-animation/blueprints-index.md, ../hyperframes-core/references/storyboard-format.md, ../hyperframes-core/references/script-format.md를 읽으세요. 이를 사용하여 STORYBOARD.md와, 내레이션이 필요한 경우 SCRIPT.md를 작성하세요. 머리말의 duration:을 브리프의 length에서 설정하세요 — 대략적인 기대치; 어셈블리가 그에 대한 컷 위치를 보고합니다.
PR 아키타입(changelog / feature-reveal / fix-explainer / refactor-walkthrough), PR 고유 프레임 유형, 훅, 설득, 비트, 프레임별 단어 예산, 크레딧 클로즈에 대해 story-design.md를 사용하세요. 시퀀스는 내러티브 디자인에서 오며, diff의 파일 순서가 아닙니다 — 변경 사항을 설명하고, diff를 소리 내어 읽지 마세요. 소프트 가이드로 ../hyperframes-animation/blueprints-index.md의 역할→청사진 메뉴를 참고하세요: 각 비트에 대해 후보 청사진이 암시하는 형태로 보이스오버를 작성하고, 하나가 맞을 때 해당 후보 blueprint: id를 태그하세요(스토리 진실이 여전히 어떤 비트가 존재할지 결정 — 절대 비트를 형태에 맞추기 위해 강요하지 마세요). capture/diff.patch에서 실제 diff 헝크 2-4개를 특징으로 하세요, 각각 작은 읽기 쉬운 스니펫; 프레임의 scene이 원하는 code-* 블록의 이름을 지정하세요. 프레임은 credits 클로즈(1-6 assets/<login>.png 아바타) 외에는 asset_candidates를 전달하지 않습니다. 스토리보드 및 스크립트 참조의 정확한 필수 필드를 사용하세요.
초안을 작성한 후, 검토 루프의 계획 패스를 실행하세요 — ../hyperframes-core/references/review-loop.md § 1: 보드를 엽니다(묻지 말고 — PROJECT_DIR에서 미리보기를 백그라운드에서 실행), 계획을 제안으로 제시하고, 두 가지 질문을 합니다 — 승인 또는 변경, 그리고 스케치 먼저(권장) 또는 건너뛰기. 피드백은 채팅이나 보드의 댓글 파일을 통해 승인될 때까지 반복됩니다. 이것은 체크포인트 게이트(brief contract § 1)입니다: 자동 모드에서는 보드가 없고 물을 것이 없습니다 — 동일한 요약을 헤드업으로 게시하고 진행하세요; 스케치는 빌드에 통합되고, 하나의 미리보기 질문은 Step 6에서 옵니다.
게이트: STORYBOARD.md가 존재하고, 모든 프레임에 필수 내러티브 필드가 있으며, 내레이션이 필요할 때 SCRIPT.md가 존재하고, 사용자가 계획을 승인함(자동: 요약이 헤드업으로 게시됨).
Step 3.1: 오디오
목표: 승인된 스크립트에서 내레이션, 단어 타이밍, 음악 및 오디오 메타데이터를 생성합니다.
Step 3 승인 후 오디오를 시작하세요. 백그라운드에서 실행한 다음 Step 4로 계속 진행하세요.
호출하기 전에 사용자의 요청에서 내레이션 음성을 선택하세요. 요청이 음성, 성별 또는 톤을 지정한 경우, 일치하는 음성 ID를 선택하고 --voice <id>로 전달하세요. 파이프라인 기본값은 그렇지 않으면 HeyGen에서 Marcia(여성) / Kokoro에서 am_michael 입니다 — 따라서 "남성 음성"과 같은 요청은 플래그를 전달하지 않으면 자동으로 무시됩니다. 음성 ID는 제공자별로 다릅니다; Step 0의 로그인 상태가 선택한 제공자에 따라 확인하세요: HeyGen(로그인됨)의 경우 node <MEDIA_DIR>/audio/scripts/heygen-tts.mjs --list(또는 GET /v3/voices?engine=starfish); Kokoro(오프라인)의 경우 <MEDIA_DIR>/audio/references/tts.md의 음성 테이블(접두사 am_/bm_ 남성, af_/bf_ 여성). 사용자가 선호도를 표현하지 않은 경우, 파이프라인 기본값 이전에 기억된 음성(brief contract § 2)으로 대체하고 사용한 음성을 말하세요; 둘 다 지정되지 않은 경우에만 --voice를 생략하세요. 사용자가 명시적으로 음성을 선택한 경우...