外掛安裝： 在執行設定或更新命令之前，請遵循 外掛執行規則（當此技能位於 HyperFrames 外掛內時）。獨立安裝則保留下方的更新指示。
通用影片
在依賴此工作流程之前，請執行：
npx hyperframes skills update general-video
成功的無操作表示該技能已是最新。如果發生更新失敗，請顯示失敗訊息，而非依賴記憶中的內容繼續執行。
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/references/brief-contract.md中的閘門：協作模式等待登入或明確的離線選擇；自主模式則陳述狀態，並透過可用的離線供應商繼續執行。當沒有離線供應商能滿足必要功能時，請顯示為阻礙因素。僅本機採用不要求驗證閘門。 - Figma： 如果任何輸入是
figma.com網址，請先執行/figma。根據其匯出的資產、令牌、元件或分鏡板影格進行建構。請勿使用原始的 Figma 連接器呼叫，因為它們會跳過 SVG 清理、媒體來源追蹤和品牌令牌綁定。
這些適配器不會變更由 /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/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/references/brief-contract.md 中的規範術語：
| 欄位 | 意義 | 效果 |
|---|---|---|
flow | 誰主導 | automation：選擇並執行路線。companion：在對話中共同創作。 |
storyboard | 在建構前規劃、草擬和審查 | yes：執行規劃和草稿審查（storyboard.html）。no：直接建構，不經此流程。 |
衍生 mode | 檢查點閘門的行為模式 | 遵循簡報合約。切勿要求使用者命名模式。 |
請勿為這些狀態發明同義詞。持續的「直接建構」訊號由意圖層處理，並以 flow: automation、storyboard: no 的形式送達。
- 對於
flow: automation，選擇路線並在第一次進度更新中用一行說明。 - 對於特定編輯，直接進行編輯，無需發明新路線。
對於現有素材的硬切、修剪、拼接或重新排序，將相同的影片原始檔複製到多個片段元素中。在每個副本上，使用 data-media-start 和 data-duration 設定來源範圍，然後使用 data-start 設定創作者指定的位置/順序。分開創作的音訊在匹配的 <audio> 元素上遵循相同的片段範圍和時間。/hyperframes-core 擁有此時間編輯權；僅在需要視覺屬性動畫（如縮放、推進、平移、裁切、遮罩或內部包裝器上的 clip-path）時，才使用 /hyperframes-keyframes。
從 ../hyperframes-core/references/creator-editing-recipes.md 複製完整的合約。
協作流程
當 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/references/storyboard-format.md 和 ../hyperframes/references/review-loop.md |
| 任何媒體資產或操作，包括旁白、BGM、音效、字幕、調色或變換 | /media-use；對於框架播放和放置，也需讀取 /hyperframes-core → references/variables-and-media.md |
| 多場景組合 | ../hyperframes/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組合的命名規則——動作名稱來自這些索引，而非發明。故事的真實性決定哪些場景存在；引用是對其進行修飾。在你自己規劃建構任何命名的視覺效果之前，請先搜尋即時目錄：對於簡報中提到的每個外觀、效果、處理或轉場——「CRT 掃描線」、「故障」、「底片顆粒」、「閃爍掃過」、「五彩紙屑爆炸」——請執行npx hyperframes catalog --query "<該外觀，用一般英文>" --json並在規劃說明如何建構該外觀之前閱讀前幾個結果。此搜尋無需安裝任何東西：無需專案、無需事先add、無需帳號。它會從任何目錄對整個託管註冊表（約 400 個區塊和元件）進行排名，因此同樣適用於使用者在建構過程中要求的外觀。規劃中命名的區塊將在階段 3 安裝；僅在搜尋後找不到任何合適的內容時，才手動建構外觀。多場景規劃也會記錄為調度成品：STORYBOARD.md中每個場景一個## Frame N區塊——status: outline、一個宣告的src:、藍圖/規則引用以及節奏文字——即使當storyboard: no時也是如此。該區塊是調度單位；分鏡板工作表僅是審查介面。 - 在要求時審查規劃。 對於
storyboard: yes，對這些區塊執行共享審查循環。對於storyboard: no，繼續進行，無需規劃暫停或草稿工作表。當規劃暫停發生時
…
[已截斷以利翻譯]