Communitygithub.com

webiscorp/designskill-open

從頭開始或轉換 PowerPoint 檔案,建立引人入勝、動畫豐富的 HTML 簡報。當使用者想要建立簡報、將 PPT/PPTX 轉換為網頁,或為演講/提案建立投影片時使用。幫助非設計師透過視覺探索而非抽象選擇來發掘其美感。

designskill-open 是什麼?

此技能能建立零依賴、動畫豐富的 HTML 簡報,完全在瀏覽器中執行。它遵守固定的 16:9 舞台規則 (1920×1080),確保在所有螢幕上維持一致的比例,不重新排版。設計上強調獨特美感,避免常見的 AI 生成風格,專注於字體、色彩、動態和背景。它支援全新建立、從 .pptx 轉換並最佳化,以及增強現有 HTML 簡報。其「展示,而非說明」的流程會根據目的、長度和內容密度,直接產生三種不同的投影片預覽,讓使用者透過視覺比較來選擇,而非描述抽象的偏好。此技能適用於 Claude Code、Cursor、Codex 等主要 AI 代理平台,特別適合需快速產出客製化、視覺衝擊簡報的開發者與非設計師。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/webiscorp/designskill-open/tree/HEAD/skills/frontend-slides

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

Frontend Slides

建立零依賴、動畫豐富的 HTML 簡報,完全在瀏覽器中執行。

核心原則

  1. 零依賴 — 單一 HTML 檔案,內嵌 CSS/JS。不需要 npm,不需要建置工具。
  2. 展示,而非說明 — 產生視覺預覽,而非抽象選擇。人們透過觀看來發現自己想要什麼。
  3. 獨特設計 — 不能是普通的「AI 產物」。每個簡報都必須感覺是量身打造的。
  4. 漸進式揭露 — 先讀取輕量級的樣式索引。對於大膽的範本,使用小型預覽卡來預覽樣式,並僅在使用者選定該範本後才載入完整的 design.md。
  5. 固定的 16:9 舞台(不可協商) — 每個投影片組使用 1920×1080 的投影片畫布,並整體縮放以符合視窗。投影片在所有螢幕(包括手機)上都必須保持 16:9 比例。不要為了適應裝置而重新排列投影片內容。

設計美學

你傾向於產出一般的、「分佈平均」的輸出。在前端設計中,這會產生使用者所謂的「AI 產物」美學。要避免這個情況:製作出有創意、有特色的前端,讓人驚喜和愉悅。

專注於:

  • 字體:選擇美麗、獨特且有趣的字體。避免使用 Arial 和 Inter 等通用字體;改為選擇能提升前端美感的獨特字體。
  • 色彩與主題:致力於連貫的美學。使用 CSS 變數以保持一致性。具有強烈對比色的主色比膽怯、均勻分佈的調色板效果更好。從 IDE 主題和文化美學中汲取靈感。
  • 動態:使用動畫來達到效果和微互動。優先考慮純 CSS 解決方案。在 React 中可使用 Motion 函式庫。專注於高衝擊時刻:一次精心編排的頁面載入,搭配交錯出現(animation-delay),比分散的微互動更能帶來愉悅感。
  • 背景:營造氛圍和深度,而非預設為純色。疊加 CSS 漸層、使用幾何圖案,或加入符合整體美學的背景效果。

避免普通的 AI 生成美學:

  • 過度使用的字體家族(Inter、Roboto、Arial、系統字體)
  • 老套的配色方案(特別是白色背景上的紫色漸層)
  • 可預測的佈局和元件模式
  • 缺乏情境特定特色的套版設計

要有創意地解讀,做出意想不到的選擇,讓人感覺是為情境真正設計的。在淺色和深色主題、不同字體、不同美學之間變化。你仍然傾向於在多次生成中選擇常見的選擇(例如 Space Grotesk)。要避免這個情況:跳出框架思考至關重要!

固定舞台規則

這些不變項適用於每個簡報中的每一張投影片:

  • 每個投影片組都有一個填滿瀏覽器視窗的視窗包裝器。
  • 每張投影片都是在固定的 1920×1080 舞台內編寫的。
  • 舞台會均勻縮放以符合視窗。可能會出現信箱/柱箱效果;不得重新排版內容。
  • 不要使用響應式中斷點來為手機重新排列投影片內容。
  • 使用 1920×1080 設計尺寸的固定內部投影片尺寸。
  • 投影片的可見性必須使用 viewport-base.css 中的 .active / .visible 類別,透過 visibility、opacity 和 pointer-events 來控制。不要使用 display: none / display: block 來切換投影片;後續的佈局類別(例如 .slide-content { display: flex; })可能會覆蓋它們,使每張投影片同時可見。
  • clamp() 僅用於舞台外的非投影片 UI,或用於無法使用完整舞台的小型備用預覽。
  • 包含 prefers-reduced-motion 支援。
  • 永遠不要直接否定 CSS 函式(-clamp()、-min()、-max() 會被忽略)——請使用 calc(-1 * clamp(...))。

產生時,請讀取 viewport-base.css 並將其完整內容包含在每個簡報中。

內容密度模式

詢問使用者這主要是閱讀型簡報還是演講型簡報,然後根據答案進行設計:

密度模式最適合設計行為
低密度 / 講者主導公開演講、主題演講式分享、現場解說一張投影片一個想法、大字型、強烈的視覺層次、大量的留白、最多 1-3 個項目符號、必要時使用更多投影片
高密度 / 閱讀優先報告、講義、非同步審閱、詳細的內部文件更自成一體的投影片、結構化的網格/表格/註解、可讀性佳時使用 4-8 個項目符號或 4-6 個卡片、間距較緊但仍刻意安排

基線限制仍然適用:沒有捲動、沒有溢出、沒有重疊面板、文字不小於舒適閱讀尺寸。如果內容超過所選的密度模式,請將其拆分到更多投影片中,而不是縮小直到變得擁擠。


階段 0:偵測模式

確定使用者想要什麼:

  • 模式 A:新建簡報 — 從頭開始建立。進入階段 1。
  • 模式 B:PPT 轉換 — 轉換 .pptx 檔案。進入階段 4。
  • 模式 C:增強 — 改進現有的 HTML 簡報。讀取它,理解它,進行增強。遵循下列的模式 C 修改規則。

模式 C:修改規則

在增強現有簡報時,固定舞台的適配是最大的風險:

  1. 在新增內容之前: 計算現有元素數量,檢查密度限制
  2. 新增圖片: 將它們放入 1920×1080 的投影片畫布內。如果投影片已有最大內容,則拆分為兩張
  3. 新增文字: 每張投影片最多 4-6 個項目符號。超過限制?拆分為續頁
  4. 在任何修改之後,驗證: 投影片舞台仍然是 16:9,沒有文字溢出其卡片,沒有面板重疊,並且在 1280×720 加上一個手機視窗下截圖看起來正確
  5. 主動重新組織: 如果修改會導致溢出,自動拆分內容並告知使用者。不要等到被問起才做

在現有投影片中新增圖片時: 將圖片移至新投影片或先減少其他內容。在沒有檢查現有內容是否已填滿 1920×1080 投影片舞台之前,永遠不要新增圖片。


階段 1:內容探索(新建簡報)

一次詢問所有問題,讓使用者一次性填寫完畢。如果目前環境提供原生結構化問題 UI,請使用它;否則,在一條簡潔的訊息中提問,並使用清晰編號的選項:

問題 1 — 目的(標題:「目的」): 這個簡報的目的是什麼?選項:募資簡報 / 教學-教程 / 會議演講 / 內部簡報

問題 2 — 長度(標題:「長度」): 大約需要幾張投影片?選項:短 5-10 / 中 10-20 / 長 20+

問題 3 — 內容(標題:「內容」):\n你準備好內容了嗎?選項:所有內容已準備好 / 粗略筆記 / 只有主題

問題 4 — 密度(標題:「密度」): 希望簡報感覺多密集?選項:

  • 「低密度 / 講者主導」 — 大想法,較少文字,更多視覺呼吸空間
  • 「高密度 / 閱讀優先」 — 更多為非同步閱讀準備的自足細節

在階段 1 期間不要詢問內聯編輯。 使用者不應該在看到草稿之前就必須選擇編輯行為。內聯編輯是草稿後的便利功能:預設包含它,除非使用者明確要求鎖定/僅匯出檔案。

記住使用者的密度選擇。它會影響投影片數量、字體大小、每張投影片的文字量、佈局密度,以及是要偏向電影風格的講者投影片還是自足的閱讀投影片。

如果使用者有內容,請他們分享。

步驟 1.2:圖片評估(如果提供了圖片)

如果使用者選擇「無圖片」→ 跳至階段 2。

如果使用者提供圖片資料夾:

  1. 掃描 — 列出所有圖片檔案(.png、.jpg、.svg、.webp 等)
  2. 檢查每張圖片 — 使用代理程式可用的圖片理解能力。如果無法讀取圖片,請使用檔案名稱/元數據,僅在必要時要求使用者澄清
  3. 評估 — 對每張圖片:它顯示什麼、可用或不可用(附原因)、代表什麼概念、主要顏色
  4. 共同設計大綱 — 策劃的圖片與文字一起影響投影片結構。這不是「先規劃投影片再加圖片」——而是從一開始就圍繞兩者進行設計(例如,3 張截圖 → 3 張功能投影片,1 張標誌 → 標題/結尾投影片)
  5. 確認大綱,在可用時使用相同的結構化問題機制:「這個投影片大綱和圖片選擇看起來對嗎?」選項:看起來很好 / 調整圖片 / 調整大綱

預覽中的標誌: 如果識別出可用的標誌,將它(base64)嵌入階段 2 的每個樣式預覽中——使用者會看到他們的品牌以三種不同風格呈現。


階段 2:樣式探索

這是「展示,而非說明」的階段。 大多數人無法用言語表達設計偏好。

步驟 2.0:直接產生 3 個樣式預覽

根據目的、觀眾、氛圍和內容密度,產生 3 個不同的單頁 HTML 預覽,展示字體、色彩、動態和整體美學。

不要詢問使用者是否想要選項或預設選擇器。預設的探索體驗始終是視覺比較。

如果使用者已經給了感覺,就使用它。如果沒有,根據場合、觀眾、內容和重要性來推斷可能的氛圍。保持選項足夠多樣化,以便使用者可以透過視覺反應,而不是必須先表達他們的品味。

如果使用者明確指定了預設或大膽的範本,請將其作為一個選項,並圍繞它產生其餘的預覽內容。

讀取 STYLE_PRESETS.md 以獲取安全的預設候選清單。如果 bold-template-pack/selection-index.json 存在,也讀取該精簡索引,但不要讀取任何 design.md 檔案。

氛圍建議預設
印象深刻/自信大膽訊號、電動錄音室、暗色植物
興奮/充滿活力創意電壓、霓虹網路、分割粉彩
冷靜/專注筆記本分頁、紙張與墨水、瑞士現代
啟發/感動暗色植物、復古編輯、粉彩幾何

預覽混合規則:

  • 預設產生 3 個預覽:1 個來自 STYLE_PRESETS.md 的安全預設,至少 1 個來自 bold-template-pack/selection-index.json 的大膽範本,以及 1 個自由發揮。
  • 自由發揮可以是第二個大膽範本,也可以是自行產生的客製設計。選擇能為使用者的場合、觀眾、氛圍和內容創造最強烈、最有用的對比的那個。
  • 不要強迫每個富有表現力的選項都來自範本庫。如果需求比現有範本能提供的更尖銳、更具體,請使用自由發揮的位置來自由設計。
  • 對於保守或高風險的投影片組,確保安全預設特別克制;選擇一個冷靜、正式程度較高的大膽範本;讓自由發揮成為另一個克制的範本,或是一種感覺權威而非裝飾性的客製設計。
  • 對於富有表現力的投影片組,將安全預設保留為可讀的備用方案;選擇一個強大的大膽範本;讓自由發揮大膽、針對情境,且與其他兩個預覽明顯不同。
  • 如果大膽範本的匹配度不佳,請將自由發揮用作客製設計,或改為回退到另一個安全預設,而不是強迫使用範本。

自訂自由發揮設計規則:

  • 遵循上面的設計美學部分:沒有通用的「AI 產物」,沒有預設的字體/顏色/佈局選擇,沒有紫色漸層配白色背景的陳腔濫調,沒有套版的儀表板/卡片外觀。
  • 搭配使用者陳述的場合、觀眾、氛圍/感覺和內容密度。客製設計應該感覺是為這個投影片組量身打造的,而不僅僅是「時尚」。
  • 做出一個明確的視覺命題:獨特的字體、一個投入的調色板、一個可識別的佈局系統,以及一個強烈的氛圍或圖形裝置。
  • 保持其可行性以用於完整的投影片組。預覽必須暗示一個可以擴展到章節、內容、引言、比較和結尾投影片的設計系統。
  • 使用固定的 1920×1080 舞台規則,並通過與其他選項相同的預覽真實性檢查。
  • 永遠不要在投影片本身渲染「客製」、「自由發揮」、「AI 生成」或設計流程標籤。

大膽範本選擇規則:

  • 根據 mood、tone、best_for、avoid_for、formality、density 和 scheme 來匹配使用者的目的和氛圍。
  • 將 best_for 範例視為軟訊號,而非嚴格的行業過濾器。
  • 保持三個預覽彼此之間真正不同。
  • 在選定大膽範本候選清單後,僅從選擇索引中的 preview_md 路徑讀取這些候選的 preview.md 檔案。
  • 僅使用 preview.md 進行標題投影片預覽。在使用者選擇最終範本之前,不要讀取完整的 design.md 檔案。
  • 除非所選的最終 design.md 缺少關鍵的實作細節,否則不要讀取或複製 template.html。

預覽真實性規則(不可協商):

  • 每個樣式預覽必須看起來像是使用者投影片組中的真實第一張投影片,而不是診斷卡。
  • 永遠不要在投影片上渲染內部工作流程文字:沒有 preview、generated from、preview.md、template、preset、style option、Option A/B/C、檔案名稱、路徑或來源文件標籤。
  • 永遠不要在投影片本身渲染範本名稱或別名。範本/樣式名稱僅屬於給使用者的訊息中。
  • 永遠不要將使用者需求註釋渲染為投影片內容,例如「尖銳且挑釁」、「安全選項」、「大膽選項」、「供內部共享」或「觀眾:...」,除非使用者明確希望該確切短語出現在投影片組中。
  • 如果投影片需要裝飾元素,請僅使用真實的投影片組裝飾元素:投影片組標題、章節標題、日期、作者、公司、頁碼,或來自使用者材料的真實內容短語。
  • 在開啟預覽之前,檢查可見文字,並在發現任何內部元數據時進行修改。

將預覽儲存到 .frontend-slides/slide-previews/(style-a.html、style-b.html、style-c.html)。每個...

[依原文截斷,待續]

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

相關技能