設計交接
文案已核准。設計師或線框生成器需要的不是文字本身，而是每個文字區塊對讀者應產生的作用、順序，以及在手機上哪些部分必須保留。此技能將前者轉化為後者，且不會決定文案已決定的任何事項。
閘門：已核准文案，以及每個區塊的區塊規格
兩個輸入。第二個經常被忽略。
已核准文案，而非草稿。 圍繞仍在爭論的段落建構的佈局需要重建，且重建後的成果往往更差，因為它是在為不同文字所選的形狀上打補丁。若文案仍在變動，請停止並說明原因。
每個區塊的區塊規格。 ../conversion-page-build/SKILL.md 會在產生文案時一併產出區塊規格（位於 ## 區塊規格 標題下）。此技能只會讀取其中的五個關鍵名稱：section_type、purpose、content_hierarchy、components、responsive_intent。該檔案擁有規格的形狀，以及為何在文案之後而非之前撰寫的理由。
若文案送達時沒有規格，仍可進行交接——先從文案撰寫規格，並在輸出中標記為推測而來。從已完成文案逆向推導的規格僅記錄文案表現出來的作用，與其設計作用可能不同。當兩者不一致時，設計師將忠實地佈局錯誤的意圖，而下游流程無法察覺。
流程
四個步驟。前三個步驟總是執行。第四個通常不會。
- 將每個區塊規格對應到元件——
references/section-to-component.md。將五個關鍵轉換為每個區塊的元件清單，以及該區塊限制佈局的一個關鍵事項。 - 撰寫線框簡報——
references/relume-brief.md。頁面層級的框架，然後每個區塊一個區塊：結構與內容功能，不含外觀。 - 撰寫細化規格——
references/figma-refinement-spec.md。視覺層級、強調重點、折頁以上優先順序與掃描路徑：線框未確定的四件事。 - 平台註記（可選）——見下方。
步驟 2 和 3 刻意保持為獨立文件，且順序固定。原因在 references/figma-refinement-spec.md 開頭說明，此處不再重複。
平台檢查僅在平台已命名時執行
除非建置目標已指定且為 WordPress，否則不要開啟 references/platform-notes-wordpress.md。 Webflow 建置、Framer 建置、手寫程式碼建置與未指定建置均不會載入此處任何內容。
這並非檔案整理的潔癖。平台註記描述的是某個平台上為真、另一個平台上為假的限制，因此帶有不適用限制的規格會讓設計師解決不存在的問題，然後在有人質疑時為該解決方案辯護。錯誤的註記比完全沒有註記更糟。
若目標尚未指定，請詢問。若答案是「尚未決定」，請撰寫無平台的交接文件，並在輸出中記錄平台檢查尚未執行，以便後續接手建置的人知道有項目待處理，而非假設檢查已通過。
每個平台檔案都有相同的結構，且無其他內容： 每個行為一個註記，每個註記說明三件事——平台行為、該行為導致的失敗，以及避免失敗的用語。沒有對應檔案在此技能中的平台則不產生註記；切勿將 WordPress 的註記作為預設值，這正是條件檢查旨在避免的特定錯誤。
工具名稱僅為標識，而非方法
兩個參考檔案以工具命名——references/relume-brief.md 和 references/figma-refinement-spec.md——因為這是人們要求的名稱。兩者都不依賴於工具本身，且兩者均不聲明任何工具會如何處理接收到的內容。
此限制是刻意的。聲明「工具 X 接受如此形狀的描述」的技能是在對他人產品做出陳述，而這類陳述會悄然過時，讀者無法分辨當前陳述與兩年前的陳述。因此，這些檔案僅描述文件的內容及其形狀的原因。若確有對工具進行查驗，檔案會附上查驗日期，且不會超出查驗範圍。
社論語氣只在一個地方影響設計
社論語氣繼承自轉換簡報，此處不再重新決定；其背後理由屬於 ../audience-research/SKILL.md。五個社論語氣輪廓檔案位於 ../audience-research/references/register-profiles.md。
它影響此技能中的一個決策：頁面允許花費多少強調重點。 此處其他所有內容都是結構性的，且保持不變——同一個區塊對任何讀者都必須產生相同作用。references/figma-refinement-spec.md 包含這個唯一的交集，也是此技能中唯一讀取社論語氣列的檔案。
此技能不做的事
- 不重寫文案。 若一個區塊因文案從未說明其用途而無法佈局，問題在於措辭時呼叫
../copy-sweeps/SKILL.md，問題在於缺少論據時呼叫../conversion-page-build/SKILL.md。請明確指出哪一個，並停止。 - 不選擇視覺風格。 無色板、無字級、無間距值、無斷點數字。僅設定層級與關係；設計系統提供具體數值。
references/figma-refinement-spec.md完整說明了拒絕的理由，以及當沒有設計系統可用時的處理方式。 - 絕不從已上線的頁面開始工作。 此技能向前運作，從已核准文案到尚未建置的佈局。判斷現有佈局是反向流程，需要此技能不具備的證據——請使用
../conversion-page-audit/SKILL.md。 - 不建置。 平台註記的存在是為了確保規格不會要求建置目標無法低成本實現的功能。它們並非建置說明，也不會使此技能成為建置技能。
未解決項目
任何交接無法從文案和簡報中確定的項目，都應在文件中寫成 未確定 —— <可解決此問題的條件> ，而非猜測。此原則及其理由在 ../audience-research/SKILL.md 中為整個外掛說明一次，此處直接套用。最常見的兩種情況為：佈局依賴但尚未產生的素材，以及文案承諾但不存在的事實證明元素。
產出內容
一份交接文件。在此儲存庫的歸檔規則下，它會放置於 03 專案/<專案>/<頁面>/[C] 設計交接 — <頁面>.md；其他位置則放置於專案存放規格的地方。它按順序包含：每個區塊的元件映射表、線框簡報、細化規格，以及（僅在平台已指定時）適用的平台註記。
請說明歸檔位置，並說明平台檢查是否已執行。未提及平台的交接文件會被解讀為平台已檢查過。