WesleyQDev/rooster-edit

RoosterEdit

RoosterEdit은 에이전트를 위한 비디오 스튜디오입니다. Remotion, HyperFrames 또는 FFmpeg를 대체하지 않습니다. 무엇을 만들지 결정하고, 자산을 정리하고, 계획을 작성하고, 선택한 엔진을 구동하고, 결과를 검토하고, 패키지를 제공합니다.

가장 중요한 규칙: 사용자가 명시적으로 중단 없음을 요청하지 않는 한, 계획과 미리보기가 승인되기 전에 렌더링하지 마십시오. 렌더링은 파이프라인에서 가장 저렴한 부분이지만 되돌리기에는 가장 비용이 많이 드는 실수입니다.

CLI 실행

이 스킬은 scripts/rooster.mjs CLI를 스킬의 기본 디렉토리 기준으로 제공합니다. 사용자 프로젝트 디렉토리에서 실행하고, 스킬 기본 경로를 기준으로 스크립트를 확인하세요. 아래 예시에서 <skill>은 기본 디렉토리를 의미합니다.

node "<skill>/scripts/rooster.mjs" doctor --json

명령을 실행하기 위해 사용자 프로젝트에 scripts/ 디렉토리를 생성하지 마십시오. 워크스페이스(rooster/)는 프로젝트에 속하고, CLI는 스킬에 속합니다. 쉘의 작업 디렉토리가 스킬 디렉토리인 경우 CLI가 잘못된 위치에 워크스페이스를 생성합니다.

스킬 설치 위치

사용자가 RoosterEdit 설치를 요청하면, 설치를 프로젝트 로컬(권장) 로 할지 글로벌로 할지 먼저 물어보세요. 현재 하네스가 실제로 읽는 스킬 폴더를 사용하고 OpenCode를 가정하지 마세요.

• 로컬: 하네스의 프로젝트 수준 스킬 폴더에 rooster-edit를 추가합니다(예: .opencode/skills, .claude/skills, .agents/skills). 버전이 프로젝트에 고정되고 다른 작업에 영향을 주지 않으므로 권장됩니다.
• 글로벌: 하네스의 글로벌 스킬 폴더에 rooster-edit를 추가합니다(예: ~/.config/opencode/skills 또는 ~/.claude/skills). 사용자가 머신의 모든 프로젝트에서 RoosterEdit을 사용하려는 경우에만 사용합니다.

하네스의 폴더를 확인할 수 없으면 스킬 검색 경로를 검사하거나 사용자에게 물어보세요. 복제하기 전에 답변을 기다리세요. 이 선택은 스킬이 있는 위치에 관한 것이며 비디오 워크스페이스(./rooster)가 있는 위치에 관한 것이 아닙니다.

보고

작업 종료 답변은 기본적으로 짧게(5-10줄 또는 간결한 표 하나) 유지합니다. 사용자가 조치를 취하는 데 필요한 정보만 포함합니다:

• 수행되거나 발견된 사항
• 결과물의 경로 또는 링크
• 누락되거나 차단된 사항 (있는 경우)
• 명확한 다음 질문 하나

브리핑을 반복하거나, 로그를 붙여넣거나, 모든 명령을 나열하거나, 사용자가 요청하지 않는 한 전체 스킬을 설명하지 마세요. 세부 사항은 워크스페이스 파일에 넣거나 참조 문서에 링크하세요. 계획, QA 보고서 또는 납품 패키지는 사용자가 내용을 검토해야 하므로 더 길어질 수 있습니다.

설치와 워크스페이스 설정은 별도의 단계입니다. 설치 후 doctor를 실행한 후, 온보딩을 시작하거나 가이드를 작성하지 마세요. 환경을 몇 줄로 요약하고 사용자가 지금 워크스페이스를 구성할지 물어보세요. rooster/ 또는 채널을 생성하기 전에 '예'라는 답변을 기다리세요.

진행 상황 업데이트

상태 업데이트와 모든 승인 게이트에서 간결한 단계 표시기를 사용하세요. 프로젝트에 대해 8단계 트래커 하나를 유지합니다:

1. 환경 및 워크스페이스
2. 브리핑 및 인테이크
3. 자산 및 대본
4. 편집 계획
5. 스토리보드 및 타임라인
6. 엔진 빌드
7. 미리보기 및 QA
8. 렌더링 및 납품

예시:

• 단계 3/8 — 대본 완료. 42개 구간, 10:12 길이.
• 단계 4/8 — 계획이 edit/plan.html에 준비됨. 타임라인으로 진행할까요?
• 단계 6/8 — 빌드 완료. 미리보기를 열고 QA를 실행할까요?
• 단계 8/8 — 미리보기 승인됨. 최종 렌더링을 진행할까요?

해당되지 않는 단계는 건너뛰고 이유를 설명하세요. 모든 메시지에 전체 체크리스트를 출력하지 말고, 현재 단계, 변경 사항, 다음 게이트를 표시하세요. 타임라인과 최종 렌더링을 하나의 승인으로 결합하지 마세요: 미리보기와 QA가 그 사이에 있습니다.

서브에이전트 우선 실행

주 에이전트는 작업자가 아닌 감독입니다. 사용자와 대화하고, 브리핑과 결정을 소유하며, 승인 게이트를 실행하고, 최종 프레임을 확인합니다. 힘든 작업은 단계 서브에이전트(대본 분석, 리서치, 스크립트 초안, 계획 초안, 스타일 및 스토리보드, 빌드 및 수정, QA 스윕, 렌더링 및 패키징)에게 넘어갑니다. 각 서브에이전트는 자체 컨텍스트를 가지며 단계가 끝나면 폐기되므로 원자재가 주 스레드에 축적되지 않습니다.

하네스에 서브에이전트 도구가 있을 때는 기본적으로 위임하세요. 저렴한 명령 하나일 때, 대화 자체(인테이크, 승인)일 때, 또는 최종 시각적 판단일 때는 단계를 인라인으로 유지합니다.

단계	서브에이전트	주 에이전트가 받는 것
브리핑	producer	한 문단 브리핑 + 열린 질문
리서치	researcher	5가지 발견 사항 + 출처 + 라이선스 플래그
대본	transcript-analyst	길이, 주제, 10-20개 비트, 플래그
스크립트	scriptwriter	훅 + 비트 요약
계획	editor	계획 요약 + 위험 요소
스타일/스토리보드	art-director	토큰 + 장면 수 + 자산 필요 사항
타임라인	editor	길이 계산 + 마커
오디오	audio-director	음성/음악/믹스 결정
빌드	engineer	상태 + 아티팩트 경로 + 차단 요소
QA	qa	평결 + 주요 이슈 + 프레임 경로
렌더	engineer	최종 경로 + 프로브 통계

짧은 프롬프트로 생성하세요: 역할 파일 경로, 프로젝트 경로, 한 문장 작업, 입력 경로, 제약 조건. 경로를 전달하고 브리핑, 대본, 로그 또는 계획 내용은 절대 전달하지 마세요. 입력이 대화 자체인 경우 먼저 work/intake.md에 답변을 작성하세요. references/subagents.md에 설명된 핸드오프를 요청하고 그 외에는 요청하지 마세요. 파일을 쓰거나 명령을 실행하는 단계에는 하네스의 범용 또는 작업자 에이전트를 사용하고, 리서치에는 읽기 전용 또는 리서치 유형을 사용하세요. 이는 기능 능력이며 도구 이름이 아닙니다: 하네스가 파일 및 명령 접근 권한이 있는 새 에이전트를 시작할 수 없거나 스폰이 두 번 실패하면 단계를 인라인으로 실행하고 파일 경계를 유지하세요.

핸드오프만 주 컨텍스트에 들어갑니다:

status: ok | needs-decision | blocked
artifacts: paths that exist
summary: <= 5 lines
decisions: what the main agent must confirm
blockers: what stops the stage
next: next stage or exact question

주 에이전트는 브리핑, 스크립트, 스타일, review.md 및 핸드오프를 읽고 plan.html과 3-5개의 프레임을 볼 수 있습니다. 원시 대본, 전체 계획 JSON, 생성된 코드, 빌드/렌더 로그 또는 수십 개의 프레임이 포함된 연락처 시트를 읽어서는 안 됩니다. 세부 사항이 누락된 경우 원시 파일을 열지 않고 동일한 서브에이전트에 후속 작업을 보내세요.

여기 있는 어떤 것도 종속성이 아닙니다. 단계가 인라인으로 실행될 때 아티팩트와 게이트는 동일합니다. 컨텍스트 격리만 잃을 뿐 워크플로우는 잃지 않습니다.

승인 게이트는 절대 서브에이전트로 이동하지 않습니다. 서브에이전트가 제안하고 사용자와 주 에이전트가 결정합니다.

설치 후 첫 실행

워크스페이스가 아직 존재하지 않으면 프로젝트를 생성하기 전에 짧은 온보딩을 하세요.

먼저 물어보세요: "지금 워크스페이스를 설정할까요?" 한 줄로 이 작업이 rooster/와 첫 번째 채널을 생성한다고 설명하세요. 답변이 '아니오'이면 멈추고 아무것도 생성하지 마세요.

답변이 '예'이면:

1. 기본적으로 ./rooster를 사용하세요. 사용자가 사용자 지정 경로를 원하지 않는 한 "워크스페이스가 어디에 있어야 합니까?"라고 묻지 마세요.
2. 한 가지 질문을 하세요: "이 채널은 무엇을 생산할 것입니까? 한 문장이면 충분합니다." 답변과 대화를 사용하여 채널 이름, 언어, 형식, 소스, 프로필, 자산, 엔진, 자율성 및 음성을 추론하세요. 채널 필드 12개를 모두 묻지 말고 기간을 묻지 마세요.
3. 추론된 기본값을 간결한 한 줄로 보여주고 "괜찮습니까? 아니면 조정할 사항이 있습니까?"라고 물어보세요. 플랫폼이나 소스가 실제 푸티지인지 여부와 같이 필드가 진정으로 모호한 경우에만 후속 질문을 하세요.
4. 확인 후 init을 실행한 다음 channel new <id> ...를 답변과 함께 실행하세요. 짧은 요약을 보여주고 중단하세요.

기간은 채널 기본값이 아닙니다. 각 프로젝트에 속하며 비디오가 생성될 때 선택됩니다. 전체 12개 필드 설정은 선택적인 고급 경로입니다. 사용자가 모든 것을 사용자 지정하려면 한 번에 최대 3개씩 그룹으로 물어보고 한 번에 모두 묻지 마세요.

채널은 브랜드, 대상 또는 운영(예: "EN Tech" 또는 "PT Criador")을 위한 안정적인 그룹입니다. 언어, 형식, 프로필, 자산 정책, 엔진, 자율성 및 음성과 같은 창의적 기본값을 소유합니다. 모든 프로젝트는 채널에 속하며 해당 기본값을 재정의할 수 있습니다. 기간은 프로젝트별로 설정되며 채널 기본값이 아닙니다.

사용자가 명시적으로 요청하지 않는 한 같은 차례에 비디오를 시작하지 마세요. 정확한 질문, 기본값 및 명령은 references/onboarding.md를 읽으세요. 자산을 다운로드하거나 생성하기 전에 references/assets.md를 읽으세요.

빠른 경로: 6단계 비디오 워크플로우

사용자가 원시 푸티지에서 완성된 비디오까지 가장 간단한 경로를 원할 때 참조 워크플로우와 동일한 6단계를 따르되 RoosterEdit 워크스페이스에 맞게 조정합니다:

1. 머신 준비 — FFmpeg, Node.js LTS, Python 3, HyperFrames 및 Whisper(또는 HyperFrames의 Parakeet/whisper.cpp). 설치하기 전에 물어보세요.
2. 프로젝트 생성 또는 확인 — rooster new ...; 원시 미디어는 assets/source/로 이동합니다.
3. 스타일 가이드 작성 — art-director가 style.md를 작성하고 프로필을 확인합니다. 계획을 세우기 전에 styleproof <slug>를 실행하고 세 개의 샘플 프레임을 승인하세요.
4. 대본 작성 및 계획 — transcript-analyst가 edit/transcript.json, edit/digest.md 및 edit/analysis.json을 작성합니다. editor가 분석 및 style.md에서 edit/plan.json을 작성합니다. 대본 컨텍스트가 포함된 plan.html을 보여주고 승인을 기다리세요.
5. 시각적 요소 생성 — 채널 스타일이 요구할 때 engineer가 자막(레트레이루), 그래픽, 목록, 줌, B-롤, 하단 써드, 음악 및 SFX를 구축합니다. 사용자가 명시적으로 깔끔한 컷을 요청하지 않는 한 컷만 있는 초안은 완성된 비디오가 아닙니다.
6. 어셈블, 검토, 내보내기 — engineer가 승인된 계획에서 HyperFrames 또는 Remotion 프로젝트를 생성하기 위해 build를 실행합니다. 전체 빌드 전에 --sample 3을 사용하세요. qa가 preview/index.html과 프레임을 검사한 다음 engineer가 renders/로 렌더링합니다. 사용자가 DaVinci 또는 Premiere를 원할 경우 export가 EDL/FCPXML 핸드오프를 작성합니다.

정확한 명령과 참조 비디오 폴더에서 우리 폴더로의 매핑은 references/video-pipeline.md를 읽으세요. 이 스킬의 나머지 부분은 더 넓은 스튜디오 모드입니다. 빠른 경로는 단일 비디오 작업의 기본값입니다.

운영 원칙

• 생성하기 전에 직접 확인하세요. 명확한 브리핑, 스크립트 및 샷 목록은 프롬프트 조정보다 더 많은 시간을 절약합니다. 작업의 첫 부분을 비디오 이해에 투자하세요.
• 추측하지 말고 검사하세요. 파일을 읽고, 미디어를 조사하고, 프레임을 보고, 도구를 확인하세요. 코드가 올바르게 보인다고 렌더나 자산이 존재한다고 주장하지 마세요.
• 편집 가능한 상태를 유지하세요. 일회용 스크립트보다 명명된 장면, 변수 및 읽기 쉬운 구성 요소를 선호하세요. 사용자는 프로젝트를 다시 작성하지 않고도 색상, 줄 또는 클립을 변경할 수 있어야 합니다.
• 눈으로 검토하세요. 브라우저 미리보기, 스크린샷 또는 렌더링된 스틸을 사용하여 구성, 페이싱 및 자막을 판단하세요. 코드 검토만으로는 충분하지 않습니다.
• 출처를 존중하세요. 모든 자산이 어디서 왔는지와 라이선스를 기록하세요. 라이선스가 없는 트랙이 포함된 아름다운 비디오는 책임입니다.
• 우아하게 저하하세요. 하네스에 서브에이전트, 브라우저, Node, FFmpeg 또는 TTS가 없을 수 있습니다. 사용 가능한 최상의 경로를 제공하고 누락된 사항을 알리세요.
• 무거운 단계는 위임하세요. 주 에이전트가 지시하고 단계 서브에이전트가 힘든 작업을 수행하며 짧은 핸드오프를 반환합니다. 대본, 빌드 로그, 생성된 코드 및 QA 스윕은 주 컨텍스트를 통과하지 않아야 합니다. references/subagents.md를 읽으세요.
• 짧게 보고하세요. 모든 작업을 결과, 경로 및 하나의 다음 질문으로 끝내세요. 사용자가 요청하지 않는 한 전체 프로세스를 설명하거나 명령을 덤프하지 마세요.
• 창의적인 레이어를 완성하세요. 컷만으로는 비디오가 아닙니다. 사용자가 명시적으로 깔끔한 컷을 요청하지 않는 한 오버레이, B-롤, 음악, SFX 또는 자막을 계획하세요.
• 확실하지 않으면 물어보세요. 선택이 컷, 외관, 오디오 또는 비용을 변경하는 경우 현재 단계 X/8에서 물어보세요. 조용히 추측하지 마세요.
• 컨텍스트를 보호하세요. 비디오 작업은 토큰이 많이 사용됩니다. 엔진 로그를 파일로 리디렉션하고, 꼬리만 읽고, 전체 대본 대신 digest를 사용하고, 모든 프레임 대신 몇 가지 주요 프레임을 검사하세요. references/token-discipline.md를 읽으세요.

0단계 - 워크스페이스 찾기

먼저 현재 프로젝트에서 rooster/ 디렉토리를 찾은 다음, ROOSTER_WORKSPACE가 설정되어 있으면 사용하세요. 기본값은 ./rooster이며, 사용자가 원할 때만 사용자 지정 경로를 물어보세요.

둘 다 존재하지 않고 사용자가 이미 비디오를 만들라고 요청했다면 워크스페이스 생성이 암시됩니다. 다음을 실행하세요:

node "<skill>/scripts/rooster.mjs" init

사용자가 방금 스킬을 설치했거나 탐색 중인 경우, 자동으로 생성하지 말고 "설치 후 첫 실행"을 따라 먼저 물어보세요.

워크스페이스는 채널, 프로젝트, 프로필 및 자산 라이브러리가 있는 곳입니다. 스킬 디렉토리 밖에 두세요. 스킬은 재사용 가능하고 워크스페이스는 사용자의 비디오 프로젝트에 속합니다.

워크스페이스가 존재하지만 채널이 없으면 프로젝트를 생성하기 전에 채널을 만드세요. 모든 프로젝트는 채널에 속합니다. default 채널은 일회성 비디오를 처리합니다.

사용자가 질문만 하거나 아이디어를 탐색 중인 경우 워크스페이스를 생성하지 않고 답변하세요. 질문은 빌드 요청이 아닙니다.

1단계 — 기능 확인

실행:

node "<skill>/scripts/rooster.mjs" doctor --json

이 명령은 Node, npm, Python, FFmpeg, FFprobe, Git, GPU, 감지된 엔진, TTS 제공자, yt-dlp, Whisper 및 HyperFrames CLI를 보고합니다. 하네스 자체는 서브에이전트와 브라우저를 사용할 수 있는지 알고 있습니다. 해당 지식을 CLI 출력과 결합하세요. 비용은 docs/COSTS.md를 읽으세요. 명시적 허가 없이 유료 제공자를 호출하지 마세요.

무언가 누락된 경우 references/harness.md를 읽으세요. 간단한 버전:

• Node 없음: 컷 및 오디오에 FFmpeg를 직접 사용할 수 있지만 HyperFrames 또는 Remotion을 실행할 수 없습니다.
• FFmpeg 없음: 계획, 스크립트 및 스토리보드는 가능하지만 로컬에서 프로브하거나 렌더링할 수 없습니다.
• 브라우저 없음: 스틸 또는 프레임을 렌더링하여 이미지로 검사합니다.
• TTS 없음: 사용자 음성, 자막만 사용하거나 로컬...

(원문이 잘렸으므로 제공된 내용까지만 번역했습니다.)