KaigorodovTuskul/editorial-design-agent-skill

編輯設計 — 原創藝術指導，非範本填寫

不可協商的目標

創作出具有凝聚力、獨特性、針對內容的出版物，展現專業藝術指導工作室的編輯野心。模型是藝術總監。不要將設計簡化為從九種預定義投影片類型中選取一種。 原始的 build <json> 路徑是一個舊版回歸測試工具，非建議的生成策略。

你必須實際撰寫並修改真實的 HTML/CSS/SVG，在 Chromium 中渲染，檢視輸出，修正問題，並驗證成品。單靠技能、品牌設定檔或 lint 腳本無法取代原創視覺方向或檢查渲染後的頁面。Hallmark 是專業發佈的必要條件，但它不是發佈引擎，也不能取代此技能。

0. 新互動專案的開始 — 主題與字型

在一個新的互動專案開始時，僅詢問一次調色盤與字型，並提供一個簡單回應：使用預設值。預設調色盤為 Crystal Cobalt Enterprise — 一種以參考為基礎的設計方向，包含鈷藍/近似黑色、節制的青/紫羅蘭光、淺色分析表面、原創稜鏡玻璃藝術品，以及四種藝術指導模式。預設字型為 Geologica Roman (CRSV=0)。替代方案：Azure Iris Unified、Arctic Editorial、Deep Navy、Monochrome；以及 Geist Sans、IBM Plex Sans、Onest、Manrope。品牌限制優先。如果對話中已建立調色盤/字型，則繼承之，無需再次詢問。無頭建置使用預設值，並以推斷選擇的標記持久儲存。

使用實際的製作指示，而非僅描述性的形容詞： 對於 Crystal Cobalt，請閱讀 references/styles/crystal-cobalt-enterprise.md、references/quality/crystal-cobalt-hallmark.md 以及 seeds/crystal-cobalt/README.md。所有原創可重複使用的藝術品位於 seeds/crystal-cobalt/ 下；切勿嵌入 AEB 的標誌、旭日紋或其特定的原創玻璃環。將附帶的參考作為風格靈感，並創建新的形狀、構圖與原創標記。

使用 node bin/editorial.mjs seeds crystal-cobalt-enterprise 列出素材，或使用 node bin/editorial.mjs seed <project-dir> --theme crystal-cobalt-enterprise 將種子素材複製到專案的 assets/seeds/crystal-cobalt/ 中。建置管線也會自動包含所選主題的種子素材。不要將投影片扁平化為點陣圖： 為混合 PPTX 維持靜態底圖上方的 HTML 可編輯文字欄位。

字型未隨附。發佈前，請確認瀏覽器與 PPTX 渲染器中已精確安裝匹配的字型；除非獲得核准並附有重新生成的比對證據，否則字型替代會阻止發佈。

1. 內容即設計輸入

閱讀實際來源（使用者參考 PDF、核准的文案、XLSX 財務模型、表格、照片與品牌工具包）。不要虛構事實數據、標誌或公司事實。對於試算表財務模型，請注意 openpyxl 不會重新計算公式。將示範值標記為未驗證。設計可以重組和精煉散文，但不得改變數值含義、單位、日期、警告事項、分母、正負號或來源出處。

在編碼前，請在內部繪製文件的敘事節奏，例如開場論點 → 負面基線 → 戰略轉折 → 驅動因素 → 情境 → 橋接 → 決策。為出版物創建一個獨特的視覺概念：字型層級、間距邏輯、圖表標記、安靜/動態節奏，以及一兩個基於內容的標誌性主題。除非被要求，否則不要逐字借用來源參考的調色盤或網格。重複使用其編輯野心，而非其像素。

2. 藝術指導規則（有紀律的自由）

• 將原創版面撰寫為 HTML。 允許自由形式的網格、CSS 定位、CSS 形狀以及作者設計的 SVG。沒有固定的投影片結構，也沒有每頁強制的範本系列。
• 構圖跟隨主張。 一行論點可以佔據半頁。一個數字可以是巨大的。財務橋接圖必須保留量化意義。不要將所有內容塞入 KPI 卡片，不要逐頁使用相同的網格，也不要不加區別地填充空白。
• 一個視覺世界，多種構圖。建立不對稱/安靜/密集、明亮/黑暗、文字主導/數據主導的節奏交替。避免連續相同的輪廓。
• 創意野心是必需的，而非僅被容忍。 在有用時，使用引人注目的不對稱、表現力豐富的字型、自訂 SVG 構圖、分層形狀、受控漸層、技術插圖、圖示和微妙的紋理效果。使視覺豐富度有目的性且針對內容；不要將每張投影片變成相同的波紋漸層主視覺。如果一個頁面雖然機械上有效但感覺普通，請重新設計其視覺概念，而不是添加隨機裝飾。圖片（如果存在）必須是真實/已授權的，或明確為藝術創作。
• 避免虛假精確度、虛構的財務主張、預設的靛藍紫色光暈、無處不在的圖示、裝飾性的卡片矩陣、損壞的西里爾字母、數據不足的圖表和極小的免責聲明。允許有意的命名品牌漸層：Crystal Cobalt 明確使用鈷藍色、青色和偶爾的紫羅蘭/洋紅色照明；上游 Hallmark 2a 衝突必須在原始稽核中記錄。偏好結構化的定向光線與局部深度，而非統一的模糊色塊。在插圖和 SVG 標記有助於釐清故事時允許使用。圖示需要語義意義與視覺一致性。
• 編碼前，草擬一頁視覺分數（visual-plan.json 或筆記）：每張投影片一個獨特的焦點元素和輪廓；分配所選主題適當的表面模式（Crystal Cobalt：atmospheric-dark、analytical-light、data-night、mixed-strategic；Azure Iris：lighter、refined、darker）；描述其標誌性主題和數據角色。在七張投影片的簡報中，力求至少五種明顯不同的輪廓；不要將所有頁面強制放入同一種構圖。從 references/styles/ 中的所選主題詞彙中選擇，或發明更強大的原創處理方式。
• 變化閘門： 相鄰頁面不得共享相同的主要幾何形狀、主視覺處理、圖形主題和密度；在一個簡報中，同時包含極度簡約和強烈圖形的頁面。至少保留一個打破預期左側標題/右側圖表排列的構圖。在變化其表現形式前，最多在 2-3 頁使用一個獨特的主題。這些是設計審查規則，而非無根據的數值主張。
• 圖示政策： 使用有目的性、風格匹配的內嵌 SVG 圖示或纖細的作者設計象形圖。對於純文字或數據主導的頁面使用零個圖示，當它們有助於改善層級時使用 1-3 個，且切勿僅為裝飾在每個 KPI 上方放置圖示。不要使用表情符號作為圖示替代。
• 效果與漸層： 允許在整個出版物中使用多種美學系列：例如，虹彩絲綢/緞帶、等高線地圖線稿、剪裁光場、半透明技術疊加、字型遮罩、柔和分級面板、精細網格紋理，以及數據綁定的 SVG 標記。避免在每一頁重複相同的效果。將裝飾性 SVG 保留在可編輯文字元素之外，以便混合 PPTX 將其作為精確靜態背景的一部分保存。
• 構建一個包含 project.json、獨立 slides/01-*.html ... 和 assets/*.css 的單一來源專案。每個來源投影片是一個完整的離線 HTML 文件，包含恰好一個 1920×1080 的 <section class="slide">。
• 每個要保持可編輯的可見文字/數字必須是帶有 data-editable="true" 的單一明確 HTML 元素。為獲得最大的 PPTX 保真度，請將每個顯示行分別寫入一個單獨的元素，不要有巢狀樣式文字跨度，並使用 CSS white-space:nowrap。複雜的 SVG 圖形和圖形裝飾保持為靜態背景。如果需要編輯，圖表標籤必須是單獨的 HTML 文字元素。
• 保持文字不被裁剪，包括免責聲明，並確保本地文字在字型替代時能夠容納。使用真實單位與參考。

3. 強制性 Hallmark 依賴

透過 npm run setup:hallmark 或手動審查的同等方式在 vendor/hallmark 安裝鎖定的上游版本。閱讀其 SKILL.md 以及僅相關的參考檔案（craft.md、layout.md、gates.md、data-viz.md）。簡報摘要和客戶設計檔案優先於隨機化的 Hallmark 主題。實際執行 Hallmark sloplint --genre editorial --render --json 對照已撰寫的頁面，擷取結果，並審查其發現。對網站專用版面規則的出版物特定例外情況，可以記錄明確的規則 ID 與原因，但缺少 Hallmark 永遠不能算作 PASS。不要假裝該工具已執行。

4. 使用附帶的確定性引擎渲染

python examples/editorial-reference/build_example.py # 選用示範
node bin/editorial.mjs build-html <project-directory> --out <output-directory> --allow-unverified
node bin/editorial.mjs verify <output-directory>

build-html 複製原始作者設計的 HTML 檔案；它不會將它們傳遞給通用投影片範本。Python Playwright/Chromium 擷取 (i) 完整 PNG/PDF 以及 (ii) 僅隱藏 [data-editable] 文字的相同像素大小靜態背景，以及每個元素的 DOM 座標、計算字型/樣式和幾何發現。然後 PptxGenJS 將這些背景放在本地文字後面。這是一個混合可編輯 PPTX，而非完整的原生 PowerPoint 重建。部署時，需要 --strict 驗證和正確字型。來源 HTML、螢幕截圖和每張投影片的編輯清單保持可重現。

5. 視覺 QA：有範圍但真實

第一個撰寫的預覽尚未準備好交付。使用 Playwright MCP（如果可用）或附帶的 Playwright 執行器，進行兩輪實際的視覺審查。在每一輪中檢查索引圖和相關的全解析度投影片。第一輪評論層級、節奏、獨特性、溢出、密度、圖表和清晰度，然後應用一批修正。第二輪重新渲染所有更改的投影片，並審查修正/回歸。第三輪取決於 P0/P1 失敗；切勿執行無限迴圈。僅在實際可用且確實有用時使用一個新的上下文評論子代理。不要發明 /goal 工具：僅在實現它的 harness 中使用。

自動化 DOM 和字型檢查在每張投影片上執行。策略性使用螢幕截圖（一張索引圖加上詳細的問題投影片）以控制 token 用量。使用 editorial review ... 和螢幕截圖的校驗和記錄兩次審查。沒有實際檢查就沒有審查記錄。如果在第三輪後仍有缺陷，則中斷執行，並誠實標記為 NOT_READY 狀態。

6. PPTX 保真度是發佈阻止條件

永遠不要僅僅因為存在文字物件和背景圖像就聲稱 PPTX 與 PDF 相同。每個建置必須在實際相容的渲染器中重新開啟 PPTX，以 HTML 參考大小柵格化其所有頁面，與 HTML/PNG 黃金樣本進行比較（並檢查嚴重差異）。使用：

python python/verify_pptx.py outputs/project/publication-editable.pptx --out outputs/project --visual --strict

檢查比較整個圖像、文字區域和背景，並分別儲存實際的 PPTX 頁面 PNG 以及差異圖像。一個導出圖層是沒有可編輯文字的全投影片圖像；原生的文字疊加層必須保留其座標、系列、顏色和粗細。不要使用 PowerPoint 自動調整/縮小，因為它會靜默地改變字型。避免包裝的原生文字：一行撰寫的文字 → 一個原生文字物件。相同的字型需要安裝在接收設備上。當數字在 PowerPoint 中修改時，來源數據和背景圖表藝術品不會更新。

基本限制： 任意渲染的原生 PowerPoint 文字無法保證在所有機器和辦公室套件上與 Chromium 文字逐位元相同。承諾在指定的渲染器上進行測試過的容差，而非普遍的字像素完美等價。當保真度低於閾值時，使閘門失敗。不要將可編輯的透明文字替換到已烘焙到背景中的文字之上：編輯後的值將不會明顯取代舊值。

7. 交付與發佈

使用者應取得 PDF、混合 PPTX、來源 HTML、索引圖和 QA 證據（render-report.json、hallmark-report.json、pptx-verify-report.json、比對差異和 release-status.json）。READY 需要真實的 Hallmark 稽核、已安裝/核可的字型、真正的視覺審查輪次、已驗證的財務主張、通過的 PPTX 視覺往返測試，以及對投資者分發的人為核准。示範者可以是 NOT_READY，且必須如此標記。

在每個新的編輯性出版物之前，閱讀 docs/art-direction.md 和所選主題的規格。其他支援文件：docs/architecture.md、docs/design-grammar.md、docs/quality-gates.md、docs/hybrid-pptx.md、docs/hallmark-integration.md。