GitHub 단일 저장소 비디오 오케스트레이션
본 Skill은 GitHub 단일 저장소 비디오의 유일한 오케스트레이션 진입점입니다. 각 저장소는 독립적으로 사실, 기획, 스크립트, 화면 녹화, 타임라인, 오디오, 표지 데이터 및 릴리스 패키지를 소유하며, 공용 컴포넌트만 재사용합니다. 기존 작품 및 예시는 참고용으로만 사용해야 하며, 사실, 스키마 또는 시각적 하드 기준으로 사용할 수 없습니다.
1. 읽기 순서 및 책임
먼저 저장소 AGENTS.md에 명시된 문서를 읽고, 단계별로 완전히 읽고 실행합니다:
work-library-api-registration: 작업대 등록 또는 작업 복제 필드.~/.codex/skills/selfmedia-github-research/SKILL.md: 공식 출처 및 고위험 주장.~/.codex/skills/douyin-tech-content-planner/SKILL.md: 대상 청중, 고유 혜택, 후킹 및 증거 순서.~/.codex/skills/record-web-demo/SKILL.md: 증거 목록, 액션 플랜 및 실제 화면 녹화.~/.codex/skills/selfmedia-script-storyboard/SKILL.md: 최종 나레이션과 읽기 가능한 스토리보드를 먼저 결정하고, 최종 오디오 길이는 추정하지 않음.- 본 Skill의 오디오 규칙: 직렬 생성 및 실제 오디오 측정, 먼저 실제 길이와 자막 시간 획득.
~/.codex/skills/selfmedia-script-storyboard/SKILL.md: 화면 녹화 액션 시간과 측정된 오디오를 사용하여 Timeline v1.2 완성.~/.codex/skills/selfmedia-cover-design/SKILL.md: 3:4 및 4:3 두 가지 크기 표지.~/.codex/skills/selfmedia-remotion-render/SKILL.md: 공용 템플릿 렌더링.- 본 Skill의 프로세스 게이트: 단계 순서, 필수 산출물 및 작업대 상태 확인; 5개 파일 머신 계약 통과 후 직접 원자적 공식 릴리스 패키지 생성.
콘텐츠 Agent는 자신의 콘텐츠 유닛만 수정할 수 있습니다. apps/studio/src/root.tsx, 공용 템플릿, 공용 표지, 스키마, Preflight 및 릴리스 검증기는 주 통합 Agent만 수정할 수 있습니다. 여러 Agent가 동시에 공유 파일을 수정할 수 없습니다.
2. 등록 및 공식 콘텐츠 유닛
- 사용자가 공식 주제를 제출한 후, 먼저 작업대 등록을 완료해야 합니다: 새 콘텐츠는
POST /api/production-requests를 호출하고, 기존 디렉토리는POST /api/works를 호출한 후POST /api/production-requests/adopt를 호출합니다. 두 방식 모두 유효한work_id및 생산 요청 ID를 반환해야 합니다; 이 두 ID가 없으면 연구, 녹화 또는 렌더링할 수 없습니다. - 등록 성공 후에야
projects/github/videos/<content-id>/에 독립 콘텐츠 유닛을 생성하거나 인수하고,projects/index.yaml및projects/task-index.yaml을 동기화합니다.content.yaml,task.yaml및制作单.md는 모두 동일한work_id를 기록해야 합니다; 작업대 프로세스 인터페이스의 첫 번째 단계는 항상 "작업대 등록"으로 표시됩니다. - 작업대는 작업 요구사항만 저장합니다; 템플릿 복사 시 이전 저장소 URL, Star, 버전, 라이선스, 스크립트, 타임라인, 화면 녹화, 출처, 표지 데이터 및 릴리스 패키지를 지웁니다.
renderer.composition_id는 고정적으로GitHubProjectDemoTemplate입니다. 템플릿 ID는 작업대/API에서 반환하며, 특정 과거 작품의 템플릿 ID를 수동으로 의존하지 않습니다.- 사용자가 공식 작업을 제출하면 작업대가 8단계를 연속 실행하여
release_ready까지 진행할 수 있습니다. 사용자가 명시적으로 테스트를 요청하고 정지 지점을 지정한 경우에만stopAfterStageId를 설정합니다;planning은 제작 단만 제출하고,render는 렌더링 임시 저장만 유지하며 공식 디렉토리를 생성하지 않습니다. 작업대 연속 실행 시 동일한 Codex 세션을 재사용하며, 단계 게이트를 유지하지만 각 단계마다 컨텍스트를 다시 구축하지 않습니다. - 공식 콘텐츠 유닛에는 반드시 다음이 존재해야 합니다:
project.jsoncontent.yamltask.yamlresearch/facts.json制作单.md
- Pipeline research가 임시 작업 공간에 출력될 때, 공식 출처, 현재 사용 중인 동적 필드 및 고위험 주장 결론을 공식 콘텐츠 유닛에 다시 기록해야 합니다; 임시 디렉토리를 공식 프로젝트로 대체할 수 없습니다.
GitHub 단일 프로젝트 비디오는 하나의 수동 주요 문서 制作单.md만 유지하며, decision, voiceover, storyboard, assets, release의 5개 고정 표식 블록을 사용합니다. 새 작업은 research/decision.md, research/content-plan.md, script/voiceover.md, script/script.json, 创作提示词.md 또는 qa/를 생성하지 않습니다; 사실, 타임라인, 액션 플랜, 화면 녹화 목록, 오디오, SRT 및 렌더링 Props는 계속 독립적인 기계 파일을 사용합니다.
3. 출처, 위험 및 기획 게이트
- GitHub 저장소 페이지를 사용하여 프로젝트 신원을 확인하고 공식 URL을 저장합니다. 본 영상에 실제로 등장하는 고위험 주장에 대해서만 README, 공식 문서 또는 릴리스 페이지에 접근하며, 전 기능 백과사전식 검증을 수행하지 않습니다.
- 고위험 주장에는 다음이 포함됩니다: 동적 숫자 및 순위; 가격, 비용, 절감 비율 및 성능 비교; 보안, 개인 정보, 법적 결론; 라이선스, 버전, 유지 관리 상태 및 공식 신원; 절대적 약속; 실제 화면 또는 공식 출처로 뒷받침되지 않는 구체적인 결과.
- Star, 버전, 라이선스 등의 필드는 화면이나 카피에서 사용할 때만 검증합니다; 사용 시 공식 렌더링 전에 새로 고칩니다.
facts.json은 정확한 값, 출처 및 위험 결론을 저장합니다; 추가 고위험 주장이 없으면 빈 목록을 기록합니다. - 일반적인痛点, 의문문, 감정, 비유, 경미한 유머 및 실제 데모의 구어체 요약은 문장별로 검증하지 않습니다. 사용자가 제공하거나 승인한 후킹은 기본적으로 잠그며, 명백한 사실 오류, 법적 규정 준수 위험 또는 심각한 오해의 소지가 있는 경우에만 거부할 수 있습니다; 기타 위험은 최소 단어 수준으로만 수정합니다.
- 하나의 비디오는 하나의 핵심 혜택만 약속합니다. 먼저 대상 청중, 구어체 후킹, 첫 12초 이행 및 유일한 CTA를 결정한 후 스크립트를 작성합니다. 사실 파일은 나레이션에 README 기술 용어를 주입해서는 안 됩니다; 실제로 사용 가능 여부에 영향을 미치는 하드门槛만 해당 기능과 함께 자연스럽게 설명하며, 별도의 위험 알림 페이지, 대기 검증 페이지, 면책 벽 또는 적용 범위 페이지를 만드는 것을 금지합니다.
- 공개 완성품은 전체 URL, QR 코드, 다운로드 버튼, 외부 사이트 작업 지시 또는 일반 도구의 특정 금액을 표시하지 않습니다.
- 프로젝트 신원을 확인할 수 없거나, 공개 카피에 여전히 해결되지 않은 고위험 주장이 포함된 경우 중단합니다; 고위험 주장이 없으면 녹화 및 렌더링을 차단할 수 없습니다.
4. 실제 증거 및素材 시간
먼저 record-web-demo를 실행해야 합니다:
- 800×600 논리 뷰포트를 사용하여 README, 이미지/GIF, 후보 스크린샷 및 선택자를 수집합니다.
- 먼저 GitHub 저장소 신원 샷을 구성합니다: 실제 저장소 이름은 얇은 둥근 모서리 상자, Star 또는 버전은 얇은 타원형 원을 사용합니다; 이 샷은 모든 README 또는 외부 데모보다 먼저 배치해야 합니다.
- 그런 다음 핵심 혜택을 입증할 수 있는 1~3개의 README 또는 공식 데모 증거를 선택합니다; 파일 목록, 설치 로그, 로고 및 라이선스는 기본적으로 결과 증거로 사용할 수 없습니다.
- GitHub 신원 및 외부 데모는 독립적인 액션 플랜 및 화면 녹화 파일을 사용합니다; 각각 검증 통과 후 녹화합니다. 1600×1200 인코딩 소스가 필요한 경우
--pixel-scale 2후처리를 사용하며, 웹 페이지 레이아웃을 확대하지 않습니다. - 화면 녹화 목록은 각 실제 액션의
startMs,endMs, 페이지, 작업, 증거 객체 및 실행 결과를 기록해야 합니다. - 화면 녹화 스크립트는 성공적으로 완료되어야 하며, 목록의 액션은 실제
startMs,endMs및 완료 상태를 가져야 합니다; 실패한 액션은 타임라인에 포함될 수 없습니다. - 타임라인의
trimStartMs및trimEndMs는 화면 녹화 목록에서만 가져올 수 있으며, 완성 장면 시간을素材 시작점으로 사용하는 것을 금지합니다.
5. 스크립트 및 타임라인
길이는 정보량, 실제 나레이션 및 화면 판독 시간에 따라 결정되며, 25초로 고정되지 않습니다. 기본 내레이션 참조:
0~3초 GitHub 저장소 페이지, 프로젝트 이름, Star 및 핵심 가치
3~6초 README 결과 또는 공식 데모의 첫 번째 실제 증거
첫 12초 가장 강력한 실제 증거 등장
중반 1~2개의 증거 계속 시연
후반 적용 시나리오,门槛 또는 제한사항
끝 한 문장 요약 및 자연스러운 CTA
먼저 최종 나레이션과 읽기 가능한 스토리보드를 制作单.md의 voiceover 및 storyboard 블록에 기록합니다. 오디오 단계 완료 후, 측정된 실제 오디오 길이, 자막 시간 및 화면 녹화 목록을 사용하여 유일한 기계 감독 파일 timeline.json을 생성합니다. 타임라인:
packages/timeline-schema/timeline.schema.json사용, 버전1.2;- Scene
role은hook,proof,process,result,identity,cta만 허용; direction.proofByMs <= 12000;direction.demoLayoutPreset은 고정적으로fixed-demo-v1; 데모 외부 프레임 고정x=86, y=420, width=908, height=681;- 최대 하나의
visualPeak: true; focus는 검증된 소스 프레임에서 얻은 정규화 좌표 사용;- 데모 장면은
identityTop,evidenceTop,captionTop을 설정할 수 없음; 강조는 데모 프레임 내부에서만 발생 가능; - 화면 녹화에 이미 주석이 있는 경우 Remotion에서 중복 주석을 달지 않음;
- 장면, 자막 및 오디오가 전체 시간을 덮고, 중복, 경계 초과 및 무효 여백이 없어야 함.
제목, 표지, 첫 화면, 나레이션, 자막 및 릴리스 카피에는 반드시 GitHub 및 프로젝트 이름이 포함되어야 하며, 프로젝트 신원, 숫자 및 기타 고위험 사실이 일관되게 유지되어야 합니다. 세 플랫폼 제목은 각각 30개의 유니코드 문자를 초과할 수 없습니다. 세 플랫폼의 话题/标签 행에는 각각 #github优质项目 #github开源가 포함되어야 하며, 총 5~7개 중복되지 않는 태그로, 프로젝트 태그 및 현재 내용과 일치하는 최소 2개의 가치/시나리오 태그를 보완해야 합니다; 실시간 인기 태그는 최대 2개까지 보충 가능하며, 해당 플랫폼 증거가 있을 때만 추가할 수 있습니다.
6. 공용 Remotion 아키텍처
새 저장소는 공용 Composition만 사용합니다:
GitHubProjectDemoTemplateGitHubProjectCoverPortraitGitHubProjectCoverLandscape
GitHubProjectCoverFeed는 이전 버전 호환용으로만 사용되며, 새 프로젝트의 Composition 목록, 렌더링 작업 또는 릴리스 패키지에 포함되지 않습니다.
프로젝트는 구조화된 입력을 통해 타임라인, 프로젝트 이름, Star, 후킹, 결과, 프리셋 및素材를 전달합니다. 금지 사항:
- 새 저장소 전용 TSX 시각 시스템 생성;
- Root에 저장소 전용 비디오 또는 표지 Composition 등록;
- OpenMontage 또는 기존 프로젝트를 공용 템플릿 기본 사실로 하드코딩;
- 렌더링 단계에서 사실 변경,素材 시간 추측 또는 장면 재정렬.
GitHubProjectDemoTemplate은 템플릿 ID이며, 프로젝트 ID가 아닙니다. Studio는 고정적으로 http://localhost:3000/을 사용하며, 입력 속성을 통해 프로젝트 데이터를 선택합니다. 일반 TSX, CSS, JSON 및素材 변경은 핫 리로드에 의존합니다; 종속성, 구성, 진입점 변경, 서비스 무응답 또는 복구 불가능한 컴파일 오류가 있는 경우에만 재시작을 허용하고 이유를 기록합니다. CLI 공식 렌더링은 Studio 포트에 의존하지 않습니다.
공식 렌더링 전에 통합 Preflight를 한 번 실행합니다: 공식 파일 완전성, 공개 콘텐츠에 사용된 동적 필드 및 고위험 주장 유효성, 액션 플랜 및 화면 녹화 통과,素材 시간 적법성, 타임라인 스키마 통과, 제목 길이 통과, 오디오 모드 일관성, 표지 데이터 완전성. 하나라도 실패하면 즉시 중단합니다.
7. 오디오 모드
작업대, content.yaml 및 task.yaml의 일관된 voice.mode만 따릅니다:
generate-and-mix: 직렬로 Edge-TTS를 생성하여 릴리스 비디오에 믹싱; 최종적으로 AAC 48kHz 스테레오, 평균 볼륨 약 -20~-28dB.generate-reference: 참조 오디오를 생성하지만 믹싱하지 않음; 릴리스 비디오는 실제로 오디오 트랙이 없어야 함.self-recorded: TTS를 생성하지 않음; 릴리스 비디오는 실제로 오디오 트랙이 없어야 하며, SRT는 사용자 더빙 후 미세 조정을 위해 유지.
모드가 없거나 세 위치가 일치하지 않으면 Preflight 실패. 오디오 단계는 타임라인 단계 이전에 위치해야 함; 카피 변경 후 오디오를 다시 생성하고 측정하며, 이전 길이를 재사용하지 않음. 타임라인과 SRT는 이번 측정된 길이를 사용해야 하며, 오디오 또는 SRT가 타임라인 길이를 초과하면 렌더링에 진입할 수 없음.
8. 표지 및 공식 렌더링
표지는 반드시 selfmedia-cover-design을 실행해야 하며, 비디오 완성 후 임시로 조합할 수 없습니다. 비디오는 고정적으로 두 개의 독립적인 레이아웃 표지를 생성합니다: 3:4, 4:3; 비디오 프레임을 하드 크롭할 수 없으며, 9:16 비디오 스트림 표지를 생성하지 않습니다.
GitHub 시리즈 고정 정보 순서: GitHub 컬럼 신원, 프로젝트 이름, 프로젝트 이름 아래 금색 Star, 6~12자 구체적 결과. 표지 데이터는 본 프로젝트에서 가져와야 하며, 각각 3:4 및 4:3 두 파일을 생성합니다.
모든 프로젝트가 Preflight를 통과한 후, 한 번만 Bundle한 다음, 승인된 기획에 따라 일괄 렌더링합니다. 동일한 버전을 위해 반복적으로 미리 보기, 장면별 프레임 추출 및 재렌더링을 하지 않으며, QA 이미지 디렉토리를 생성하지 않습니다.
9. 미디어 에셋, 표지 및 멀티 플랫폼 릴리스
9.1 먼저 4가지 이미지 산출물 구분
하나의 프로젝트는 하나의 "이미지" 필드만 등록할 수 없습니다. 다음을 각각 관리해야 합니다:
| 산출물 | 용도 | 선호 생성 방식 | AI 이미지 생성 사용 여부 |
|---|---|---|---|
| 기사 내 이미지 | 아키텍처, 프로세스, 설치 단계, 실제 기능 설명 | 공식 스크린샷, 화면 녹화 프레임, Remotion 정적 프레임 또는 SVG; 필요 시에만 AI를 사용하여 사실을 담지 않는 배경 생성 | 기본적으로 사용 안 함; 사실 화면은 AI로 조작할 수 없음 |
| 기사 표지 | CSDN, Zhihu, 공식 계정 등의 기사 목록 썸네일 | Remotion/HTML/CSS 중첩 레이아웃 | AI로 텍스트 없는 배경 생성 가능하지만, 제목, 프로젝트 이름, Star, 숫자는 이후에 중첩해야 함 |
| 비디오 표지 | Douyin/Bilibili 동영상 또는 포토 에세이 입구 표지 | selfmedia-cover-design + 공용 Remotion Composition, 독립적으로 3:4 및 4:3 생성 | AI로 시각적 주체 생성 가능하지만, 비디오 프레임을 하드 크롭하여 표지를 대체할 수 없음 |
| Skill 아이콘 | SkillHub 탐색 페이지, Skill 패키지 메타데이터 | 프로젝트 아이콘 재사용 또는 selfmedia-imagegen으로 텍스트 없는 아이콘 생성 후, 512px로 크롭/내보내기 | 사용 가능; 아이콘 안에 작은 글자나 읽을 수 없는 영어를 넣지 마십시오 |
결론: 기사 표지와 비디오 표지는 비디오 첫 프레임을 잘라낸 것이 아닙니다. 기사 내 이미지도 모두 호출하여 생성할 필요가 없습니다. 실제 스크린샷은 증거를 담당하고, Remotion은 안정적인 레이아웃을 담당하며, AI 이미지 생성은 사실 위험이 없는 시각적 배경 또는 아이콘만 담당합니다.
9.2 이미지 에셋 생성 순서
각 프로젝트는 다음 순서로 에셋을 준비하며, 표지를 먼저 만든 후 사실을 보완하는 것을 금지합니다:
공식 출처 및 사실 검증
→ 실제 스크린샷/화면 녹화/README 증거
→ 기사 구조 및 비디오 스토리보드
→ 필요한 이미지 결정
→ 이미지 에셋 생성 또는 정리
→ Remotion으로 프로젝트 이름, 제목, 숫자 및 브랜드 레이아웃 통합 중첩
→ 기사 표지, 3:4 비디오 표지, 4:3 비디오 표지 생성
→ 크기/안전 영역/사실 일관성 검사
이미지 출처 선택:
- 실제 제품 화면: GitHub, 공식 데모, 공식 문서, 실제 실행 페이지에서 직접 스크린샷 또는 화면 녹화에서 프레임 추출.
- 설명형 도해: 우선 Remotion, SVG, HTML/CSS로 생성, 아키텍처 다이어그램, 순서도, 비교표 및 설치 단계에 적합.
- 분위기 배경:
selfmedia-imagegen을 사용하여 생성, 검증되지 않은 로고, Star, 버전 번호, 가격 및 기능 약속은 넣지 않음. - 기사 표지 제목: Remotion/HTML/CSS에서 중첩해야 하며, AI가 픽셀 내에서 중국어 텍스트를 생성하는 것에 의존하지 않음.
9.3 표지 필드 및 레이아웃 규칙
각 프로젝트의 표지 데이터는 별도로 저장해야 하며, 최소한 다음을 포함합니다:
cover:
eyebrow: "GitHub 开源项目"
project_name: "<프로젝트 이름>"
hook: "<6~12자 구체적 결과>"
star_text: "<실제 Star, 검증 날짜 포함>"
focal_asset: "<실제 스크린샷 또는 사실 위험이 없는 배경 이미지 경로>"
palette: "<본 프로젝트 선택 색상표>"
source_checked_at: "<YYYY-MM-DD>"
outputs:
portrait: "02-세로표지-3비4.png"
landscape: "03-가로표지-4비3.png"
GitHub 시리즈 고정 정보 순서: 컬럼 신원 → 프로젝트 이름 → 금색 Star → 하나의 구체적 결과. 표지 메인 제목은 하나의 혜택만 표현하며, "100개 프로젝트", 전체 기능 목록 또는 설치 명령어를 표지에 채워넣지 않습니다.
- 3:4:
1080×1440, 상단 경계 약115px, 하단 경계 약216px, 좌우 각각86px. - 4:3: 독립적으로 재배치, 3:4 표지를 늘리거나 하드 크롭하지 않음.
- 9:16 비디오 화면:
1080×1920, 코어 콘텐츠는 상단170px, 하단288px, 좌우86px의 프로젝트 안전 영역을 따릅니다; 이는 비디오 표지 크기가 아닙니다. - 제목, 프로젝트 이름, Star, 버전 및 기타 정확한 숫자는 결정적 레이아웃을 사용합니다; AI 이미지 내에서 정확한 텍스트를 생성하지 않습니다.
9.4 기사 이미지와 Remotion의 역할 분담
기사 게시 전에 기사 유형에 따라 선택합니다:
| 기사 내용 | 권장 에셋 | 설명 |
|---|---|---|
| 프로젝트 소개 | 1장 프로젝트 표지 + 1장 실제 GitHub 스크린샷 + 1장 핵심 능력 이미지 | 핵심 능력 이미지는 SVG/Remotion 사용, AI가 제품 스크린샷을 가장하지 않음 |
| 설치 튜토리얼 | 명령어 스크린샷, 터미널 스크린샷, 순서도 | 명령어와 경로는 실제 프로젝트에서 가져와야 함 |
| 아키텍처 분석 | SVG/Remotion 아키텍처 다이어그램 + 공식 README 스크린샷 | 구조 시각화, 사실 출처는 여전히 공식 저장소를 가리킴 |
| 비교 리뷰 | Remotion/HTML 테이블 + 각 프로젝트 공식 링크 | 검증된 필드만 비교 |
| 순수 의견 기사 | 표지 + 소량 분위기 이미지 | 분위기 이미지는 AI 생성 가능하지만, 제품 기능 증명에는 사용 불가 |
9.5 릴리스 플랫폼 계층화
릴리스는 모든 플랫폼에 동일한 원본을 게시하는 것이 아닙니다. "코드 출처, 스킬 배포, 기사 검색, 비디오 배포"로 계층화합니다:
| 계층 | 플랫폼 | 주요 작업 | 릴리스 콘텐츠 |
|---|---|---|---|
| 코드 메인 소스 | GitHub | 권위적 사실, 버전, Issue, Star | 소스 코드, README, CHANGELOG, License, Release |
| 국내 코드 미러 | Gitee | 국내 접근, 미러 진입점, 백업 다운로드 | GitHub와 동기화된 소스 코드 및 README, GitHub를 메인 소스로 명시 |
| 스킬 배포 | SkillHub | 스킬 검색, 설치, 버전 관리 | 합법적 Skill 패키지, manifest, 한글 설명, 아이콘, 버전 변경 사항 |
| 기사 검색 | CSDN, Zhihu, Juejin,头条, 공식 계정 | 장문 검색, 설명 및 트래픽 유도 | 플랫폼에 맞게 조정된 기사, 표지, 실제 스크린샷, 공식 링크 |
| 비디오/포토 에세이 배포 | Bilibili, Douyin | 발견, 데모, 팔로우 및 트래픽 유도 | 비디오, 칼럼/포토 에세이, 3:4 또는 플랫폼 요구 사항의 입구 이미지 |
| 선택적 확산 | 소수파(少数派), SegmentFault, 오픈소스 중국(开源中国), 블로그 파크(博客园) | 기술 독자 및 개발자 커뮤니티 | 콘텐츠가 실제로 적합한 경우에만 게시, 양을 채우기 위해 반복해서 게시하지 않음 |
100개 프로젝트의 최소 릴리스 조합 제안:
GitHub 메인 소스 + Gitee 미러
→ Skill이 있는 프로젝트는 SkillHub에 추가
→ CSDN / Zhihu / 공식 계정에서 플랫폼에 적합한 기사 버전 선택
→ Bilibili / Douyin에 데모 비디오 또는 포토 에세이 게시
SkillHub에는 모든 GitHub 프로젝트를 게시할 수 없습니다. 실행 가능한 Skill 패키지 구조, SKILL.md/manifest.yaml, 트리거 단어 및 자체 테스트 설명이 실제로 있는 프로젝트만 등록합니다; 일반 도구 저장소는 GitHub, Gitee 및 기사/비디오 콘텐츠만 게시합니다.
9.6 릴리스 전 플랫폼 어댑테이션
각 플랫폼에 대해 독립적인 release 필드를 생성하며, 하나의 Markdown을 모든 플랫폼에 원본 그대로 복사하는 것을 허용하지 않습니다:
release:
github:
repo_url: ""
release_url: ""
status: "pending"
gitee:
mirror_url: ""
sync_checked_at: ""
status: "pending"
skillhub:
skill_slug: ""
package_path: ""
icon_path: ""
status: "not_applicable"
articles:
csdn: { title: "", url: "", status: "pending" }
zhihu: { title: "", url: "", status: "not_applicable" }
wechat: { title: "", url: "", status: "not_applicable" }
media:
bilibili: { url: "", status: "pending" }
douyin: { url: "", status: "pending" }
각 플랫폼 완료 후 제목, 본문/README 주요 부분, 프로젝트 링크, 이미지 및 공개 상태를 다시 읽어야 합니다; 릴리스 로그는 실제 URL, 시간, 버전, 브라우저 환경 및 승인 결론을 기록합니다. 게시, 전송, 삭제 및 기존 원고 덮어쓰기는 여전히 수동 확인 작업입니다.
10. Release Check
Agent가 다음 기계 프로세스 게이트를 완료한 후, 5개 파일을 renders/release-package/에 기록합니다. 작업대 검증 통과 후 원자적으로 이름을 发布成品/로 변경하고 직접 release_ready로 진입합니다:
- 작업대 생산 요청이 유효한
work_id와 연결되어 있고, 라이브러리 기록 디렉토리가source_dir과 완전히 일치; 그렇지 않으면 중단, 출처 및 위험 검증, 화면 녹화 또는 렌더링 단계에 진입하지 않음; - Pipeline
validate --require-assets통과; - 타임라인 스키마,素材 길이, 첫 12초 증거 게이트 통과;
- 렌더링 명령어 성공, 비디오 출력 1080×1920, 30fps, H.264;
- 오디오 트랙이
voice.mode를 준수, TTS 및 SRT 끝이 비디오 길이를 초과하지 않음;generate-and-mix의 최종 평균 볼륨은 -28~-20dB 사이여야 함; - 두 표지 크기 및 이름이 올바름;
- 세 플랫폼에 각각 실질적으로 다른 제목과 설명이 있으며, 제목은 각각 30개의 유니코드 문자를 초과하지 않고, 설명은 실제 단락을 유지;
- 세 플랫폼 태그 모두
#github优质项目 #github开源포함, 각 행 5~7개의 중복되지 않는 태그, 프로젝트 태그 및 가치/시나리오 태그가 현재 내용과 일치; projects/index.yaml,projects/task-index.yaml,task.yaml,content.yaml상태 일치.
불완전 재생, 프레임 추출, 이미지별 확인, OCR, 연락처 표 또는 20:9 압력 맵을 수행하지 않으며, QA 이미지 및 주관적 보고서를 생성하지 않습니다. 최종 화면은 사용자가 확인합니다.
더 이상 rendered → visual_reviewed 수동 확인 단계를 설정하지 않으며, 중복 후보 패키지를 복사하지 않습니다. 하나라도 계약이 실패하면 发布成品/을 생성하거나 release_ready를 보고하지 않습니다. 공식 릴리스 패키지는 반드시 5개의 파일만 있어야 합니다: 릴리스 카피, 비디오, 3:4 표지, 4:3 표지, SRT. SRT는 고정적으로 04-字幕.srt로 명명됩니다; 최종 화면은 사용자가 공식 디렉토리에서 확인합니다.
자동 업로드하지 않고, 플랫폼 계정을 조작하지 않으며, 릴리스 후 데이터를 수집하지 않습니다.