Koubou：App Store 截圖產生器
使用 HTML/CSS 範本搭配 100 多種真實裝置框架、xcstrings 在地化及像素完美的 Apple 尺寸，產生專業的 App Store 截圖。
截圖是廣告，不是文件。每張幻燈片都在銷售一種感受、結果或痛點解決方案。
此技能中，使用者指示始終優先於預設值。
預設情況下創意方向是開放的。 使用此技能中的規則來強制要求影響力、可讀性和可感知畫布的縮放，而不是讓每組截圖看起來都一樣。
規則層級
依照此順序處理此技能中的指南：
- 硬性限制 — 可讀性、縮放、縮圖清晰度、真實的產品行銷以及真實的畫布感知
- 強烈預設 — 多樣性、不對稱性、重疊、節奏感，以及避免通用佈局
- 風格偏好 — 反平庸啟發法和風格預設值，當有更強烈的想法能明顯改善作品時，可以打破這些預設值
如果打破預設值能產生更好的截圖集，就刻意打破它，並在產生前向自己解釋其中的取捨。
參考檔案（按需閱讀，非預先閱讀）：
setup.md— 安裝與 HTML 執行環境設定design-guide.md— 設計原則、文案規則、CSS 規則、HTML 範本範例style-intake.md— 如何在提問前檢查應用程式的真實視覺語言style-interview.md— 簡短、高訊號的風格問題與對話模式yaml-reference.md— YAML 配置格式、在地化、素材、裝置、尺寸capabilities-reference.md— 完整的 koubou 功能（內容模式、強調、縮放、漸層）
階段 1：設定（靜默、自動）
首先檢查 kou 是否可用。如果 kou 已能正常運作，請勿重新安裝或觸碰 Python 套件管理。
首選順序：
kou --version 2>/dev/null
如果 kou --version 成功：
- 將 koubou 視為已安裝
- 不要執行
pip、pip3或playwright install - 不要嘗試主動「升級」或「修復」使用者的環境
- 務必在每次產生前執行
kou setup-html，因為此技能僅限 HTML，且該命令設計為可安全重複執行
如果 kou --version 失敗，請閱讀 setup.md 並遵循對環境影響最小的路徑。
對於 HTML 渲染支援：
- 始終使用
kou setup-html - 不要因為 HTML 在之前的執行中有效就跳過此步驟
- 不要直接執行
playwright install chromium
僅在設定失敗時通知使用者。切勿修改正常運作的安裝。
階段 2：閱讀應用程式，然後提問
不要從通用的風格問卷開始。首先檢查應用程式的真實視覺語言，然後只詢問仍然遺失或不明確的部分。
在詢問風格問題之前，請先閱讀 style-intake.md。按此順序進行。
2.1 風格探索（在風格問題前為必做）
首先檢查本地專案原始碼。在使用者提出視覺方向之前自動進行搜尋。
優先考慮這些來源：
Assets.xcassets、應用程式圖示、插圖、標誌、顏色素材- 現有的截圖和行銷資料夾：
.maestro/screenshots/AppStore/fastlane/screenshots/marketing/
- 產品文件和定位：
README*CLAUDE.md- 發佈計劃、著陸頁文案、docs 資料夾
- 設計標記和使用者介面程式碼：
- CSS 變數
- SwiftUI 顏色、漸層、材質、排版選擇
- 網頁主題檔案和共享設計常數
- 如果存在，先前的 App Store 成品：
- 先前的範本
- 舊的截圖活動
- 在地化的行銷素材
提取並摘要至少這些訊號：
- 主色和強調色
- 整體對比度：深色、淺色、混合、柔和、鮮豔
- 介面密度：寬敞、平衡、密集
- 形狀語言：銳利、柔和、圓潤、以卡片為主、扁平
- 圖示和插圖風格
- 如果可以觀察到的排版方向
- 文案語氣：冷靜、技術性、俏皮、高級、溫暖、緊迫
- 應用程式感覺是冷靜、技術性、溫暖、充滿活力、精緻、俏皮等
如果應用程式風格明確：
- 用平實的語言向使用者摘要檢測到的訊號
- 確認你將從該方向建構，而不是從通用範本語言重新開始
如果訊號微弱、缺失或矛盾：
- 說出你發現了什麼
- 針對不確定之處提出有重點的後續問題，而不是提出廣泛的設計問卷
2.2 意圖訪談（簡短、高訊號）
閱讀 style-interview.md，只問最低限度的問題。保持對話性質。不要一次拋出所有問題。
在仍然需要時的必問風格問題：
- 這個活動應傳達什麼感覺：高級、俏皮、編輯風格、實用、技術性、溫暖等？
- 是否有應影響方向的 App Store 參考資料、品牌或截圖集？
- 視覺上禁止哪些元素：強烈的漸層、玻璃擬態、僅深色模式、卡片網格、過於俏皮的風格等？
- 應用程式中哪些視覺特質必須在截圖中仍然可辨識？
僅在仍未解決時才問的選答題：
- 偏好的排版方向或字體個性
- 淺色、深色或混合偏好
- 密度偏好：更多留白或更多資訊
- 各張幻燈片之間應該感覺高度一致還是明顯不同
2.3 產品資訊（仍為必填）
在風格探索開始後，自然地收集其餘的生產輸入：
- 應用程式：名稱、功能描述（一句話）、主要價值主張
- 截圖：應用程式截圖在哪裡？首先自動搜尋：
- 如果找到，顯示你找到的內容並確認
- 如果未找到，詢問使用者如何產生它們
- 優先選擇能清晰顯示應用程式 UI 的乾淨模擬器截圖。如果使用者可以選擇，優先選擇最近的 6.1 吋 iPhone 截圖作為原始素材
- 要強調的功能：按優先順序列出的功能/優點（建議 3-5 個）。每張幻燈片 = 1 個功能
- 主要素材：應用程式圖示或其他品牌素材。在詢問前自動搜尋
- 幻燈片數量：需要多少張截圖（建議從 3-5 張開始，Apple 最多允許 10 張）
僅在相關時才問的選填項：
- 裝置：預設為
iPhone 16 Pro - Black Titanium - Portrait。僅在 iPad/Mac/其他裝置有意義時才詢問 - 在地化：僅當專案已有 xcstrings 或多語言支援時
- 額外素材：浮動 UI 元素、徽章、輔助插圖
- 額外限制：要求的聲明、禁止的風格或行銷限制
2.4 風格決定（在撰寫 HTML 前為必做）
在起草範本之前，明確決定並內部鎖定以下六項：
偵測到的品牌訊號選擇的活動風格文案語氣背景系統裝置構圖節奏各幻燈片的變化計劃
每個項目都必須由以下任一者證明其合理性：
- 來自風格探索的應用程式證據，或者
- 來自訪談的直接使用者回饋
如果你無法證明其中任何一項的合理性，請在設計之前繼續提出重點問題。
衍生項目（除非受阻，否則不要詢問）
- 來自品牌色和 UI 情緒的背景漸層或紋理
- 佈局分佈（主打 → 功能頂部 → 功能底部 → 交替）
- 來自功能和價值主張的標題文案
- 來自應用程式實際調色板的次要色板
- 來自
project.device+project.output_size的kou inspect-frame的畫布類別 - 應用程式名稱是否應出現。預設：省略它，除非它能以可讀的尺寸增加真正的品牌價值
- 應用程式圖示是否應出現。預設：謹慎使用它，僅在主打或結尾幻燈片上，不要作為一個微小的裝飾性標記
原則：如果本地已有可用的上下文，請在使用前先使用它。風格問題應在檢查之後而非之前提出。
階段 3：產生
在產生範本前閱讀 design-guide.md。在撰寫配置前閱讀 yaml-reference.md。
-
建立工作目錄（例如
AppStore/或對專案有意義的任何位置） -
執行
kou setup-html -
從 YAML 讀取
project.device和project.output_size -
執行
kou inspect-frame "<device>" --output-size <size> --output json並在撰寫 CSS 前使用該幾何數據 -
在觸碰佈局前，先起草敘事弧線以及每張幻燈片的 2-3 個標題/副標題選項。首先挑選最強的一個。文案品質優先於 CSS
-
將風格決定轉化為活動簡報：
- 這個截圖集應該給人什麼感覺
- 允許使用哪些主題
- 禁止使用哪些主題
- 前 5 張幻燈片應展現多少變化
-
建立
templates/資料夾並放入 HTML 範本 — 至少 3 種不同的佈局，且前 3 張幻燈片不得重複相同的構圖原型 -
在每個 HTML 範本中，在撰寫任何 CSS 之前，為以下元素添加
data-kou-id和data-kou-role：- 主標題：
data-kou-id="headline" data-kou-role="headline" - 輔助文案：
data-kou-id="subtitle" data-kou-role="supporting" - 主要裝置圖像：
data-kou-id="device" data-kou-role="device" - 功能標題/副標題（結尾/功能幻燈片）：
data-kou-id="feature-N-title" data-kou-role="feature-title"、data-kou-id="feature-N-sub" data-kou-role="feature-sub"
如果沒有這些，佈局側車的
elements陣列將會是空的，導致渲染後的品質檢查無法進行。請參閱design-guide.md中的範本範例以了解正確的註解模式。 - 主標題：
-
使用 koubou 配置建立
config.yaml（閱讀yaml-reference.md了解格式） -
使用能適應畫布和文案長度的 CSS：有意識地使用
vw或clamp()，偏好 CSS Grid、重疊和絕對定位圖層，並在真實畫布上驗證最終的計算文字大小 -
在撰寫 HTML 之前：為每張幻燈片規劃文字/裝置區域（每個區域佔畫布的多少百分比）。在區域清晰之前不要開始撰寫 CSS
-
執行：
kou generate config.yaml --output json -
對於每個產生的 HTML 截圖，從 JSON 結果中讀取
layout_path，並在決定佈局可接受之前檢查側車 -
渲染後品質保證（必做 — 不要跳過）：
- 視覺檢查每個產生的幻燈片
- 開啟
layout_path引用的每個*.layout.json側車 - 根據
design-guide.md中的拒絕檢查清單進行檢查 - 檢查渲染後的截圖集是否仍然反映你發現的應用程式風格，而不是通用的 App Store 預設值
- 僅將佈局 JSON 用於客觀幾何數據：位置、佔用空間、比例和數學重疊
- 如果需要被測量的 HTML 幻燈片的
elements是空的，則將其視為遺失或損壞的註解，並修復範本 - 驗證：沒有表情符號圖示、沒有相同的卡片網格、沒有未置中的裝置、沒有低於最小尺寸的文字、沒有意外的裝置裁切（主打幻燈片上必須可見裝置頂部/瀏海；螢幕內容必須可讀）
- 應用標誌交換測試：這些幻燈片對競爭對手來說也適用嗎？
- 如果任何幻燈片失敗，請在展示給使用者之前修復並重新產生
-
開啟輸出資料夾：
open <output_dir> -
詢問使用者是否需要調整 — 迭代特定幻燈片，而無需重新產生所有內容
迭代規則
- 當使用者要求更改特定幻燈片時，僅修改該範本和配置條目
- 當使用者要求全局風格更改（顏色、字體、情緒、密度、粗細）時，更新所有範本
- 更改後重新執行
kou generate config.yaml --output json，以使新的layout_path值和側車保持同步 - 如果使用者在編輯時想要即時預覽，請使用
kou live config.yaml - 如果幻燈片感覺很小，首先增加比例或切換佈局。不要用額外的漸層或標籤來隱藏問題
- 如果文案導致文字過小，請重寫文案或選擇更合適的佈局；切勿因為「文字必須適合」而接受一張平庸的幻燈片
- 保持高度多樣性：目標是活動的一致性，而不是佈局的重複
- 如果輸出仍然違反設計規則或拒絕檢查清單，請不要在第一次成功渲染後就停止
- 如果使用者要求改變情緒，請在品質限制內重新詮釋整個截圖集，而不是為先前的預設值辯護
- 如果截圖和佈局 JSON 不一致，則相信渲染後的截圖以體現品味，並調查註解或渲染時序，而不是從過時的幾何數據強制執行佈局決策
硬性規則
硬性限制
- 切勿使用表情符號作為圖示 — 使用 CSS 形狀（強調條、點）或僅使用文字
- 切勿使用禁止的文案短語 — 例如「革命性的」、「無縫的」、「解鎖」、「顛覆性的」等
- 應用標誌交換測試 — 如果競爭對手的名稱適合，則表示該截圖集過於通用
- 每個 HTML 範本必須有
data-kou-id註解 — 至少要有：headline、subtitle和device。如果產生後佈局側車中的elements為空，則表示註解遺失 — 在品質檢查通過前修復範本。請勿向使用者展示未經註解的幻燈片
縮放
- 在較高的 iPhone 直向模式（
iPhone6_9、iPhone6_7）上，主打標題必須>=10vw，側邊佈局標題>=10vw，副標題>=4.5vw - 僅在計算後的大小在目標畫布上仍高於最小值時，才使用
vw或clamp() - 在對比或結尾幻燈片上，內容群組必須佔據畫布高度的 60% 以上
強烈預設
- 不要在連續的幻燈片上使用相同的直立、居中手機構圖
- 不要在標題和裝置之間留下大的空白區域（> 畫布高度的 15%）
- 避免在居中裝置上組合使用
rotate()+translate()，除非在渲染後視覺中心仍然感覺有設計意圖 - 當幻燈片需要重疊、邊緣突破裁切或分層構圖時，不要使用簡單的居中 flex 列
- 在撰寫 CSS 前規劃文字/裝置區域（請參閱 design-guide.md 中的裝置-文字區域規劃）
- 如果你使用卡片網格，除非嚴格的網格確實服務於概念，否則請錯開、強調或簡化它們
內容
- 預設情況下，不要添加微小的頂部標籤、類別標籤或應用程式名稱頁首
- 除非清晰可讀，否則不要將應用程式名稱渲染為小型裝飾性文字