一般影片
在依賴此工作流程之前，請先執行：
npx hyperframes skills update general-video
成功執行且無任何輸出（no-op）表示技能為最新版本。若更新失敗，請顯示錯誤訊息，不要直接從記憶體繼續。
1. 套用跨領域的來源適配器
- 媒體： 如有任何音訊、圖片、圖示、標誌、語音、調色、LUT、效果/處理、字幕或媒體操作需求，請載入
/media-use並依循../media-use/references/resolve.md（解析、採用、重用）和../media-use/references/setup-providers.md（提供者、認證）的指示。對於模糊的素材反饋和具名樣式，請在編輯前使用../media-use/references/media-treatments.md；不要自行以 CSS/SVG/透明度來實作支援的媒體效果。在執行第一個需要認證的提供者動作前，請執行npx hyperframes auth status並逐字輸出其結果。如果顯示為登出狀態，則套用../hyperframes-core/references/brief-contract.md中的閘門：協作模式會等待登入或明確選擇離線；自動模式則會陳述狀態並透過可用的離線提供者繼續執行。當沒有離線提供者能滿足所需功能時，請回報阻礙。僅在本機採用（local adoption）不需要認證閘門。 - Figma： 如果任何輸入是
figma.com的 URL，請先執行/figma。從其匯出的資產、設計 Token、元件或分鏡畫格進行建構。請勿直接使用原始的 Figma 連接器呼叫，因為它們會跳過 SVG 清理、媒體來源追蹤和品牌 Token 綁定。
這些適配器不會改變 /hyperframes 所選取的工作流程。
2. 從專案狀態開始
套用第一個符合的列，不要評估較低層級的狀態列：
| 狀態 | 動作 |
|---|---|
| 特定編輯 | 執行編輯，保留現有的專案決策，然後重新執行受影響的檢查。不要重新開始探索階段。 |
BRIEF.md 存在 | 讀取它。如果 workflow 指定了另一個工作流程且 flow 不是 companion，則移交。不要問任何摘要問題。 |
無摘要，但存在 hyperframes.json 或 STORYBOARD.md | 從檔案和記錄的偏好設定繼續。僅從已知事實回填 BRIEF.md。 |
| 全新創作 | 執行 /hyperframes 及其意圖層。僅在 workflow: general-video 或 flow: companion 時返回此處。 |
對於新專案，請從摘要中選擇一個 kebab-case 的目錄名稱，並在撰寫摘要前先進行初始化：
npx hyperframes init "videos/<project>" --non-interactive --example=blank --skill=general-video
然後在專案根目錄下使用 ../hyperframes-core/references/brief-format.md 撰寫 BRIEF.md。在現有專案中，根目錄是包含 hyperframes.json 的目錄。僅記錄摘要格式指定的、已確認的偏好支援欄位，使用 node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJECT_ROOT>；永遠不要記錄推斷的預設值。此處 <MEDIA_DIR> 是已安裝的 /media-use 技能目錄，<PROJECT_ROOT> 是包含 hyperframes.json 的目錄。如果意圖層採用了某個配方，請立即使用 node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes <PROJECT_ROOT> --name <name> 套用它，且不要再次詢問。
3. 解讀執行形狀
僅使用 ../hyperframes-core/references/brief-contract.md 中的規範術語：
| 欄位 | 意義 | 影響 |
|---|---|---|
flow | 誰來主導 | automation：選擇並執行路線。companion：在對話中共同創作。 |
| `storyboard`` | 分鏡是否是審查表面 | yes：執行規劃與草稿審查。no：不透過分鏡板直接建構。 |
衍生的 mode | 檢查點閘門的行為 | 遵循簡報合約。永遠不要要求使用者命名模式。 |
不要為這些狀態發明同義詞。持續的「直接建構」訊號由意圖層處理，並以 flow: automation, storyboard: no 的形式到達。
- 對於
flow: automation，選擇路線並在第一個進度更新的第一行中說明。 - 對於特定編輯，進行編輯，不要發明新的路線。
協作流程
當 flow: companion 時：
- 讀取
BRIEF.md，並將已接受的## Assets和## Customizations與專案成品進行對照。完成仍然待辦的已接受工作；已完成的工作則保留原狀；不要將已接受的功能再次當作新功能提供。 - 以導演而非承包商的身份到來。 選擇協作模式的使用者選擇了參與和品質；誠實的回應是你所能設計的最佳版本，而不是你能辯護的最小版本。第一個計畫是天花板級別的處理方案：故事弧線（借用最近的類型鏡頭——選單 § 類型鏡頭）、設計規格、每個場景的動作處理名稱（§ 5 的規劃紀律）、轉場、音訊識別——音樂和聲音標記，或刻意的靜默——使用者的素材安置，以及設計過的開場和結尾。用一行話說明每個層次增加了什麼；在提及時標記出成本高昂的項目（渲染時間、登入、計費）。使用者向下修剪處理方案；他們永遠不應該逐項批准地拼湊出一個方案。
- 天花板屬於概念，而非工具箱。 每個層次都必須服務於摘要的訊息——一個會以同樣方式裝扮任何影片的處理方案只是裝飾。工藝要達到天花板；內容永遠不能超出被要求的範圍（§ 6）。
- 在檢查點之間，
../hyperframes/references/capability-menu.md有兩種運作方式。作為觸發列表：當使用者提及某個功能的輸入或建構進展到需要該功能時，提供相關的能力。作為每次迭代的升級通道：一個規劃、草稿或建構檢查點可以攜帶一兩個追蹤的提議，指向使用者正在查看的素材（「場景3的統計數字想要計數效果」）。在提供之前先讀取它；永遠不要傾倒整個目錄。 - 在使用者接受某個功能後，立即產生其成品，並在匹配的
BRIEF.md內容章節中記錄該決策。僅在使用者明確更改時，才重寫 frontmatter 欄位並記錄已確認的偏好。 - 保留相同的分鏡、驗證、最終預覽和渲染審批閘門。協作模式改變的是誰來掌舵，而不是品質需要什麼。
4. 在每個階段前載入所需知識
當條件匹配時，這些讀取是強制性的：
| 條件 | 在執行前讀取 |
|---|---|
| 任何合成 HTML 或場景佈局 | /hyperframes-core；使用 references/determinism-rules.md 了解其佈局合約 |
| 任何非平凡的創作或視覺處理 | /hyperframes-creative → references/house-style.md 和 references/video-composition.md |
| 任何動態、動畫或場景轉場 | /hyperframes-animation；依其路由找到匹配的規則、適配器、藍圖或轉場參考 |
storyboard: yes | ../hyperframes-core/references/storyboard-format.md 和 ../hyperframes-core/references/review-loop.md |
| 任何媒體資產或操作，包括旁白、背景音樂、音效、字幕、調色或變換 | /media-use；有關框架播放和放置，也需讀取 /hyperframes-core → references/variables-and-media.md |
| 多場景組裝 | ../hyperframes-core/references/production-loop.md |
flow: companion，在第一次規劃之前 | /hyperframes-creative → references/story-spine.md 和 references/house-style.md；最近的類型鏡頭以及完整的 ../hyperframes/references/capability-menu.md——天花板級處理方案是從這些設計出來的，而不是回憶出來的 |
| 協作功能提供、捕捉、節奏網格、生成式影片、地圖、發布或跨工作流程功能 | ../hyperframes/references/capability-menu.md; |
| 存在設計規格，在最終批准前 | /hyperframes-creative → references/design-adherence.md |
不要用記憶來取代這些讀取。只有在實際載入匹配的參考時，漸進式揭露才能節省上下文。
5. 執行合成
使用此依賴順序。僅在其輸入不存在時跳過某個階段。
-
規劃。 陳述觀眾弧線、結構、節奏和持續時間驅動因素。短篇單一場景使用一個檔案；三個或以上的硬場景切換或任何重複使用的場景使用子合成。閱讀
/hyperframes-creative→references/story-spine.md了解有旁白的弧線，references/beat-direction.md了解節奏，/hyperframes-core→references/composition-patterns.md了解結構。對於開放式多場景摘要，透過/hyperframes-creative→references/prompt-expansion.md展開提示。多場景規劃會引用每個場景的形狀：來自/hyperframes-animation→blueprints-index.md的藍圖 ID（當有適合的藍圖時），或者當沒有適合的藍圖時，引用其組合的具名規則（來自rules-index.md）——動畫名稱來自這些索引，絕不自行發明。故事的真實性決定哪些場景存在；引用只是裝飾它們。多場景規劃也會被記錄為分派成品：STORYBOARD.md中每個場景一個## Frame N區塊——status: outline，宣告的src:，藍圖/規則引用，以及節拍文字——即使storyboard: no也是如此。該區塊是分派單元；分鏡板只是審查表面。 -
在要求時審查規劃。 對於
storyboard: yes，對這些區塊執行共享的審查循環。對於storyboard: no，在不開啟分鏡板的情況下繼續。無論如何，當規劃暫停發生時，將子代理委派授權（第4步分派所需的）摺疊到該暫停中，而不是稍後再次停止。 -
解析依賴。 在平行工作前安裝註冊表區塊。暫存使用者資產，採用現有媒體，僅解析摘要要求的內容。當音訊的時間點驅動持續時間時，及早開始處理音訊。
-
建構場景。 對於短篇單一場景作品，在添加動畫之前，先在場景最顯著的時刻實作它（當存在已確認的線框時，該線框就是那個最終狀態，且不得重繪），然後根據其引用的藍圖或規則進行動畫——在撰寫動畫程式碼之前，請閱讀完整的配方本體（
/hyperframes-animation→blueprints/<id>.md,rules/<id>.md）。分派只有在規模足夠大時才有價值。 撰寫資料包和喚醒新的工作單元上下文會花費數分鐘和 Token：一部約6個短場景的影片，在此上下文中，逐個場景建構會更快（實測：5個短場景約9分鐘逐個建構 vs 約21分鐘分封處理）。只有當規劃超出此範圍——更多場景，或個別場景很重——時才進行分派，然後給每個工作單元 2–3 個場景，而不是一個，並在單一波次中產生所有工作單元（第二波次會使時間窗口幾乎加倍）。進行分派時：
node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md"建構器會為每個場景在
.hyperframes/frame-packets/下寫入一個有界限的資料包（該場景確切的分鏡區塊 + 藍圖本體 + 每個引用的規則配方，內聯）和_role.md（../hyperframes-core/references/frame-worker-role.md中的角色提示）。建構完所有場景後，它們必須使用../hyperframes-core/references/production-loop.md中的組裝參考進行合併。 -
自動操作。 你的最後一次編輯可能是跨場景的。調整佈局、持續時間、音訊階層、層級順序或橋接場景。不要進行超出範圍的敘事或視覺變更。
-
最終檢查與產出。 執行 /check，根據最終驗證規則進行驗證，在
/output/中產生一個最終的單頁 HTML 檔案，並提示進行渲染審批。如果存在設計規格，則在最終批准前執行design-adherence。對於storyboard: yes，在最終批准前也使用../hyperframes-core/references/review-loop.md運行最終審查。
6. 工作流程守則
這些是超越階段的、跨領域的規則：
- 媒體即證明。 在編輯者解決並採用之前，使用者提供的資產不被視為屬於專案。不要對未解析的檔案路徑進行僅 CSS 的降級處理；列出遺失的資產作為檢查結果。
- 一次定義，處處引用。 不要複製定義；建立一個單一來源的檔案（例如，從使用者素材清單生成的調色盤 CSS，或外部品牌指南）。在合成腳本中匯入該檔案。
- 不要對使用者說不而讓他們自己去做。 使用者通常不知道界限在哪裡。如果需求的意圖合理但超出了你的能力範圍，請陳述：「我可以（做 X、Y、Z）來回應那個意圖。我無法直接做（Q），但（這個替代方案）覆蓋了相同的目標。要繼續嗎？」使用
/media-use中記錄的媒體處理；不要發明替代方案。 - 版本 1 是一個選擇。 從摘要中生成一個完整的、一致的版本作爲第一個版本。在預覽前不要要求迭代方向。使用者可以在之後要求編輯。
- 渲染空間是無限的；上下文視窗不是。 對於 6-8 個場景，使用數據包分派（第 5 步）。如果動畫和轉場密集，使用 blueprints/defaults.yaml 來控制預設值。當你在單一上下文中的 Token 使用量接近極限時，明確說明：「為了最佳品質，我將剩餘的場景分包給專業單元。」然後產生數據包。
- 保持安全第一。 如果使用者的請求可能會中斷長時間運行的渲染、花費大量 API 成本或創建無法恢復的狀態，請在執行前警告。這不是質疑——這是預警。如果使用者確認，則繼續。
- 驗證完整性。 當工作完成時，徹底檢查。瀏覽輸出內容、檢查控制台錯誤、確認互動作品可操作。不要製造需要送回的漏洞。
- 精確溝通。 使用精確的渲染持續時間、檔案大小和限制。不要說「約30分鐘」而實際上是45分鐘。說「30-45分鐘渲染時間」或「取決於輸出解析度」。
- 輸入分派。 框架分派需要一個目標
STORYBOARD.md。如果規劃在其到達時沒有記錄場景區塊（例如來自意圖層），請將它們添加回去。將scenes陣列的長度回報給框架。 - 路徑紀律。 永遠不要在腳本路徑中使用波浪號
~。從hyperframes.json或明確的環境變數中解析完整路徑。 - 我們是出版者，不僅是作者。 除非要求，否則不要重複使用他人的背景音樂曲目。對你的敘事負責任。在輸出中嵌入正確的後設資料。對於語言、地理或文化敏感的內容，查閱
/hyperframes-creative/references/inclusivity.md。