anthonytrance/video-editor-skill

影片編輯器

將一個資料夾中的片段變成一部完成的短影片。代理就是編輯：它決定故事並撰寫編輯計劃，而腳本則精確地執行機械部分，確保剪輯點打在節拍上、沒有任何素材被意外重複使用、也不會出現信箱黑邊。

如果存在 LOCAL.md，請先閱讀它：它記錄了此機器的 Python 環境、品牌檔案和媒體資料夾。內容所有者、品牌字體、標誌和預設外觀都儲存在品牌檔案 (~/.video-editor/brand.json，詳見 references/brand.md）中，絕不會放在腳本裡。

只需要修剪或簡單裁切的單一剪輯、單一剪輯加上字幕，以及發佈作業，都屬於該安裝實例的社交技能（對於 XNP 來說是 xnp-social）。此技能負責製作編輯成品；社交技能則負責審查、添加字幕、規劃和發佈。

沒有影片類型列表

每個請求都是一種混搭。不要尋找匹配的範本。相反地，根據簡報決定以下四件事，如果影片在中途改變了風格，則每個段落分別決定：

1. 主軸：決定節奏的因素。
   • 音樂：根據小節和節拍進行剪輯，選擇充滿能量的鏡頭，高潮出現在 Drop 處（len 使用 "2bar"、"1beat"）。
   • 對白：文字決定長度，畫面在短語結尾處切換，音樂壓低以讓出對白（audio_db 設定在有對白的鏡頭上，長度以秒為單位）。
   • 故事或時間順序：開場、鋪陳、高潮、餘韻；根據動作和場景變換進行剪輯，音樂作為背景。
   • 混合型：根據段落切換主軸：例如 6 秒的口白以對白為主軸，接著是演出素材以節拍為主軸；或者以時間順序為主的旅遊故事，中間穿插節拍剪輯的演出片段。
2. 目的地與設計。 影片要去哪裡（Reel、Story、輪播、動態消息、TikTok、Shorts、YouTube），以及如何使用那個空間：滿版、帶邊框的正方形或 4:5 的照片放在設計好的背景上，或是每個鏡頭切換這兩種方式。根據素材和目的來選擇，而不是習慣：如果裁成 9:16 會毀掉一個寬廣的畫面，那麼它可能需要一個帶邊框的 Reel、一個輪播或一段 16:9 的總結。閱讀 references/formats.md 了解每個平台如何處理畫面以及何種設計最合適。長度則根據目的地和素材內容而定。
3. 必須包含的項目。 必須出現且能被辨識的指定人物、一個標誌、一個日期、一句感謝詞、一個特定時刻、一行標題。只有在簡報真的未提及時才詢問。
4. 聲音層。 僅音樂；音樂加上偶爾出現的人群或環境音；對白加上背景音樂；僅對白。對白需要添加字幕（請見下方「字幕」章節）。

接著撰寫計劃，設定 "destination" 以遵循畫布大小、安全區域和長度限制。references/examples.md 展示了四個處理過的簡報範例（派對花絮 Reel、口白、口白接演出片段、旅遊故事），作為推理過程，而非可供複製的類型。references/craft.md 包含了適用於所有這些情況的剪輯規則。

工作流程

腳本位於 scripts/ 目錄下；使用 LOCAL.md 中指定的 Python 環境來執行，並設定 PYTHONUTF8=1 PYTHONIOENCODING=utf-8，同時確保 FFmpeg 和 ffprobe 在 PATH 環境變數中。在技能資料夾之外的專案資料夾中工作（包含 src/、audio/、log/、proxy/、out/、review/、edit.json）。

1. 簡報。 確認素材中的人物及其辨識方式、活動、目的以及上述的四項決定。將其寫入 brief.txt；Gemini 會讀取它。
2. 記錄素材。 gemini.py log WORKDIR src/*.mp4 --context brief.txt --ratio 9:16 會為每個剪輯寫入 log/NAME.json：包含時間點，記錄人物在哪裡（x 座標用於裁切的分數值）、動作、情緒、能量、聲音、對白、品質、9:16 的窗口是否能容納主題、最佳裁切中心點以及用途（開場、高潮、反應……）。每個剪輯約 1 美分。記錄是線索：在據此進行建構前，請根據畫面確認人臉、裁切中心和「最佳時刻」。
3. 檢視。 sheet.py 透過一次 FFmpeg 運行製作帶標籤的縮圖索引表：使用 --every 2 遍歷一個剪輯、--times 指定時間點、a.mp4@3 [email protected] 進行候選比較、--crop 9:16 --cx 0.4 查看來源將如何被構圖、--grid 10 用於規劃裁切。請親自檢視圖片；永遠不要要求內容所有者查看。
4. 規劃。 撰寫 edit.json（詳見 references/edit-format.md）。每個鏡頭都應指向不同的時間點；為每個鏡頭添加備註說明它為何存在。
5. 檢查。 validate.py edit.json（render.py 也會自動執行它，並在發現錯誤時拒絕渲染）。錯誤包括：同一段素材被使用兩次、來源片段太短、未知的運鏡、未經允許使用 fit 導致邊框、文字落在平台 UI 區域內、缺少檔案、音樂太短。警告包括：取自同一剪輯且間隔小於 2 秒的鏡頭、相似鏡頭、脫離節拍的剪輯點、已構圖的來源內部出現黑色邊緣、標誌靠近 UI 區域。請閱讀每個警告並做出決定；不要只是忽略它。
6. 草稿渲染。 render.py edit.json --out out/v1-draft.mp4 --draft（半尺寸，快速）。接著執行 sheet.py out/v1-draft.mp4 --plan edit.json --out review/v1.png 顯示每個鏡頭的開頭、中間和結尾：檢查構圖、人頭、文字位置以及每個鏡頭是否與備註相符。
7. 完整渲染。 render.py edit.json --out out/v1.mp4。慢速預設，處理 30 秒的 4K 來源素材約需 5 分鐘；render.py 接著會檢查大小、長度、聲音、每個鏡頭的黑邊、黑幀以及計劃中的 max_mb。
8. 評論。 gemini.py review out/v1.mp4 --context brief.txt --plan edit.json --out review/v1.json（不到 1 美分）。將每條評論視為一個說法：在更改任何內容之前，請根據畫面或計劃進行檢查。它可能會將正確的文字標記為「不安全」，或將正確的日期標記為「錯字」。它真正能發現的問題是重複的鏡頭、遮擋關鍵動作的手、出現在畫面內的手機、以及被誤認為是故障的閃爍。
9. 疊代。 使用新的版本號碼；永遠不要覆蓋已交付的檔案。為每個版本保留 edit.json（複製為 edit-v2.json），以便任何版本都能被重新渲染。
10. 交付。 按照 LOCAL.md 所說的方式交付，用文字描述編輯內容（逐個鏡頭、文字說明了什麼、音樂在哪裡達到高潮），然後將檔案交給社交技能進行審查、添加字幕和發佈。發佈永遠需要內容所有者的明確批准。

字幕

對白字幕是社交技能的工作：先渲染編輯成品，然後在其完成後的渲染檔案上執行它的字幕輔助工具（對於 XNP：xnp-social/scripts/captions.py transcribe），以便文字時間與編輯成品匹配，接著執行其強制性的批准步驟，最後燒錄字幕。如果最終時間軸上已經存在一個已批准的 .srt 或 .ass 檔案，計劃中的 captions.file 則會在渲染期間直接燒錄它，而不是走上述流程。

誠實的限制

相似鏡頭檢查是基於圖片哈希值和平均顏色：它能捕捉到同一時刻使用兩次，但無法捕捉到不同時刻中「從相同角度拍攝同一人物」的情況。這種語義檢查來自 Gemini 的記錄和評論，以及透過閱讀縮圖索引表來進行。沒有自動的節拍偵測：請提供 BPM 和一個在重拍上的起點（music.start），這樣時間格就會很精確。沒有人臉追蹤：平移和裁切中心點來自記錄和縮圖索引表。Gemini 的時間碼在長片段上可能會出現漂移；代理檔案上會燒錄一個時間碼以確保其準確性，並且 log 在時間點超過片段長度時會發出警告。

檔案

scripts/common.py 計劃載入、時間計算、探測、品牌、調色。 scripts/render.py 單次遍歷渲染器。 scripts/validate.py 檢查器。 scripts/sheet.py 縮圖索引表。 scripts/gemini.py 記錄和評論。參考資料：formats.md、edit-format.md、craft.md、examples.md、brand.md。