品牌參考包

品牌參考包 是做什麼的？

此包是背景脈絡，而非內容。 它記錄品牌已經是什麼樣子（受眾、語調、視覺語言、 權杖，以及每個主張所來自的螢幕與文案），以便後續可以根據它來做出格式、腳本與設計決策。 包中不包含鉤子、腳本或系列。如果某個來源暗示了其中一項，請註明來源並保持決策開放。

位置圖：

上游（策略） ──→ 此技能（觀察到的品牌） ──→ 下游（格式、腳本、Reels）
ICP · VOC · 品牌語調   表面所說/顯示的內容      腳本到Reel、shader-lab

此技能不建立 ICP、客戶之聲或品牌語調。它會找到上游產出物，根據它們檢查表面， 並將每個標記為已驗證 / 推斷 / 遺失（包 §0）。差異應回報給上游；不要在這裡掩蓋它們。

檔案：

• template.md：包的章節結構。
• scripts/：通用擷取與渲染輔助工具。
• apps/<app>/：每個應用程式一個資料夾，包含其 URL、流程配方、特殊情況、生產規則和 PDF 版面。
  • 首先閱讀 apps/<app>/README.md。 對於新應用程式，請在接收期間建立它。

以下指令相對於此技能資料夾（.claude/skills/brand-reference-pack/）撰寫，輸出路徑相對於執行它們的位置。 從專案根目錄執行，並以技能路徑作為 scripts/ 的前綴。pack_pdf.py 會解析相對於技能配置的路徑。

0. 接收（一輪 AskUserQuestion，僅限新應用程式）

收集：

• 應用程式名稱。
• 網站 URL。
• 社群媒體帳號。
• App Store ID 與國家（如果相關，則為 Play 套件 ID）。
• 如何執行應用程式：模擬器建置、TestFlight、網頁應用程式或模擬器。
• 程式碼儲存庫路徑（如果有的話）。
• 現有的品牌、ICP 或研究文件。
• 哪個流程是核心流程。
• 生產中哪些是禁止的。
• 輸出資料夾。

將答案寫入 apps/<app>/README.md。

1. 基礎檢查（ICP、客戶之聲、品牌語調）

對於每個基礎，尋找上游產出物：Wiki 或文件資料夾、研究簡報、品牌書。

• ICP： 由數據或研究支持的已定義目標客戶。註明其信心水準和樣本大小。
• 客戶之聲： 來自訪談、評論、支援或社群的客戶自己的話語。品牌自家網站上的推薦僅算作弱證據：它們是經過策劃的。
• 品牌語調： 書面的語調指南或文案規則。

將每一個記錄在包的 §0 表格中。在步驟 2 到 5 中，檢查即時表面是否與產出物相符。 不符之處歸入「開放決策」。如果某個產出物遺失，請說明並指出可以填補該缺口的上游工作；不要從表面憑空創造基礎。

2. 公開表面（儘可能並行）

每個主張都需要 refs/ 中的一個檔案。

網站：

node scripts/site.mjs <url> <brand>/refs/web

這會儲存桌面和行動裝置的完整頁面與重點區域截圖，以及包含字型（包括 font-host ID 背後的實際字型名稱）、顏色、圖片、連結和頁面文字的 site-styles.json。將完整頁面截圖切成約 4 部分以便閱讀。

App Store：

node scripts/store.mjs <id> <brand>/refs/store [country]

這會儲存列表（官方定位）、商店截圖，以及作為原始 VOC 材料的評論。

社群媒體（在內建瀏覽器中）：

• 拒絕可選的 cookies。
• 網格：收集每個貼文的圖片 src 和 alt，將它們繪製到畫布上，用其取代頁面並截圖。
• 標題：對每個貼文頁面進行同源擷取 → og:description。
• 未登入狀態下，您只能取得大約 12 則貼文。請說明此情況，如果 Reels 很重要，請要求使用者登入或匯出。
• 如果您取得了 Reels，請記錄其節奏、標題風格和音訊。
• 將所有內容寫入 refs/<platform>/。

現有文件： 使用 Explore 子代理來綜合分析受眾、承諾、術語、語調規則和主張，並附上檔案引文。

3. 程式碼權杖（如果有儲存庫）

使用 Explore 子代理來找出應用程式所使用的任何框架的佈景主題：

• Flutter ThemeData 和顏色常數
• Tailwind 設定
• CSS 變數
• iOS 資產目錄
• Android colors.xml

同時涵蓋字型、圓角半徑、動畫慣例、著色器、標誌檔案和值得注意的 UI 文案。 自行抽查十六進位色碼。撰寫 tokens.json，包含顏色角色、字體級數（縮放到 1080×1920）、形狀、動畫和畫布。

應用程式內文案： 從 UI 程式碼中擷取每個面向使用者的字串，逐字附上檔案：行號，供人物角色大腦使用（步驟 7）：

python3 scripts/app_copy.py <src root> <persona>/raw/app-copy/app-copy-<date>.md <ui dirs/files…>

（Flutter：app/lib 搭配 pages widgets constants models enums main.dart；其他堆疊則使用 --ext=.tsx 等。）它會過濾日誌、金鑰和 ID；在將其放入大腦之前，仍然需要瀏覽輸出內容以確認沒有機密資訊。

4. 即時應用程式走查

最豐富的來源：這是產品實際的視覺與語言文法展現的地方。

• 先取得同意： 明確說明此執行會寫入哪些生產資料（帳戶、評估答案、產生的報告、完成狀態），並獲得同意。使用者執行所有註冊和登入動作。絕對不要輸入憑證，絕對不要訂閱，絕對不要向 AI 教練發送訊息。
• 觀看與錄製： 連接模擬器面板（mcp__Claude_Code_iOS_Simulator__control attach）。
  • 在背景啟動 xcrun simctl io <UDID> recordVideo --codec=h264 --force <file>。
  • 在登入期間停止它，並在之後啟動一個新的，這樣就不需要修剪任何內容。
  • 使用 pkill -INT -f recordVideo 停止。
• 透過輔助功能標籤而非座標來驅動： UDID=… OUT=<brand>/refs/app scripts/ui.sh tree|shot|label|tap|swipe|hold。
  • 對每個新螢幕拍攝一張照片，以其標題命名。
  • 等待動畫和 CMS 文案穩定後再拍攝；如果某行尚未渲染，則標記為「未擷取」。
  • 為每個階段建立一份連絡表（PIL，幾行），並閱讀此連絡表，而不是每個 PNG。
• 遵循 apps/<app>/README.md 中的應用程式配方。 將您遇到的新特殊情況新增回其中。
• 音訊： 模擬器錄製沒有音訊。如果應用程式有語音或音訊，請向使用者索取原始檔案。
• 之後：
  • 按擷取順序重新編號截圖。
  • 建立 refs/app-flow-sheet.jpg。
  • 壓縮錄製內容：scale=540:-2,fps=30,crf 26。

5. 撰寫包

將 template.md 填入 <brand>/README.md。

• 只引用您看到的內容。
• 如果表面之間不一致，最新的即時表面是工作預設值，不一致之處歸入「開放決策」。
• §0 來自步驟 1。

6. 驗證

將 README 和 refs/ 資料夾交給一個全新的子代理，而不是您的結論。要求它檢查每一個被引用的行、十六進位色碼和主張是否都有一個檔案作為來源，並列出任何沒有來源的項目。在交回之前修正或標記每個項目。

7. 輸出

• PDF： 撰寫 apps/<app>/pdf.json（複製 GetAhead 的範例：封面、字型、強調色、指向 tokens.json 的色板群組、字體範例行、截圖頁面）。然後執行：

  python3 scripts/pack_pdf.py apps/<app>/pdf.json
  

  檢查結果，以 pdftoppm -r 40 連絡表的形式查看。
• 文件： 如果專案有 Wiki 或文件，請依照其慣例（頁面、索引、日誌、在其取代的頁面上加上矛盾標記）將包歸檔到那裡。
• 人物角色大腦： 如果專案有人物角色大腦（例如 persona/，作為腳本生成說話依據的品牌化身大腦），請將應用程式走查的擷取內容複製到其 raw/app-run-<date>/ 中，並將應用程式內文案複製到 raw/app-copy/ 中（需獲得使用者的同意：raw/ 是他們的），然後執行大腦自己的攝取工作流程（其 CLAUDE.md）：來源頁面、概念頁面、使用逐字應用程式行進行卡片重建。此包記錄品牌的外觀；大腦記錄它如何說話——腳本依賴大腦。
• 傳送： 使用 SendUserFile 傳送 PDF 和 README。
• 報告：
  • 寫入了哪些生產資料
  • 哪些內容未擷取
  • 基礎狀態
  • 開放決策