옵션
집집 Skill 웹 개발 web-video-presentation

web-video-presentation

ConardLi/garden-skills ConardLi/garden-skills

기사나 스크립트를 동영상처럼 보이는 클릭 기반 16:9 웹 프레젠테이션으로 변환하고, 선택에 따라 AI 음성 내레이션을 추가할 수 있습니다.

...모든 것을 확장하십시오
0
업데이트 된 시간 2026년 9월 30일

웹 비디오 프레젠테이션

기사나 내레이션 대본을 단계별로 스크린 녹화가 가능한 "동영상으로 위장한 웹페이지"로 제작하며, 선택에 따라 내레이션 오디오를 합성할 수 있습니다. 결과물 = Vite + React + TS 프로젝트 + 챕터별로 분할된 오디오.

적용 사례

  • "나레이션 대본이나 기사가 있는데, 이를 동영상으로 만들어 주세요" —— 나레이션 중심의 콘텐츠
  • "동적 PPT"를 만들고 싶은 경우
  • 16:9 가로 화면 녹화, 큰 글자, 여백, 화면마다 애니메이션 효과 적용
  • 교육 / 제품 시연 / 키노트에서 영화 같은 느낌을 원할 때
  • Bilibili / YouTube / 틱톡 동영상 콘텐츠

이 스킬은 방법론과 협업 프로세스를 핵심으로 합니다. 스캐폴딩 템플릿은 토큰과 기본 요소를 제공하지만, 각 미학적 결정(색상, 서체, 모션 효과의 분위기)은 주제에 맞춰 재설계해야 합니다 —— 그대로 베껴서는 안 됩니다.

워크플로우 개요

Phase 1   内容编写
   1.1  识别用户输入
   1.2  一次产出 script.md + outline.md
        (口播稿 + 开发计划)
   ▼
[Checkpoint Plan]      ← 必须停。一次对齐 5 件事:
                         稿子 / outline / 主题 / 素材 / 开发模式
   ▼
Phase 2   网页开发
   2.1  脚手架(按选定主题)
   2.2  第 1 章 = 主线程 + 完整版本(强制 anchor)
        ▼
        [硬节点] 用户验收第 1 章 ← 不可跳过
        ▼
   2.3  第 2~N 章(按选定模式:A 逐章 / B 顺序 / C 并行)
   ▼
[Checkpoint Audio]     ← 必须停。是否合成音频
   ▼
Phase 3   音频合成(可选)
   ▼
Phase 4   录屏 + 后期

작업 디렉토리 규칙 (에이전트가 사용자의 현재 디렉토리 아래에 생성/편집):

my-video/
├── article.md          # 用户给原文时必有 —— 不删!开发阶段画面信息源
├── script.md           # 必有:保持原文语言的平台化口播稿(决定节拍)
├── outline.md          # 必有:开发计划(章节切分 + 每步内容 + 信息池)
└── presentation/       # 脚手架产出的 Vite + React + TS 项目
    ├── src/chapters/-/
    │   ├── .tsx     # 视觉实现
    │   ├── .css
    │   └── narrations.ts     # ★ step 数 + 口播文本的唯一真相源
    ├── scripts/
    │   ├── extract-narrations.ts   # 扫所有 narrations.ts → audio-segments.json
    │   ├── synthesize-audio.sh     # provider-agnostic runner(循环 segments)
    │   └── tts-providers/          # 每 provider 一个 .sh(内置 2 个)
    │       ├── README.md           # 三函数契约 + 5 段现成代码片段(11labs / edge-tts / say / azure / gcloud)
    │       ├── minimax.sh          # 默认 provider,用 mmx-cli
    │       └── openai.sh           # 内置 OpenAI TTS(curl + OPENAI_API_KEY)
    ├── audio-segments.json         # extract 产出(合成前 review)
    └── public/audio//.mp3   # 可选:合成的音频

핵심:narrations.ts 단계 수와 오디오 합성에 대한 유일한 진실의 원천입니다. 챕터 .tsx 에 if (step === N) 에 나타나는 최대 N + 1은 반드시 narrations.length와 같아야 합니다. 이는 5곳(스크립트 / 아웃라인 / 챕터 코드 / chapters.ts / 오디오 파일)의 값이 절대 어긋나지 않도록 보장합니다.

엄격한 자체 점검 프로토콜(전체 스킬에 적용)

다음 세 가지 산출물은 각각 완료 후 반드시 자체 점검 → 수정 → 재보고/추진 단계를 거쳐야 합니다:

산출물 자체 점검 체크리스트 출처
script.md SCRIPT-STYLE.md 3단계 자체 점검(형식 / 문체 / 소리 내어 읽기)
outline.md OUTLINE-FORMAT.md 자체 점검
단원 구현 완료 CHAPTER-CRAFT.md 완료 후 자체 점검

실행 방식 (역량에 따라 단계적으로 하향 조정하며, 격리가 더 잘된 방식을 우선적으로 사용):

  1. Agent Teams(최적) : 독립적인 리뷰어 에이전트를 하나 실행하고, "출력 파일 경로 + 해당 체크리스트 + 핵심 맥락"을 제공하여 항목별로 검토하고 결론을 엄격하게 보고하도록 합니다(어떤 항목이 통과/불합격인지 + 증거 + 수정 제안).
  2. subAgent(차선책): Teams 기능이 없더라도 subAgent를 실행할 수 있다면 subAgent를 사용하여 동일한 절차를 따릅니다.
  3. 자체 점검(최후의 수단) : 현재 에이전트 중 어느 것도 상기 기능을 갖추지 못한 경우, 직접 항목별로 엄격히 점검한다 —— 대충 훑어보고 통과시키는 것은 허용되지 않는다.

철칙: 결론을 받은 후 먼저 불합격 항목에 따라 결과물을 수정한 다음, 사용자에게 "완료됨

  • 자체 점검 결과 + 수정 내용"을 보고하십시오. 수정 없이 원본 결론만 보고하는 것은 규정 위반입니다.

각 단계별 문서 참조 가이드

단계에 따라 다른 문서를 참조한다. 긴 세션에서 에이전트는 원칙을 잊기 쉬우며, 특히 Phase 2.4의 “구현” 장은 N번 반복된다 — 매번 핵심 제약 조건을 다시 확인해야 한다.

단계 필독(매번 확인) 한 번에 모두 읽기 / 필요 시 참조
Phase 1.1-1.2 내용 작성 references/SCRIPT-STYLE.md + references/OUTLINE-FORMAT.md + article.md(사용자 원문, 있는 경우) ——
Checkpoint Plan 주제 선정 —— themes/*/theme.json(전체 내용을 동적으로 읽고, 목록 작성 + bestFor 추천 + descriptionZh);references/THEMES.md(사용자가 주제 시스템을 파악하고자 할 때)
Phase 2.1 스캐폴딩 —— SKILL.md 이 섹션 한 번 읽어보기
Phase 2.4 구현 단일 챕터 (×N회, 2.2 / 2.3에서 호출됨) references/CHAPTER-CRAFT.md 단일 진입점 —— Part 0 10가지 원칙 / Part 1 시작 전 5가지 질문 / Part 2 관계→행동 의사결정 트리 / Part 3 시각적 도구 상자 / Part 4 소요 시간 참고 / Part 5 AI적 요소 배제 반패턴 / Part 6 코드 엄격한 규칙 (narrations.ts 강제 제약 포함) / Part 7 완료 후 자가 점검 / Part 8 피드백 속성 참조 + 현재 주제의 themes//theme.json + 현재 장의 outline.md 단락 + article.md 본 장에 해당하는 단락 + 자료 목록 references/EXAMPLES/(구조 예시, 템플릿을 그대로 베낀 것이 아님);references/THEMES.md 완전한 토큰 계약
Phase 3 오디오 합성 references/AUDIO.md(narrations.ts → segments.json → 임의의 provider 흐름 포함, 내장 minimax + openai) templates/scripts/tts-providers/README.md(프로바이더 변경 / 자체 TTS 사용 시)
Phase 4 화면 녹화 + 후반 작업 references/RECORDING.md( ?auto=1 자동 화면 녹화 포함) ——
주제 선정 / 생성 / 세분화 —— references/THEMES.md

챕터를 작성할 때는 ‘CHAPTER-CRAFT.md’ 한 부만 참조한다. 10가지 원칙 / 작업 시작 시 자기 유도 / 의사결정 트리 / AI 특유의 느낌과 패턴 배제 / 작업 완료 후 자가 점검까지 모두 이 단일 창구로 통합한다.EXAMPLES/ 필독은 아님 —— 먼저 내용에 따라 자유롭게 설계하고, 막힐 때만 참조하세요(anchor를 따라 ‘형식’만 참고하고, 그대로 베끼지 마세요).

Phase 1 —— 콘텐츠 작성 (일회성 산출)

1.1 사용자 입력 식별

사용자가 제공하는 정보 해야 할 일
원본 글 (문어체 / 공식 계정 / 논문 / 블로그) 일회성 산출 script.md + outline.md(1.2), Checkpoint Plan 통과
직접적인 내레이션 대본 / 영상 대본 파일로 저장하여 script.md, 한 번의 제작 outline.md(1.2 간소화 버전), 체크포인트 플랜 통과
아무것도 없이, 단지 “X 주제의 영상을 만들어 주세요”라고만 말함 반문: 먼저 자료나 개요를 제공해 주세요. Skill은 사용자를 대신해 콘텐츠를 구상하지 않습니다

1.2 한 번에 script.md + outline.md 생성

두 가지 결과물을 한 번의 사고 과정을 통해 완성:

  1. script.md 생성: references/SCRIPT-STYLE.md 규칙에 따라 기사를 원문의 언어를 유지한 채 플랫폼용 나레이션 원고로 변환합니다. article.md는 삭제하지 말고 보관하세요 ——이 파일은 outline에서 정보 풀을 작성하고 각 장을 화면으로 구현할 때 세부 정보를 얻는 원천이 됩니다(이중 원천 원칙).
  2. outline.md 생성: references/OUTLINE-FORMAT.md 규칙에 따라 장을 나누고 + 단계를 나누고 + 각 장의 첫 문단에서 정보 풀을 추출한다.

outline의 경계(핵심):

outline에는 반드시 outline에 작성해서는 안 되는 사항
장 구분 / 각 장의 단계 수 / 예상 소요 시간 구체적인 애니메이션 유형 (blur clear / wipe / 스프링)
각 단계별 화면 내용 (헤로 / 데이터 / 슬로건 / 목록 항목) CSS 구현 방법 (filter / SVG / clip-path)
장 단위 정보 풀: article에서 추출한 숫자 / 인용문 / 사례 / 태그 재생 시간 수치 (2.5초 / 80120ms는 표기하지 않음)
단계별 관계 명칭 접두사(“대조” / “단계별 목록” / “명언” 등 선택 가능한 힌트) 지속적인 미세 움직임 / 시간 차 등 미시적 리듬

outline에 애니메이션을 명시하지 않는 이유: 고정된 애니메이션 = chapter agent가 번역기로 전락; 여백을 남겨 chapter agent가 각 단계 시작 시 CHAPTER-CRAFT.md "콘텐츠 주도 의사결정 트리"에 따라 자유롭게 설계할 수 있을 때 비로소 진정한 영상적 감각이 살아납니다. 자세한 내용은 CHAPTER-CRAFT.md Part 0 원칙 7을 참조하십시오.

계획 수립 후에는 반드시 자체 점검을 거친 뒤 Checkpoint Plan으로 진입해야 합니다: 앞서 언급한 「강제 자체 점검 프로토콜」에 따라 각각 다음에 대해 script.md / outline.md 실행해야 하며(우선순위: 에이전트 팀 → 서브에이전트 → 자체 점검), 결론에 따라 수정이 완료된 후에만 Checkpoint Plan으로 진입한다.

Checkpoint Plan —— 5가지 사항을 한 번에 정렬(하드 노드)

script.md + outline.md 작성을 마친 후에는 반드시 멈춰야 합니다. 사용자는 이 하나의 노드에서 동시에 5가지 사항을 확인합니다.

이 시점에서 에이전트가 수행해야 할 준비 작업

  1. 모든 themes/*/theme.json 가져오기 nameZh / descriptionZh / bestFor / mood —— 체크리스트를 하드코딩하지 마라
  2. 다음에 따라 script.md 내용 유형 / 키워드 / 어조에 따라, 주제에서 가장 잘 맞는 2~3 세트의 추천 항목을 적극적으로 선별한다 (일치하는 bestFor 필드)
  3. 한 번 훑어보고 outline.md 끝부분의 "자료 목록" 부분

템플릿 요약 (골격, 에이전트가 상황에 따라 내용을 채워 넣음)

内容计划写完,产出文件:
  📄 article.md     {若用户给原文则保留}
  📄 script.md      {X} 字 / ~{T} 分钟
  📄 outline.md     {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单

章节速览:
  1.      <章节标题>     步 ~s
  2. ...

接下来一次对齐 5 件事:

  1. 稿子 (script.md) 要不要改?
     可以直接编辑文件,或口头告诉我修改方向。

  2. 开发计划 (outline.md) 要不要改?重点看:
     - 章节切分 / step 数 / 估时是否合理(合理判断:每章 30~60s)
     - 每步屏幕内容是否清晰
     - 每章首段「信息池」是否有足够的 article 细节供画面挂
     - 末尾素材清单是否完整

  3. 选哪个主题?我的推荐:
     ★ <推荐 1:nameZh (id)> — 因为 ;
     ★ <推荐 2 / 推荐 3>
     其它可选:<剩余主题,nameZh + 一句话>
     也可以让我帮你做新主题(详见 references/THEMES.md)。

  4. 真素材怎么准备?粗看本视频要的图:<列粗略清单>
     a) 我从 <现有素材路径> 帮你挑   b) 你自己提供   c) 全部 placeholder

  5. 开发模式选哪个?

     **第 1 章无论哪种模式都必须主线程做完 + 用户验收**(强制 anchor)。
     差异在第 2 章及之后:

     A) 默认 · 逐章确认(推荐)
        每章做完都暂停验收 → 风险可控 / 节奏最稳
     B) 第 1 章后顺序开发(不并行)
        第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
     C) 第 1 章后并行开发(subagent)
        第 2~N 章用 subagent 并行 → 最快 / 用户控并行数(一次几章)
        ⚠️ 风格各章会有差异(这是预期,主题禁区兜底)

피드백 수신 후:

  • 원고 / 개요 수정 필요 시: 파일을 직접 편집하고, 편집 완료 후 한 번 알림(또는 구두로 설명하여 에이전트가 수정)
  • 주제가 명확해야만 Phase 2로 진행됩니다. 사용자가 "주제는 당신이 골라줘"라고 하면 → 추천한 것 중 첫 번째를 선택하고, 사용자에게 무엇을 왜 선택했는지 설명한 뒤 , 마음을 바꿀 기회를 줍니다
  • 형식 확정 → Phase 2로 진행

Phase 2 —— 웹 개발

2.1 스캐폴딩

bash /scripts/scaffold.sh \
  ./presentation \
  --theme=<用户选的主题 id>

bash /scripts/scaffold.sh --list-themes

사용자 지정 주제 → 먼저 references/THEMES.md "새 테마 만들기" 절차에 따라 하나 themes//, 그 다음 --theme=。

스캐폴딩을 통해 01-example 데모를 추가합니다. 1장의 실제 내용을 작성하기 전에 다음을 삭제하세요:

rm -rf presentation/src/chapters/01-example

그리고 presentation/src/registry/chapters.ts 안의 EXAMPLE_CHAPTER 의 import와 배열 항목을 제거하세요.

2.2 제1장 —— 메인 스레드 + 강제 검수

핵심: 제1장 = 한 번에 완성된 버전(리듬 + 시각적 요소 + 실제 자료 완비). “골격 버전”이라는 개념은 없음 —— 제1장에서는 사용자가 바로 검수할 수 있는 시연을 만들어야 한다.

왜 제1장은 반드시 메인 스레드여야 하는가:

  • 이것은 CHAPTER-CRAFT.md 이 가이드라인이 현재 테마 + 현재 소재 하에서 처음으로 구현되는 단계
  • 가이드라인에 사각지대가 있거나 테마 색상/글꼴 토큰이 부족할 경우, 제1장에서 반드시 드러나게 된다 —— 이때 사용자의 피드백을 통해 가이드라인을 수정하거나 테마를 조정할 수 있으며, 조기에 수정할수록 비용이 가장 적게 든다
  • 후속 장(순서나 병렬 여부와 상관없이)은 모두 제1장의 코드 패턴을 참고해야 하므로, 제1장은 해당 프로젝트의 “스타일 기준점(장 간 일관성을 강요하지는 않지만, 단일 장 자체는 완전한 설득력을 가져야 함)”

제1장을 완성한 후에는 반드시 작업을 중단하고 사용자의 검수를 기다려야 합니다:

第 1 章  做完了,dev server 在 localhost:5173 运行。

验收重点:
  □ 视觉气质对不对?符合  的预期吗?
  □ 节奏对不对?某些步太快 / 太慢 / 信息太薄?
  □ 内容驱动动画是否到位?还是有几步是无脑入场动画?
  □ 双源原则:屏幕画面有没有"口播没念但 article 能挂"的细节?
  □ 反 AI 味检查:紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有?

问题告诉我,我针对性改。OK 了告诉我"继续",我按选定模式做第 2 章及之后。

2.3 제2~N장 —— 선택한 패턴에 따라

모든 패턴에 적용되는 공통 규칙: 각 장은 독립적으로 CHAPTER-CRAFT.md 개발한다. 스타일은 장 간에 완전히 일치할 필요는 없음 —— 주제 색상 / 글꼴 토큰으로 시각적 통일성을 보장하며, 애니메이션 / 리듬 / 시각적 연출은 각 장이 자유롭게 구상하는 것이 디자인 의도이다.

모드 A · 기본 · 장별 확인

제2장 완료 → 검토를 위해 일시 중지 → OK → 제3장 → 일시 중지 → ... → 제N장. 각 장을 독립적으로 검토하며, 문제는 수시로 수정하고, 위험은 최소화되며, 진행 속도는 가장 안정적입니다. 사용자가 모드를 명확히 선택하지 않을 경우 기본적으로 이 방식을 따릅니다.

모드 B · 제1장 이후 순차 개발

제2장 → 제3장 → ... → 제N장. 메인 스레드에서 순차적으로 완료한 후, 마지막에 일괄적으로 검수합니다. 속도는 중간 정도이며, 에이전트가 병렬 작업을 지원하지 않는 환경에 적합합니다.

모드 C · 제1장 이후 병렬 개발 (서브에이전트)

서브에이전트를 사용하여 제2~N장을 병렬로 완료하며, 최대 병렬 처리 수는 사용자가 제어합니다(“한 번에 4장” / “한 번에 2장”). 가장 빠르지만, 장마다 스타일에 차이가 있을 수 있습니다. 이는 예상되는 현상이며, 그 이유는 다음과 같습니다:

  1. 각 서브에이전트는 다른 서브에이전트의 산출물을 볼 수 없어 기계적으로 정렬할 수 없음
  2. 장별 코드가 물리적으로 분리되어 있어(각 장마다 별도의 폴더 / 고유한 CSS 접두사), 서로 방해하지 않습니다
  3. 테마 토큰이 시각적 통일성을 보장합니다(색상 / 글꼴 / 헤로 숫자 / 카드 / 구분선 성격 / 장식), 분위기가 어긋나지 않습니다
  4. 스타일 불일치 = 사람이 직접 만든 영상 특유의 자연스러운 흐름(다양한 목소리 / 다양한 시점)

병렬 서브에이전트의 프롬프트에는 반드시 다음이 포함되어야 합니다:

  • 현재 장의 아웃라인 단락(정보 풀 포함)
  • references/CHAPTER-CRAFT.md 의 경로 (단일 필독 —— 시각적 시연 요구 사항 + 점진적 공개 + 이중 출처 원칙 + AI 특유의 느낌 배제 + 코드 레드라인 + 완료 후 자체 점검이 모두 이 문서에 포함됨)
  • 현재 주제 theme.json 의 descriptionZh / mood / bestFor(분위기만 참고하면 되며, 애니메이션 / 재생 시간 / 글자 크기 / 이모티콘은 chapter agent가 자유롭게 결정)
  • 제1장 코드는 “코드 스타일” 참고용(“시각적 표절 대상” 아님)
  • 엄격한 규칙: 각 장마다 고유한 CSS 접두사 사용 (.cd- / .mg- / .pm- / ...); 수정 금지 chapters.ts; 완료 후 실행 npx tsc --noEmit

중요: 어떤 모드를 선택하든, 사용자는 언제든지 도중에 모드를 전환할 수 있습니다. 제2장 완료 후 사용자가 "나머지는 병렬로" / "나머지는 장별로"라고 말해도 상관없습니다.

2.4 단일 장 구현 (각 장은 반드시 진행해야 함)

자세한 지침은 references/CHAPTER-CRAFT.md —— 단일 필수 읽기 진입점, 포함 사항: 시각적 시연 요구사항 / 단계적 공개 / 콘텐츠 선별 / 이중 출처 원칙 / 동영상 시연의 기본 미학 / AI 느낌이 나지 않게 하기 / 코드 금지 사항 / 완료 후 자체 점검.

핵심 요점 (CHAPTER-CRAFT.md에 상세히 기술됨):

  • 각 장에는 반드시 CSS / SVG / Canvas / JS 시각적 데모가 포함되어야 하며, 순수 텍스트로만 구성된 장은 금지됩니다.
  • 단계적 공개: 체크리스트 / 목록은 반드시 1개 항목 = 1단계여야 하며, 한 번에 모두 표시하는 것을 금지
  • 이중 출처 원칙: 진행 속도는 나레이션 대본과 일치해야 하며(순서 변경 금지), 세부 사항은 원문에서 발췌해야 함(정보 풀 + 본 장의 article 단락)
  • 완료 후 자체 점검을 항목별로 통과해야 하며, 기준 미달 시 수정 후 재검토 —— 위 「강제 자체 점검 규약」에 따라 실행 (우선순위: Agent Teams → subAgent → 자체 점검), 수정이 완료된 후 사용자에게 본 장의 전달을 보고

2.5 대대적인 수정 후 STORAGE_KEY 업데이트

변경 사항 chapters.ts(장 추가/삭제/재배열, 또는 특정 장의 narrations.ts 길이 변경) 후 , presentation/src/hooks/useStepper.ts 의 STORAGE_KEY(예: v4 → v5), 커서가 존재하지 않는 단계에 위치하는 것을 방지합니다.

Checkpoint Audio —— 오디오 합성 여부 (하드 노드)

Phase 2가 끝나면 반드시 중단하고 사용자에게 다음과 같이 물어봐야 합니다:

网页做完,{N} 章 {M} 步,dev server 在 localhost:5173 跑着。

要不要合成音频做"自动播放录屏"?
  ✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json,
           调 TTS provider 合成每步一个 mp3 到 public/audio/。
           合成完后用 ?auto=1 模式可以一镜到底录屏(音视频天然同步)。
           内置两个 provider:
             • minimax (mmx-cli)    —— 默认,中文音色稳
             • openai  (OPENAI_API_KEY) —— curl-based,多数已有 key
           其它后端 (ElevenLabs / edge-tts 免费 / macOS say 离线 /
           Azure / Google) 见 scripts/tts-providers/README.md 的现成片段。
  ✗ 不合成 → 跳过 Phase 3,直接 Phase 4 用手动录屏 + 后期配音。

합성할 것 → Phase 3. 합성하지 않을 것 → 바로 Phase 4.

Phase 3 —— 오디오 합성 (선택 사항)

자세한 절차는 references/AUDIO.md. 간략한 버전:

cd presentation
npm run extract-narrations   # 扫所有 narrations.ts → audio-segments.json
# 让用户扫一眼 audio-segments.json 确认文本对
npm run synthesize-audio                       # 默认 minimax provider,增量
# 或用内置 openai (要 OPENAI_API_KEY):
PRESENTATION_TTS=openai npm run synthesize-audio
# 或自定义:写一个 scripts/tts-providers/.sh,见该目录的 README.md

합성이 완료되면 사용자에게 다음 정보를 알려줍니다: 출력 위치 / 총 세그먼트 수 / 어떤 세그먼트의 길이가 비정상적인지 (너무 길면 = 해당 스텝을 분할 해야 함; 너무 짧으면 = 대본 내용이 부족함) — 마지막으로 리듬을 조정할 기회를 줍니다. 그런 다음 Phase 4로 진행합니다.

Phase 4 —— 화면 녹화 + 후반 작업

자세한 내용은 references/RECORDING.md를 참조하십시오. 두 가지 경로:

시나리오 권장 경로
Phase 3에서 오디오 합성 완료 Auto 모드 원테이크: 브라우저 실행 localhost:5173/?auto=1 → 스페이스 바 누르기 → 전체 영상 자동 재생 완료 → 녹화 중지 → 앞뒤 부분 잘라내기만 하면 완성, 사운드 트랙 후처리 불필요
Phase 3 건너뛰기 기본 Manual 모드에서 수동으로 클릭하며 진행 → 후반 작업 시 원하는 편집 도구로 음성 더빙

에이전트는 Phase 3 / Checkpoint Audio 이후 사용자에게 적합한 화면 녹화 경로를 적극적으로 안내합니다.

10가지 원칙 (한 문장 목록)

전체 내용은 다음에서 확인하세요 references/CHAPTER-CRAFT.md Part 0 —— 장을 작성할 때 거기서 확인하세요. 아래는 단지 목차입니다.

# 원칙 한 문장
1 16:9 고정 무대 내용 1920×1080 + 변환 스케일, 반응형 아님
2 전역 step 카운터 챕터는 step의 순수 함수이며, 타이머 없음
3 각 단계마다 전체 화면을 독점 if (step === N) return
4 내레이션 비트 = step 한 비트 = 한 스텝 = 한 가지 핵심 아이디어
5 숨겨진 모서리 컨트롤 진행 바 / 페이지 넘기기 버튼의 기본 투명도 0
6 무대에 크롬 없음 헤더 / 푸터 / 페이지 번호 / 브랜드 바 없음
7 콘텐츠 기반 애니메이션 먼저 내재된 동작을 찾고, 찾을 수 없을 때만 진입 애니메이션으로 보완; 지속적인 미세 움직임은 신중하게 사용
8 여러 요소를 하나씩 차례로 드러내기 1개 항목 = 1단계, N개 항목을 동시에 stagger로 표시하는 것은 금지
9 전체적으로 통일된 테마 챕터 간 표면 색상 변경 없음; 색상/글꼴은 토큰 단위로 적용, 그 외 크기는 챕터별로 자유롭게 설정
10 이중 출처 원칙 스크립트가 리듬을 정하고, 기사가 화면 밀도를 결정한다(정보 풀로 이어짐)

자주 있는 사용자 피드백 요약

간소화된 표 참조 references/CHAPTER-CRAFT.md Part 8 「자주 나오는 피드백 빠른 확인」. 핵심 : 먼저 어느 계층(리듬 / 시각 / 콘텐츠 / 코드)인지 파악한 후, 최소 단위만 수정하고 전체 장을 다시 만들지 마세요 .

관련 자료

“언제 읽을지”를 표시해 두고, 한 번에 전부 읽지 않도록 하세요:

파일 읽을 시기 내용
references/SCRIPT-STYLE.md Phase 1.2 필독 기사 → 내레이션 대본 규칙, 플랫폼별 변형
references/OUTLINE-FORMAT.md Phase 1.2 필독 outline.md 필드 사양, 명명 규칙, 장 구분, 정보 풀
references/CHAPTER-CRAFT.md Phase 2.4 각 장별 필수 읽기 링크 Part 0 10가지 원칙 / Part 1 시작 전 5가지 질문 / Part 2 관계→행동 의사결정 트리 / Part 3 시각적 도구 상자 / Part 4 재생 시간 / Part 5 AI 느낌이 나지 않는 반패턴 / Part 6 코드 엄격한 규칙 / Part 7 완료 후 자가 점검 / Part 8 피드백 빠른 참조
references/EXAMPLES/ 선택 사항 —— 구조 살펴보기 장 구조 예시 (hook / list-reveal / case-tech-review); 템플릿을 베낀 것이 아님
references/THEMES.md 주제를 선정/구상/분할할 때 완전한 토큰 계약 + 내장 주제 목록 + 창작 프로세스
references/AUDIO.md Phase 3에서 읽기 provider-agnostic 오디오 합성 프로세스, 내장 미니맥스 사용법, 제공자 변경 경로, 문제 해결
templates/scripts/tts-providers/README.md TTS 제공업체를 변경하거나 추가할 때 3가지 함수 계약 + 내장 2개 (minimax / openai) + 5가지 기성 코드 스니펫 (ElevenLabs / edge-tts / macOS say / Azure / Google)
references/RECORDING.md Phase 4에서 읽기 화면 녹화 도구 + 사후 합성
themes/ Checkpoint Plan / Phase 1.2에서 참고 내장 테마(각각 포함) theme.json + tokens.css)
scripts/scaffold.sh Phase 2.1에서 한 번 실행 원클릭 프로젝트 템플릿
GitHub에서 보기
---
name: web-video-presentation
description: Transform articles or scripts into click-driven 16:9 web presentations that look like videos, with optional AI voiceover synthesis.
---

# Web Video Presentation

把一篇文章或口播稿,一步步做成可录屏的"伪装成视频的网页",可选合成
口播音频。产出物 = Vite + React + TS 项目 + 按章节切分的音频。

## 适用场景

- "我有口播稿 / 一篇文章,帮我做成视频" —— 口播驱动的内容
- 想做 "动态 PPT"
- 16:9 横屏录屏,大字、留白、每屏都要有动效
- 教学 / 产品演示 / keynote 想要电影感
- B 站 / YouTube /抖音视频内容

本 Skill **以方法论 + 协作流程为核心**。脚手架模板提供 token 和原语,
但每个美学决策(配色、字型、动效气质)都应该针对你的主题重新设计 ——
不要照搬。

---

## 工作流总览

```
Phase 1   内容编写
   1.1  识别用户输入
   1.2  一次产出 script.md + outline.md
        (口播稿 + 开发计划)
   ▼
[Checkpoint Plan]      ← 必须停。一次对齐 5 件事:
                         稿子 / outline / 主题 / 素材 / 开发模式
   ▼
Phase 2   网页开发
   2.1  脚手架(按选定主题)
   2.2  第 1 章 = 主线程 + 完整版本(强制 anchor)
        ▼
        [硬节点] 用户验收第 1 章 ← 不可跳过
        ▼
   2.3  第 2~N 章(按选定模式:A 逐章 / B 顺序 / C 并行)
   ▼
[Checkpoint Audio]     ← 必须停。是否合成音频
   ▼
Phase 3   音频合成(可选)
   ▼
Phase 4   录屏 + 后期
```

工作目录约定(agent 在用户当前目录下创建 / 编辑):

```
my-video/
├── article.md          # 用户给原文时必有 —— 不删!开发阶段画面信息源
├── script.md           # 必有:保持原文语言的平台化口播稿(决定节拍)
├── outline.md          # 必有:开发计划(章节切分 + 每步内容 + 信息池)
└── presentation/       # 脚手架产出的 Vite + React + TS 项目
    ├── src/chapters/<NN>-<id>/
    │   ├── <Chapter>.tsx     # 视觉实现
    │   ├── <Chapter>.css
    │   └── narrations.ts     # ★ step 数 + 口播文本的唯一真相源
    ├── scripts/
    │   ├── extract-narrations.ts   # 扫所有 narrations.ts → audio-segments.json
    │   ├── synthesize-audio.sh     # provider-agnostic runner(循环 segments)
    │   └── tts-providers/          # 每 provider 一个 .sh(内置 2 个)
    │       ├── README.md           # 三函数契约 + 5 段现成代码片段(11labs / edge-tts / say / azure / gcloud)
    │       ├── minimax.sh          # 默认 provider,用 mmx-cli
    │       └── openai.sh           # 内置 OpenAI TTS(curl + OPENAI_API_KEY)
    ├── audio-segments.json         # extract 产出(合成前 review)
    └── public/audio/<id>/<N>.mp3   # 可选:合成的音频
```

> **关键**:`narrations.ts` 是 step 数和音频合成的**唯一真相源**。
> 章节 `.tsx` 里的 `if (step === N)` 出现的最大 N + 1 必须等于
> `narrations.length`。这保证 5 处地方(script / outline / 章节代码 /
> chapters.ts / 音频文件)永远不会漂。

---

## 硬性自检协议(贯穿整个 Skill)

下面三个产出,每一个**完成后必须走自检 → 修复 → 再汇报 / 推进**:

| 产出 | 自检清单出处 |
|---|---|
| `script.md` | [`SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md) 三层自检(形式 / 风骨 / 念出来) |
| `outline.md` | [`OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md) 自检 |
| 单章实现完成 | [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) 完工自检 |

**执行方式**(按能力降级,**优先用更隔离的方式**):

1. **Agent Teams(最优)**:开一个独立的 reviewer agent,给它"产出文件
   路径 + 对应清单 + 关键上下文",让它逐项核查并**严格汇报结论**
   (哪几条 pass / 哪几条 fail + 证据 + 改写建议)。
2. **subAgent(次优)**:没有 Teams 能力但能开 subagent 就用 subagent
   走同样流程。
3. **自检(兜底)**:当前 agent 都没有上述能力,就自己**严格逐项**
   核查 —— 不允许目测一遍就放行。

**铁律**:拿到结论后**先按 fail 项把产出改完**,再向用户汇报"做完了
+ 自检结论 + 改了什么"。**直接拿原始结论汇报但不修复 = 违规**。

---

## 各阶段文件读取指南

不同阶段读不同的文件。**长会话里 agent 容易遗忘原则**,特别是
Phase 2.4 的"实现单章"会重复 N 次 —— 每次都要回看核心约束。

| 阶段 | 必读(每次都看) | 一次性看完 / 按需查 |
|---|---|---|
| Phase 1.1-1.2 内容编写 | `references/SCRIPT-STYLE.md` + `references/OUTLINE-FORMAT.md` + `article.md`(用户原文,如有) | —— |
| **Checkpoint Plan 选主题** | —— | `themes/*/theme.json`(动态读全部,列清单 + `bestFor` 推荐 + `descriptionZh`);`references/THEMES.md`(用户想了解主题系统时) |
| Phase 2.1 脚手架 | —— | SKILL.md 本节看一次 |
| **Phase 2.4 实现单章(×N 次,被 2.2 / 2.3 调用)** | **`references/CHAPTER-CRAFT.md`** 单一入口 —— Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长参考 / Part 5 反 AI 味反模式 / Part 6 代码硬规则(**含 narrations.ts 强制约束**)/ Part 7 完工自检 / Part 8 反馈速查 + 当前主题的 `themes/<id>/theme.json` + 当前章节的 outline.md 段落 + **`article.md` 本章对应段落** + 素材清单 | `references/EXAMPLES/`(结构示意,不是抄袭模板);`references/THEMES.md` 完整 token 契约 |
| Phase 3 音频合成 | `references/AUDIO.md`(含 narrations.ts → segments.json → 任意 provider 流程,内置 minimax + openai) | `templates/scripts/tts-providers/README.md`(换 provider / 自带 TTS 时) |
| Phase 4 录屏 + 后期 | `references/RECORDING.md`(含 `?auto=1` 自动录屏) | —— |
| 选 / 造 / 切主题 | —— | `references/THEMES.md` |

> **写章节时只读一份 `CHAPTER-CRAFT.md`**。十条原则 / 开工 self-prompting /
> 决策树 / 反 AI 味反模式 / 完工自检全部并入这一份单一入口。`EXAMPLES/`
> **不是必读** —— 先按内容自由设计,卡壳才翻(按 anchor 翻"形",不要照搬)。

---

## Phase 1 —— 内容编写(一次产出)

### 1.1 识别用户输入

| 用户给的东西 | 该做的 |
|---|---|
| 原始文章(书面语 / 公众号 / 论文 / 博客) | 一次产出 `script.md` + `outline.md`(1.2),过 Checkpoint Plan |
| 直接的口播稿 / 视频脚本 | 落盘成 `script.md`,一次产出 `outline.md`(1.2 简化版),过 Checkpoint Plan |
| 啥都没有,只说"帮我做个 X 主题的视频" | **反问**:先给一段素材或大纲。Skill 不替用户构思内容 |

### 1.2 一次产出 script.md + outline.md

**两份产出物在一次思考中完成**:

1. **生成 `script.md`**:按 [`references/SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md)
   的规则把 article 转成保持原文语言的平台化口播稿。**保留 `article.md` 不删**——它是
   outline 写信息池和章节实现画面时的细节源(双源原则)。
2. **生成 `outline.md`**:按 [`references/OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md)
   规则切章节 + 切 step + 每章首段抽**信息池**。

**outline 的边界**(关键):

| outline 必须写 | outline 不要写 |
|---|---|
| 章节切分 / 每章 step 数 / 估时 | 具体动画类型(blur clear / wipe / 弹簧) |
| 每步屏幕内容(hero / 数据 / 标语 / 列表项) | CSS 实现手段(filter / SVG / clip-path) |
| 章节级**信息池**:从 article 抽的数字 / 引用 / 案例 / 标签 | 时长数值(不写 ~2.5s / 80~120ms) |
| 步级关系名前缀("反差对照" / "递进列表" / "金句" 等可选 hint) | 持续微动 / 错峰量等微观节奏 |

> **outline 不写动画的理由**:写死动画 = chapter agent 退化为翻译机;
> 留白让 chapter agent 在每步开工时按 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
> 的"内容驱动决策树"自由设计,才有真正的视频感。详见
> [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) Part 0 原则 7。

**落盘后必须先走自检再进 Checkpoint Plan**:按上文「硬性自检协议」分别
对 `script.md` / `outline.md` 执行(优先 Agent Teams → subAgent → 自检),
按结论修复完成后再进入 Checkpoint Plan。

---

## Checkpoint Plan —— 5 件事一次对齐(**硬节点**)

`script.md` + `outline.md` 写完后必须停下来。**用户在这一个节点同时确认
5 件事**。

### agent 此时要做的预备工作

1. 读所有 `themes/*/theme.json` 拿 `nameZh` / `descriptionZh` / `bestFor`
   / `mood` —— **不要硬编码清单**
2. 根据 `script.md` 的内容类型 / 关键词 / 语气,**主动**从主题里挑 2~3
   套**最匹配的推荐**(匹配 `bestFor` 字段)
3. 扫一遍 `outline.md` 末尾"素材清单"部分

### 总结模板(骨架,agent 按情况填充)

```
内容计划写完,产出文件:
  📄 article.md     {若用户给原文则保留}
  📄 script.md      {X} 字 / ~{T} 分钟
  📄 outline.md     {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单

章节速览:
  1. <id>     <章节标题>    <S> 步 ~<T>s
  2. ...

接下来一次对齐 5 件事:

  1. 稿子 (script.md) 要不要改?
     可以直接编辑文件,或口头告诉我修改方向。

  2. 开发计划 (outline.md) 要不要改?重点看:
     - 章节切分 / step 数 / 估时是否合理(合理判断:每章 30~60s)
     - 每步屏幕内容是否清晰
     - 每章首段「信息池」是否有足够的 article 细节供画面挂
     - 末尾素材清单是否完整

  3. 选哪个主题?我的推荐:
     ★ <推荐 1:nameZh (id)> — 因为 <bestFor 命中>;<descriptionZh 摘要>
     ★ <推荐 2 / 推荐 3>
     其它可选:<剩余主题,nameZh + 一句话>
     也可以让我帮你做新主题(详见 references/THEMES.md)。

  4. 真素材怎么准备?粗看本视频要的图:<列粗略清单>
     a) 我从 <现有素材路径> 帮你挑   b) 你自己提供   c) 全部 placeholder

  5. 开发模式选哪个?

     **第 1 章无论哪种模式都必须主线程做完 + 用户验收**(强制 anchor)。
     差异在第 2 章及之后:

     A) 默认 · 逐章确认(推荐)
        每章做完都暂停验收 → 风险可控 / 节奏最稳
     B) 第 1 章后顺序开发(不并行)
        第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
     C) 第 1 章后并行开发(subagent)
        第 2~N 章用 subagent 并行 → 最快 / 用户控并行数(一次几章)
        ⚠️ 风格各章会有差异(这是预期,主题禁区兜底)
```

收到反馈后:
- 稿子 / outline 要改:直接编辑文件,编辑完 ping 一次(或口头描述 agent 改)
- **主题必须明确**才进入 Phase 2。用户说"主题你帮我选" → 取你推荐的第 1 个,
  **告诉用户你选了什么、为什么**,给反悔机会
- 模式选定 → 进 Phase 2

---

## Phase 2 —— 网页开发

### 2.1 脚手架

```bash
bash <path-to-web-video-presentation>/scripts/scaffold.sh \
  ./presentation \
  --theme=<用户选的主题 id>

bash <path-to-web-video-presentation>/scripts/scaffold.sh --list-themes
```

> 自定义主题 → 先按 [`references/THEMES.md`](references/THEMES.md)
> "创作新主题"流程做一个 `themes/<my-theme>/`,再 `--theme=<my-theme>`。

脚手架带一个 `01-example` demo。在写第一章真实内容前**删掉**:

```bash
rm -rf presentation/src/chapters/01-example
```

并把 `presentation/src/registry/chapters.ts` 里 `EXAMPLE_CHAPTER`
的 import 和数组项移除。

### 2.2 第 1 章 —— 主线程 + 强制验收

**核心**:第 1 章 = 完整版本一次到位(节奏 + 视觉 + 真素材齐全)。
**没有"骨架版"概念** —— 第一章就要做出**用户能直接验收**的样板。

为什么第 1 章必须主线程:

- 它是 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) 这套指引在**当前
  主题 + 当前题材**下的第一次落地
- 如果指引有盲区 / 主题颜色 / 字体 token 不够用,第 1 章一定会暴露 ——
  这时候有人类反馈就能修指引 / 调主题,**早改成本最低**
- 后续章节(无论顺序 / 并行)都要参考第 1 章的代码模式,所以第 1 章 =
  当次项目的"风格锚点(不强求章节间一致,但单章自身得有完整说服力)"

**做完第 1 章后必须停下来**等用户验收:

```
第 1 章 <id> 做完了,dev server 在 localhost:5173 运行。

验收重点:
  □ 视觉气质对不对?符合 <theme nameZh> 的预期吗?
  □ 节奏对不对?某些步太快 / 太慢 / 信息太薄?
  □ 内容驱动动画是否到位?还是有几步是无脑入场动画?
  □ 双源原则:屏幕画面有没有"口播没念但 article 能挂"的细节?
  □ 反 AI 味检查:紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有?

问题告诉我,我针对性改。OK 了告诉我"继续",我按选定模式做第 2 章及之后。
```

### 2.3 第 2~N 章 —— 按选定模式

**所有模式下的共同规则**:每章独立按 [`CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
开发。**风格不强求章节间完全一致** —— 主题颜色 / 字体 token 兜底视觉
统一,动画 / 节奏 / 视觉演示由章节自由发挥是设计预期。

#### 模式 A · 默认 · 逐章确认

第 2 章做完 → 暂停验收 → OK → 第 3 章 → 暂停 → ... → 第 N 章。**每章
独立验收**,问题随时改,**风险最低,节奏最稳**。**用户不明确选模式时
默认走这个**。

#### 模式 B · 第 1 章后顺序开发

第 2 章 → 第 3 章 → ... → 第 N 章 **主线程顺序做完,最后统一验收**。
速度中等,适合 agent 不支持并行任务的环境。

#### 模式 C · 第 1 章后并行开发(subagent)

用 subagent 把第 2~N 章并行做完,最大并行数由用户控制("一次 4 章"
/ "一次 2 章")。**最快,但风格各章会有差异** —— 这是预期,因为:

1. 每个 subagent 看不到别的 subagent 产出,无法机械对齐
2. 章节代码物理分离(每章一个文件夹 / 自己的 CSS 前缀),不会互相
   破坏
3. 主题 token 兜底视觉统一(颜色 / 字体 / hero 数字 / 卡片 / 分割线
   性格 / 装饰),气质不会跑偏
4. **风格不一致 = 人手写视频的呼吸感**(多 voice / 多视角)

并行 subagent 的 prompt 必须包含:

- 当前章节 outline 段落(含信息池)
- `references/CHAPTER-CRAFT.md` 的路径(**单一必读** —— 视觉演示要求 +
  逐步揭示 + 双源原则 + 反 AI 味 + 代码红线 + 完工自检全部在这一份里)
- 当前主题 `theme.json` 的 `descriptionZh` / `mood` / `bestFor`(参考气质
  即可,动画 / 时长 / 字号 / emoji 由 chapter agent 自由决定)
- **第 1 章代码作为"代码风格"参考**(不是"视觉抄袭对象")
- 硬规则:每章独立 CSS 前缀(`.cd-` / `.mg-` / `.pm-` / ...);
  不修改 `chapters.ts`;完工跑 `npx tsc --noEmit`

**重要**:无论选哪种模式,**用户随时可以中途切换模式**。第 2 章 OK
后用户说"剩下的并行" / "剩下的逐章" 都行。

### 2.4 实现单章(每章必走)

详细指引见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) ——
**单一必读入口**,覆盖:视觉演示要求 / 逐步揭示 / 内容取舍 / 双源原则
/ 视频演示基本审美 / 反 AI 味 / 代码红线 / 完工自检。

**核心要点**(CHAPTER-CRAFT.md 详述):

- **每章必须有 CSS / SVG / Canvas / JS 视觉演示**,禁纯文字章节
- **逐步揭示**:清单 / 列表必须 1 项 = 1 step,禁一次全展示
- **双源原则**:节奏跟口播稿(顺序不能乱),细节回原文章抽(信息池 +
  本章 article 段落)
- **完工自检逐项过**,不达标回去改 —— 按上文「硬性自检协议」执行
  (优先 Agent Teams → subAgent → 自检),**改完再向用户汇报本章交付**

### 2.5 大改后 bump STORAGE_KEY

改动 `chapters.ts`(增加 / 删除 / 重排章节,或某章 `narrations.ts`
长度变化)后,**bump** `presentation/src/hooks/useStepper.ts` 的
`STORAGE_KEY`(如 `v4` → `v5`),避免持久化游标落到不存在的 step 上。

---

## Checkpoint Audio —— 是否合成音频(**硬节点**)

Phase 2 结束后必须停下来,问用户:

```
网页做完,{N} 章 {M} 步,dev server 在 localhost:5173 跑着。

要不要合成音频做"自动播放录屏"?
  ✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json,
           调 TTS provider 合成每步一个 mp3 到 public/audio/。
           合成完后用 ?auto=1 模式可以一镜到底录屏(音视频天然同步)。
           内置两个 provider:
             • minimax (mmx-cli)    —— 默认,中文音色稳
             • openai  (OPENAI_API_KEY) —— curl-based,多数已有 key
           其它后端 (ElevenLabs / edge-tts 免费 / macOS say 离线 /
           Azure / Google) 见 scripts/tts-providers/README.md 的现成片段。
  ✗ 不合成 → 跳过 Phase 3,直接 Phase 4 用手动录屏 + 后期配音。
```

要合成 → Phase 3。不合成 → 直接 Phase 4。

---

## Phase 3 —— 音频合成(可选)

详细流程见 [`references/AUDIO.md`](references/AUDIO.md)。简版:

```bash
cd presentation
npm run extract-narrations   # 扫所有 narrations.ts → audio-segments.json
# 让用户扫一眼 audio-segments.json 确认文本对
npm run synthesize-audio                       # 默认 minimax provider,增量
# 或用内置 openai (要 OPENAI_API_KEY):
PRESENTATION_TTS=openai npm run synthesize-audio
# 或自定义:写一个 scripts/tts-providers/<name>.sh,见该目录的 README.md
```

合成完告诉用户:输出位置 / 总段数 / 哪些段时长异常(太长 = 该 step 拆
分;太短 = 文案太薄)—— 给最后一次校准节奏的机会。然后进入 Phase 4。

---

## Phase 4 —— 录屏 + 后期

详见 [`references/RECORDING.md`](references/RECORDING.md)。两种路径:

| 场景 | 推荐路径 |
|---|---|
| Phase 3 已合成音频 | **Auto 模式一镜到底**:浏览器开 `localhost:5173/?auto=1` → 按 SPACE → 整片自动播完 → 停录 → 裁头尾即成片,**无需后期对音轨** |
| Phase 3 跳过 | 默认 Manual 模式手动点击推进 → 后期任意剪辑工具配音 |

> agent 在 Phase 3 / Checkpoint Audio 后**主动告诉用户**适合的录屏路径。

---

## 十条原则(一句话清单)

完整展开见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
Part 0 —— **写章节时回那里查**,下面只是索引。

| # | 原则 | 一句话 |
|---|---|---|
| 1 | 16:9 固定舞台 | 内容 1920×1080 + transform scale,没有响应式 |
| 2 | 全局 step 计数器 | 章节是 step 的纯函数,无定时器 |
| 3 | 每步独占整屏 | `if (step === N) return <FullScene />` |
| 4 | 口播节拍 = step | 一节拍 = 一 step = 一聚焦想法 |
| 5 | 隐藏的边角控件 | 进度条 / 翻页器默认 opacity 0 |
| 6 | 舞台无 chrome | 没有 header / footer / 页码 / 品牌条 |
| 7 | **内容驱动动画** | 先找内在动作,找不到才入场动画兜底;持续微动慎用 |
| 8 | 多点逐个揭示 | 1 项 = 1 step,禁同步 stagger 上 N 项 |
| 9 | 整片同一主题 | 章节间不翻表面色;**颜色 / 字体走 token**,其它尺度章节自由 |
| 10 | 双源原则 | script 定节拍,**article 定画面密度**(落到信息池) |

---

## 常见用户反馈速查

简化表见 [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md)
Part 8「常见反馈速查」。**关键**:先定位是哪一层(节奏 / 视觉 / 内容
/ 代码),再改最小切片,**不要重做整章**。

---

## 相关资源

按"何时读"标注,避免一次性全读:

| 文件 | 何时读 | 内容 |
|---|---|---|
| [`references/SCRIPT-STYLE.md`](references/SCRIPT-STYLE.md) | Phase 1.2 必读 | 文章 → 口播稿规则、平台变体 |
| [`references/OUTLINE-FORMAT.md`](references/OUTLINE-FORMAT.md) | Phase 1.2 必读 | outline.md 字段 spec、命名约定、章节切分、信息池 |
| [`references/CHAPTER-CRAFT.md`](references/CHAPTER-CRAFT.md) | **Phase 2.4 每章单一必读入口** | Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长 / Part 5 反 AI 味反模式 / Part 6 代码硬规则 / Part 7 完工自检 / Part 8 反馈速查 |
| [`references/EXAMPLES/`](references/EXAMPLES/) | **可选** —— 看结构 | 章节结构示意(hook / list-reveal / case-tech-review);**不是抄袭模板** |
| [`references/THEMES.md`](references/THEMES.md) | 选 / 造 / 切主题时 | 完整 token 契约 + 内置主题清单 + 创作流程 |
| [`references/AUDIO.md`](references/AUDIO.md) | Phase 3 才读 | provider-agnostic 音频合成流程、内置 minimax 用法、换 provider 路径、故障排查 |
| [`templates/scripts/tts-providers/README.md`](templates/scripts/tts-providers/README.md) | 换 / 加 TTS provider 时 | 三函数契约 + 内置 2 个 (minimax / openai) + 5 种现成代码片段(ElevenLabs / edge-tts / macOS say / Azure / Google) |
| [`references/RECORDING.md`](references/RECORDING.md) | Phase 4 才读 | 录屏工具 + 后期合成 |
| [`themes/`](themes) | Checkpoint Plan / Phase 1.2 时翻 | 内置主题(每个含 `theme.json` + `tokens.css`) |
| [`scripts/scaffold.sh`](scripts/scaffold.sh) | Phase 2.1 跑一次 | 一键项目脚手架 |

모든 파일

95개 파일

web-video-presentation 설치

스킬 파일을 다운로드하여 .claude/skills/ 디렉터리에 압축을 풀어주세요.

ZIP 다운로드

저장소를 클론하고 스킬 파일을 프로젝트에 복사하세요.

git clone https://github.com/ConardLi/garden-skills/tree/main/skills/web-video-presentation # Copy SKILL.md to your .claude/skills/ directory

복사 복사
빠른 설정: 스킬 폴더를 .claude/skills/로 복사하세요. Claude가 해당 스킬을 자동으로 감지하여 사용할 것입니다.

관련 스킬

github-code-search
업데이트 된 시간 2026년 6월 29일
drizzle-orm
업데이트 된 시간 2026년 6월 29일
prisma-client-api
업데이트 된 시간 2026년 6월 29일
clickhouse-io
업데이트 된 시간 2026년 6월 29일
OR