外掛安裝： 在執行設定或更新命令之前，如果此技能位於 HyperFrames 外掛內部，請遵循外掛執行規則。獨立安裝則保留下方的更新說明。
通用影片
在工作流程開始時執行 npx hyperframes usage --json，除非剛讀取過，然後在關鍵里程碑（如草稿完成後和渲染前）再次檢查。讀取可用的時間視窗和重置時間。如果使用量未知，請直接說明而不猜測配額；保持與使用者討論範圍和工作流程選擇。
在依賴此工作流程之前，執行：
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.comURL，請先執行/figma。從其匯出的素材、權杖、元件或故事板影格進行建構。不要使用原始的 Figma 連接器呼叫，因為它們會跳過 SVG 清理、媒體來源追蹤和品牌權杖綁定。
這些適配器不會變更由 /hyperframes 選擇的工作流程。
2. 從專案狀態開始
套用第一個符合的列；不要評估較低層級的狀態列：
| 狀態 | 動作 |
|---|---|
| 特定編輯 | 進行編輯，保留現有專案決策，然後重新執行受影響的檢查。不要重新開啟探索。 |
BRIEF.md 存在 | 讀取它。如果 workflow 指定了另一個工作流程且 flow 不是 companion，則移交。不要詢問任何簡要問題。 |
無簡要，但 hyperframes.json 或 STORYBOARD.md 存在 | 從檔案和記錄的偏好繼續。僅從已知事實回填 BRIEF.md。 |
| 全新創作 | 執行 /hyperframes 及其意圖層。僅在 workflow: general-video 或 flow: companion 時返回此處。 |
對於新專案，從簡要中選擇一個 kebab-case 目錄名稱，並在撰寫簡要前建立 scaffold：
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 設定編排的放置/順序。每個影片片段保留其聲音：聲音保留在剪輯上（data-has-audio="true"），因此剪下影片也會剪下其聲音。/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 |
| 任何媒體素材或操作，包括旁白、背景音樂、音效、字幕、調色或轉換 | /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 scanlines"、"glitch"、"film grain"、"shimmer sweep"、"confetti burst" — 執行npx hyperframes catalog --query "<外觀，用通俗英文>" --json並在計劃命名如何建構該外觀之前讀取前幾個結果。此搜尋不需要任何安裝：無需專案、無需先前的add、無需帳戶。它從任何目錄對整個託管註冊表（約 400 個區塊和元件）進行排名，因此它也適用於使用者在建構過程中要求的外觀。計劃命名的區塊在階段 3 安裝；僅在搜尋後沒有任何合適的結果時，才手動創作一個外觀。多場景計劃也記錄為分派工件：STORYBOARD.md中每個場景一個## Frame N區塊 —status: outline、一個宣告的src:、藍圖/規則引用、一個