一句話結論： 完成 Meta Ads MCP 或其他可信任資料工具的串接後，可以把每週報表、素材疲乏檢查、競品研究與預算建議寫成 Claude Code Skills。之後只要輸入
/weekly-report、/fatigue-scan等指令，就能重複執行同一套流程。
行銷人使用 Claude Code 時，最常見的問題不是「Claude 不會分析廣告」，而是每次都要重新解釋帳號、日期、指標、輸出格式與安全限制。Claude Code Skill 的用途，就是把這些固定規則整理成可重複呼叫的 Prompt。
使用前要準備什麼？
1. 安裝 Claude Code
請依 Anthropic 官方說明安裝並登入 Claude Code。工具版本與安裝指令可能更新，正式發布文章時應再次核對官方文件。
2. 串接可信任的 Meta 資料工具
若希望 Skill 讀取即時帳號資料，可先完成 Meta 官方 Ads MCP Server 或公司核准工具的授權。Meta Ads MCP 是受權限控制的遠端 Server，實際可用工具仍依帳號開放狀態與授權範圍而定。
延伸閱讀：Claude MCP 串接 Meta 廣告帳號完整教學
3. 先採最小權限
初次導入建議只開放報表讀取。會建立廣告、暫停項目或修改預算的 Skills，必須預設 dry-run，並在每次寫入前列出帳號、項目 ID、原設定、新設定與影響，交由使用者確認。
4. 準備專案規則
可在 CLAUDE.md 或 Skill 內寫入：
- 廣告帳號與時區
- 幣別與主要轉換事件
- 歸因設定
- 目標 CPA、CPL 或 ROAS
- 品牌語氣與禁用詞
- 資料夾結構
- 哪些動作永遠需要人工批准
不要把 Access Token、密碼或 App Secret 直接寫進 Skill 或 CLAUDE.md。
10 個 Meta 廣告 Skills 一覽
| Skill | 功能 | 預設風險層級 |
|---|---|---|
/spy | 競品廣告情報蒐集 | 讀取公開資料 |
/bulk-creative | 大量素材與文案變體 | 產生本機檔案 |
/deploy-ads | 批次建立廣告 | 高，會寫入帳號 |
/bleed-check | 高花費低轉換警示 | 中至高，可能暫停 |
/fatigue-scan | 素材疲乏分析 | 唯讀 |
/rebalance | 預算重分配建議 | 高，可能改預算 |
/setup-capi | CAPI 實作與測試範本 | 技術與隱私風險 |
/hooks | Hook 與文案變體 | 內容產出 |
/audience-audit | 受眾與排除架構稽核 | 唯讀 |
/weekly-report | 每週成效報告 | 唯讀 |
以下每一段程式碼，皆可存成對應資料夾中的 SKILL.md。
1. /spy：競品廣告情報蒐集
蒐集指定競品可公開取得的廣告，與上次資料比較後，整理 Hook、CTA、優惠與創意角度。需要注意的是，Meta Ads MCP 不一定提供任意競品的 Ad Library 查詢，因此 Prompt 先要求 Claude 盤點工具能力，避免虛構資料。
SKILL.md 完整 Prompt
---
name: spy
description: 蒐集並比較競品的 Meta 廣告素材，整理新上線、停止投放、溝通角度、Hook、CTA 與可測試方向。適合競品研究、創意會議與素材 Brief。
compatibility: 需要 Claude Code；如要讀取即時資料，需另有可查詢 Meta Ad Library 或競品廣告資料的工具。Meta Ads MCP 未必提供競品 Ad Library 查詢。
---
# 競品廣告情報蒐集
使用者參數：`$ARGUMENTS`
## 任務目標
針對使用者指定的競品、品牌或 Facebook 粉絲專頁，整理目前可取得的廣告情報，並與既有基準資料比較。最後輸出可供行銷與素材團隊直接使用的競品報告。
## 安全與真實性規則
1. 先盤點目前可用工具，確認是否真的能查詢 Meta Ad Library、公開廣告資料或使用者提供的匯出檔。
2. Meta Ads MCP 主要用於已授權廣告資產，不得因已連接 Meta Ads MCP，就假設能查詢任意競品。
3. 若工具不支援競品查詢，停止資料抓取，清楚列出缺少的工具或資料，不得虛構廣告、投放時間、花費或曝光。
4. 不得推測競品實際受眾、預算、轉換或 ROAS，除非資料來源明確提供。
5. 只分析公開廣告內容，不嘗試繞過登入、權限或平台限制。
## 參數解析
從 `$ARGUMENTS` 解析：
- `--competitors`：競品名稱、粉專網址、粉專 ID 或帳號，一個以上。
- `--country`：投放國家，預設 `TW`。
- `--since`：本次觀察起始日，可省略。
- `--baseline`：上次資料檔路徑，預設 `./reports/spy-baseline.json`。
- `--save-baseline`：是否將本次完整結果存成下一次比較基準。
- `--output`：報告路徑，預設 `./reports/spy-YYYY-MM-DD.md`。
若缺少競品清單，只詢問一次最必要的資訊，不自行挑選品牌。
## 執行流程
1. 列出可用資料來源與可查欄位。
2. 對每個競品取得目前可用的廣告資料，至少保留：品牌／粉專、廣告識別資訊、主文、標題、CTA、素材類型、開始投放日期、來源連結。
3. 若有 baseline：
- 以穩定識別資訊比對新廣告、持續投放廣告與停止出現的廣告。
- 若無可靠 ID，改用文案、素材網址與日期組合比對，並標註可能誤判。
4. 分析每則新廣告：
- Hook 類型：問題、利益、數字、反常識、優惠、見證、情境等。
- 溝通角度：痛點、解法、產品特色、比較、社會證明、促銷、品牌形象等。
- CTA、優惠形式、素材格式與推測的漏斗階段。
5. 統整跨競品趨勢：只有兩個以上競品同時出現相似方向，才標示為「共同趨勢」。
6. 提出 3–5 個可供自家品牌測試的方向，但不得直接抄寫競品文案或視覺。
7. 將完整資料寫入指定報告；只有使用者指定 `--save-baseline` 時才更新基準檔。
## 輸出格式
依序輸出：
1. 本次資料來源與限制
2. 摘要：競品數、取得廣告數、新增數、停止出現數
3. 新廣告表格：競品｜Hook｜CTA｜優惠｜角度｜格式｜開始日期｜來源
4. 持續投放與停止出現項目
5. 共同趨勢
6. 建議測試方向
7. 無法確認與需人工核對事項
## 完成條件
- 每一項結論都能追溯到資料來源。
- 未支援的欄位明確標記為無法取得。
- 不把「停止出現在本次查詢」直接寫成「已確認停投」。使用範例
/spy --competitors="品牌A,品牌B" --country=TW --save-baseline2. /bulk-creative：大量素材變體產生
把一份 Brief 拆成可測試的 Hook、CTA、視覺與尺寸矩陣，輸出文案 CSV、素材 manifest，必要時再透過本機模板渲染圖片。
SKILL.md 完整 Prompt
---
name: bulk-creative
description: 將一份 Meta 廣告創意 Brief 拆成多組標題、主文、CTA、版型與尺寸組合，產生素材規格表、文案清單及可供批次製作的 manifest。
compatibility: 需要 Claude Code 的檔案與程式執行能力。實際輸出圖片時，專案需具備可用的模板與渲染工具。
---
# Meta 廣告大量素材變體產生
使用者參數：`$ARGUMENTS`
## 任務目標
根據使用者提供的產品、受眾、優惠、品牌規範與素材資產，建立可供 Meta 廣告測試的大量素材變體。重點是建立有控制的測試矩陣，而不是把所有元素隨機排列。
## 安全與品質規則
1. 不得杜撰產品功效、價格、折扣、認證、客戶見證或數據。
2. 醫療、金融、保健、減重、就業、住房等敏感產業，先標示需人工法遵審核。
3. 若缺少品牌 Logo、產品圖或字型，不得宣稱已完成正式素材；可使用明確標示的 placeholder。
4. 每個變體最多改動一至兩個主要變因，避免無法判斷成效差異來源。
5. 所有文字需檢查錯字、禁用詞、版面溢出與 Meta 廣告政策風險。
## 參數解析
從 `$ARGUMENTS` 解析：
- `--brief`：產品、主要利益、優惠、受眾、情境與目標。
- `--count`：變體數量，預設 30，最高 200。
- `--formats`：預設 `1:1,9:16,1.91:1`。
- `--assets`：產品圖、Logo、背景圖所在目錄。
- `--brand-guide`：品牌規範或檔案路徑。
- `--output-dir`：預設 `./creatives/generated/`。
- `--render`：是否實際執行圖片渲染；未指定時只建立規格與 manifest。
## 執行流程
1. 解析 Brief，列出已知資訊與缺少資訊。
2. 建立測試假設，至少包含：
- Hook：痛點、利益、情境、數字、見證、反常識。
- 訴求：功能、結果、便利、價格、信任、稀缺。
- CTA：依活動目標選擇，不使用與落地頁不符的 CTA。
- 視覺：產品主視覺、人物情境、比較圖、資訊卡、UGC 感等。
3. 先產生一份「測試矩陣」，定義每批素材要驗證的變因。
4. 產生每個素材的：素材名稱、尺寸、主文、標題、說明、CTA、視覺規格、測試變因、落地頁。
5. 產生 `creative-manifest.json` 與 `creative-copy.csv`。
6. 若指定 `--render`：
- 先檢查模板、依賴與資產是否存在。
- 建立可重現的模板與渲染腳本。
- 每張圖渲染後檢查尺寸、文字溢出、透明背景與檔名。
- 失敗的變體記錄錯誤，不以空白檔冒充完成。
7. 產生人工審稿清單與首批建議測試組，不建議一次把所有變體全部上線。
## 輸出格式
1. Brief 摘要與假設
2. 測試矩陣
3. 素材清單表格
4. 產出檔案位置
5. 首批建議測試的 6–12 組素材
6. 人工檢查事項與政策風險
## 完成條件
- 每個變體可追溯到明確測試假設。
- 沒有未經證實的宣稱。
- manifest、CSV 與實際檔名一致。使用範例
/bulk-creative --brief="產品、受眾、優惠與目標" --count=30 --formats="1:1,9:16"3. /deploy-ads：Meta 廣告批次部署
讀取 manifest 後先做 dry-run，確認帳號、預算、資產、追蹤與排程。即使輸入 execute，Prompt 仍要求在當次對話再次人工確認，且首次建立一律保持 PAUSED。
SKILL.md 完整 Prompt
---
name: deploy-ads
description: 檢查廣告部署 manifest，建立 Meta Campaign、Ad Set 與 Ad 的部署計畫；經明確確認後，才以暫停狀態建立廣告。
compatibility: 需要已授權且具建立廣告權限的 Meta Ads MCP。正式帳號預設只允許 dry-run 與 PAUSED 建立。
---
# Meta 廣告批次部署
使用者參數：`$ARGUMENTS`
## 任務目標
讀取指定 manifest，驗證廣告結構、資產、預算與追蹤設定，先產出 dry-run 部署計畫。只有使用者在目前對話中明確確認後，才允許呼叫 Meta Ads MCP 建立物件。
## 強制安全規則
1. 預設永遠是 `dry-run`，不得因使用者只輸入 `/deploy-ads` 就建立任何內容。
2. 即使參數包含 `--execute`，仍須先列出將建立的帳號、Campaign、Ad Set、Ad、預算、幣別、狀態與追蹤設定，等待使用者明確確認。
3. 第一次執行及批次部署一律建立為 `PAUSED`。除非使用者在建立完成後另行指定並再次確認，不得設為 ACTIVE。
4. 不建立刪除、覆寫或修改既有線上廣告的動作。
5. 廣告帳號 ID、粉專、Instagram 帳號、Pixel／Dataset、轉換事件、幣別與時區有任何一項無法確認，就停止執行。
6. 不在檔案或回覆中輸出存取權杖、Cookie 或密碼。
## 參數解析
- `--manifest`：必填，JSON 或 YAML 檔案。
- `--account`：目標廣告帳號名稱或 ID。
- `--mode`：只接受 `dry-run` 或 `execute`，預設 `dry-run`。
- `--status`：預設且建議固定為 `PAUSED`。
- `--output`：預設 `./reports/deploy-YYYY-MM-DD-HHmm.md`。
## 驗證流程
1. 讀取 manifest 並驗證必要欄位。
2. 確認目標帳號名稱、ID、幣別、時區與可用資產。
3. 檢查：
- Campaign objective 與 buying type。
- 特殊廣告類別。
- Ad Set 的優化事件、出價、預算、排程、地區、年齡、受眾、版位。
- Ad 的粉專、IG 身分、素材、文案、CTA、網址、UTM、追蹤資料集。
4. 檢查名稱是否重複、預算單位是否正確、日期是否為未來且符合帳號時區。
5. 計算預計建立物件數與總日預算／總預算。
6. 輸出 dry-run 計畫與阻擋問題。
## 執行流程
只有在所有阻擋問題已排除，且使用者明確回覆同意部署後：
1. 再次確認目標帳號與建立狀態為 PAUSED。
2. 依 Campaign → Ad Set → Creative／Ad 順序建立。
3. 每建立一個物件立即記錄 ID、名稱、父層 ID 與工具回應。
4. 任一 Campaign 建立失敗時，不建立其下層物件。
5. 單一 Ad 失敗時，記錄後繼續其他獨立項目，不重複建立成功項目。
6. 最後重新讀取已建立物件，核對名稱、狀態、預算與數量。
## 輸出格式
1. Dry-run 摘要
2. 帳號與資產核對
3. 建立清單
4. 預算與排程
5. 警告與阻擋問題
6. 執行確認句
7. 執行後 ID、狀態、錯誤與需人工檢查事項
## 完成條件
- 沒有明確確認就沒有任何寫入。
- 所有建立項目預設為 PAUSED。
- 執行結果可逐項追溯與核對。使用範例
/deploy-ads --manifest=./campaigns/launch.json --account=act_xxx --mode=dry-run4. /bleed-check：廣告燒錢偵測
找出近期花費已高於門檻、但轉換不足的項目。新版 Prompt 不會因為零轉換就直接暫停，而是先檢查歸因延遲、資料完整度與追蹤異常。
SKILL.md 完整 Prompt
---
name: bleed-check
description: 檢查 Meta 廣告近期高花費、低轉換或追蹤異常項目，產生燒錢警示；預設只回報，不自動暫停。
compatibility: 需要已授權的 Meta Ads MCP。若要暫停廣告，需具寫入權限並在當次對話取得明確確認。
---
# Meta 廣告燒錢檢查
使用者參數：`$ARGUMENTS`
## 任務目標
找出近期可能持續消耗預算、但沒有產生足夠成果的 Campaign、Ad Set 或 Ad。先排除資料未完整回傳、歸因延遲與追蹤異常，再提出分級處理建議。
## 強制安全規則
1. 預設 `report-only`，不得自動暫停、調整預算或關閉廣告。
2. 必須先確認帳號時區、幣別、主要轉換事件與歸因設定。
3. 今天或最近數小時的資料可能不完整，不得只因零轉換直接判定廣告失效。
4. 若 Meta Ads MCP 不支援小時級資料，使用最小可用完整區間，並清楚標示限制。
5. 只有在使用者看到待處理清單、項目 ID 與理由後明確確認，才可暫停指定項目。
6. 暫停前再次確認不是學習期、低量高客單、名單延後成交或轉換追蹤故障。
## 參數解析
- `--account`：廣告帳號名稱或 ID。
- `--window`：預設最近 1 個完整日；可輸入 `6h`、`24h`、`3d`。
- `--spend-threshold`：花費門檻及幣別。
- `--conversion-floor`：主要轉換最低數量。
- `--cpa-ceiling`：可接受 CPA 上限，可省略。
- `--level`：`campaign`、`adset`、`ad`，預設 `adset`。
- `--mode`：`report-only` 或 `pause-confirmed`，預設前者。
## 執行流程
1. 列出本次查詢條件：帳號、區間、時區、幣別、層級、轉換事件、歸因。
2. 讀取有效投放中的項目及花費、曝光、點擊、CTR、CPC、CPM、轉換、CPA、ROAS、頻次與投放狀態。
3. 驗證資料完整度：
- 區間是否包含尚未結束的今天。
- 轉換事件是否有回傳。
- 是否有明顯整體追蹤斷點。
4. 依條件分級：
- 紅色：高於花費門檻且低於轉換門檻，並有足夠點擊或曝光。
- 黃色：接近門檻、資料量不足或可能受歸因延遲影響。
- 灰色：資料異常，應先查追蹤而不是停廣告。
5. 每個項目列出數據事實、可能原因、需人工確認事項與建議動作。
6. 若使用者要求執行暫停，先回報項目名稱、ID、目前狀態與原因，等待明確確認；只暫停被確認的項目。
7. 將檢查與任何執行結果寫入 `./logs/bleed-check.log` 或指定報告。
## 輸出格式
1. 查詢條件與資料限制
2. 紅色警示表
3. 黃色觀察表
4. 追蹤異常表
5. 建議：保留、觀察、降預算、換素材、暫停、查追蹤
6. 若需執行，列出待確認清單
## 完成條件
- 事實與推論分開。
- 不以不完整資料直接停廣告。
- 寫入動作逐項取得確認。使用範例
/bleed-check --account=act_xxx --window=24h --spend-threshold="3000 TWD" --conversion-floor=05. /fatigue-scan：素材疲乏監控
比較前後期間的 CTR、CPM、頻次、CPA／ROAS 與影片前段觀看，將素材分為高風險、中風險、低風險與資料不足，並為高風險素材產生替換 Brief。
SKILL.md 完整 Prompt
---
name: fatigue-scan
description: 分析 Meta 廣告素材的 CTR、CPM、頻次、影片前段觀看與轉換趨勢，找出素材疲乏風險並產生替換 Brief。
compatibility: 需要已授權的 Meta Ads MCP 與足夠的歷史成效資料。
---
# Meta 廣告素材疲乏掃描
使用者參數：`$ARGUMENTS`
## 任務目標
以時間趨勢而非單一數字，判斷目前投放中的素材是否出現疲乏、受眾飽和或成本惡化，並提供可執行的替換方向。
## 分析規則
1. 先區分靜態圖、輪播、一般影片與 Reels，不對所有格式套用相同指標。
2. Hook Rate 必須先說明定義；若工具沒有 3 秒觀看或等效指標，不自行捏造。
3. 至少有 7 天資料或足夠花費才做趨勢判斷；樣本不足標示為「資料不足」。
4. 頻次高不必然代表疲乏，需搭配 CTR、CPM、CPA／ROAS 與受眾規模。
5. 不因單日波動直接判定高風險。
## 參數解析
- `--account`：廣告帳號。
- `--lookback`：預設 14 個完整日。
- `--compare`：預設前 7 日對後 7 日。
- `--min-spend`：最低納入花費及幣別。
- `--frequency-warning`：頻次警戒值，預設 4，但依投放目的調整。
- `--ctr-drop`：CTR 下滑警戒百分比，預設 15%。
- `--cpm-rise`：CPM 上升警戒百分比，預設 30%。
- `--output`：報告路徑。
## 執行流程
1. 確認日期、時區、幣別、歸因與主要轉換事件。
2. 取得所有有效投放素材及每日成效。
3. 計算兩段期間的花費、曝光、CTR、CPM、CPC、頻次、轉換、CPA、ROAS；影片另計可取得的前段觀看指標。
4. 判斷：
- 高風險：多項指標持續惡化，或 CTR 明顯下降且頻次／CPM 同步上升。
- 中風險：單一主要指標惡化、接近門檻或樣本剛達最低量。
- 低風險：指標穩定或改善。
- 資料不足：無法形成可靠趨勢。
5. 對高風險素材分析原始 Hook、主訴求、視覺形式與 CTA。
6. 為每個高風險素材產生替換 Brief：保留元素、應更換元素、3 個新 Hook、2 個視覺方向、測試假設。
7. 不直接暫停或替換線上廣告。
## 輸出格式
1. 帳號素材健康摘要
2. 高風險素材表：素材｜花費｜CTR 變化｜CPM 變化｜頻次｜CPA／ROAS 變化｜理由
3. 中風險與資料不足項目
4. 每個高風險素材的替換 Brief
5. 建議優先製作順序
6. 分析限制
## 完成條件
- 每個疲乏判斷至少有兩個指標或明確趨勢支持。
- 靜態與影片採不同可用指標。
- 替換建議不是單純改顏色，而是對應成效問題。使用範例
/fatigue-scan --account=act_xxx --lookback=14 --min-spend="3000 TWD"6. /rebalance：預算重新分配
依 KPI、轉換量、預算型態與近期穩定度提出保守及標準兩套配置。預設只輸出計畫，不會因 ROAS 排名直接修改預算。
SKILL.md 完整 Prompt
---
name: rebalance
description: 依 Meta 廣告的花費、轉換、CPA、ROAS 與預算型態產生預算重分配建議；預設不執行異動。
compatibility: 需要已授權的 Meta Ads MCP。實際調整預算需寫入權限與當次人工確認。
---
# Meta 廣告預算重分配
使用者參數：`$ARGUMENTS`
## 任務目標
比較各 Campaign 或 Ad Set 的成效與可用樣本，提出保守、可解釋的預算調整方案。不得只按 ROAS 排名機械式移動預算。
## 強制安全規則
1. 預設只產出計畫，不修改預算。
2. 先確認使用 Campaign Budget、Ad Set Budget、Advantage Campaign Budget 或其他預算型態；不可對無法直接編輯的層級硬改。
3. 需納入轉換量、學習狀態、歸因延遲、毛利／名單品質等資料限制。
4. 單次建議增減幅預設不超過 20%；超過需說明理由並另行確認。
5. 不將零轉換但樣本不足的項目直接歸類為失敗。
6. 使用者明確確認前，不呼叫任何預算寫入工具。
## 參數解析
- `--account`：廣告帳號。
- `--lookback`：預設最近 7 個完整日。
- `--compare`：可指定前一期。
- `--target`：目標 ROAS、CPA、CPL 或其他主要 KPI。
- `--min-spend`：最低納入花費。
- `--max-change`：單次最大變動百分比，預設 20%。
- `--total-budget`：是否維持總預算不變，預設 `true`。
- `--mode`：`plan` 或 `execute-confirmed`，預設 `plan`。
## 執行流程
1. 確認帳號、日期、時區、幣別、歸因與 KPI。
2. 讀取各層級預算型態、目前預算、花費、轉換量、CPA、ROAS、頻次及狀態。
3. 建立帳號基準，但同時保留使用者提供的商業目標；不得只用帳號平均取代目標。
4. 分類：
- 可增加：達標、轉換量足夠、近期穩定且未顯示明顯疲乏。
- 可降低：明顯未達標且樣本足夠。
- 保持：接近目標、學習中或需要更多資料。
- 不可判斷：追蹤、資料量或預算型態不適合。
5. 產生兩套方案：
- 保守方案：每項 5–10% 變動。
- 標準方案：不超過 `--max-change`。
6. 計算調整前後預算與總額，確認不超出使用者指定總預算。
7. 提出預期影響，但明確標示為估計，不保證成效。
8. 若要執行：先列出每個 ID、舊預算、新預算、變動比例與原因，等待明確確認後逐項修改，再回讀核對。
## 輸出格式
1. 資料條件與限制
2. 帳號基準
3. 分類表
4. 保守方案
5. 標準方案
6. 不建議調整項目
7. 執行前確認清單或執行後紀錄
## 完成條件
- 調整計畫符合預算型態與總額限制。
- 每項增減都有數據與商業理由。
- 寫入前取得逐項確認。使用範例
/rebalance --account=act_xxx --lookback=7 --target="ROAS 3" --max-change=207. /setup-capi：Conversions API 建置助手
依網站平台產生 CAPI 實作範本、事件對應、event_id 去重、環境變數、測試與部署文件。程式碼仍需開發與隱私審核，不能直接視為正式環境完成品。
SKILL.md 完整 Prompt
---
name: setup-capi
description: 根據網站技術環境規畫並產生 Meta Conversions API 實作範本、事件對應、去重、測試與部署文件。
compatibility: 需要 Claude Code 的程式與檔案工具。若要讀取 Meta Dataset 或測試事件狀態，需已授權的 Meta Ads MCP。
---
# Meta Conversions API 建置助手
使用者參數：`$ARGUMENTS`
## 任務目標
依使用者的技術架構建立可審查、可測試的 CAPI 實作範本，包含事件來源、使用者資料正規化與雜湊、browser/server 去重、錯誤處理及測試說明。
## 強制安全與隱私規則
1. 不把 Access Token、App Secret、Webhook Secret、個資或真實訂單資料寫進程式碼、範例或版本控制。
2. 所有憑證使用環境變數，並建立 `.env.example`，不得建立含真實值的 `.env`。
3. 只傳送 Meta 允許且有合法基礎蒐集的使用者資料；不自行擴大追蹤範圍。
4. 對 email、phone、姓名等需依規範正規化後 SHA-256 雜湊；IP、User-Agent、`fbp`、`fbc` 依官方要求處理。
5. Browser Pixel 與 Server Event 必須使用相同 `event_id` 去重。
6. 產生的程式是實作範本，正式上線前必須由開發、法務／隱私與行銷共同測試。
## 參數解析
- `--platform`：`shopify`、`woocommerce`、`node`、`python`、`php`、`custom`。
- `--events`：例如 `PageView,ViewContent,AddToCart,InitiateCheckout,Purchase,Lead`。
- `--dataset`：Dataset／Pixel ID；可先使用 placeholder。
- `--currency`：預設依商店幣別。
- `--test-code`：測試事件代碼，僅在測試環境使用。
- `--output-dir`：預設 `./capi-implementation/`。
缺少平台或事件時，先要求最必要資訊；不得替使用者自行決定轉換定義。
## 執行流程
1. 盤點目前網站、後端、付款、訂單與 browser pixel 架構。
2. 建立事件對應表：事件名稱、觸發時機、來源資料、event_id、value、currency、content_ids、必要 user_data。
3. 建立核心事件傳送模組，包含：
- 資料正規化與雜湊函式。
- event_time、action_source、event_source_url、event_id。
- 逾時、重試、錯誤紀錄，但避免重送造成重複計算。
4. 依平台產生 webhook／route／handler 範本，驗證簽章並快速回應來源平台。
5. 產生 browser pixel 的 eventID 對應範例及去重說明。
6. 建立 `.env.example`、README／SETUP、測試腳本與部署檢查表。
7. 測試模式只使用測試資料；若 MCP 支援，讀取測試事件或 Dataset 狀態並記錄回應。
8. 驗證：事件格式、去重、幣別、value、延遲、重送、同意管理及資料最小化。
## 輸出格式
1. 架構與前提
2. 事件對應表
3. 產生的檔案清單
4. 安裝與環境變數
5. 去重機制
6. 測試步驟與預期結果
7. 隱私與上線檢查表
8. 尚未確認事項
## 完成條件
- 不包含真實憑證或個資。
- 每個事件都有清楚觸發點與 event_id。
- 提供可驗證的測試方法，而非只生成程式碼。使用範例
/setup-capi --platform=shopify --events="ViewContent,AddToCart,Purchase" --dataset=1234567898. /hooks：Hook 與廣告文案變體
從一個產品賣點或勝出角度產生不同框架、情緒與認知階段的文案，並標記測試變因，避免只是換同義詞。
SKILL.md 完整 Prompt
---
name: hooks
description: 從一個 Meta 廣告主訴求產生多組 Hook、主文、標題、說明與 CTA，依文案框架和受眾認知階段整理成測試清單。
compatibility: 可單獨使用 Claude Code；如需參考既有廣告成效，需已授權的 Meta Ads MCP。
---
# Meta 廣告 Hook 與文案變體
使用者參數：`$ARGUMENTS`
## 任務目標
把一個已知產品賣點、素材角度或既有勝出文案，延伸成可控制、可比較的 Meta 廣告文案測試組，而不是產生大量語意重複的句子。
## 品質與法遵規則
1. 不杜撰功效、數據、評價、名人推薦、優惠或稀缺性。
2. 不直接複製競品文案。
3. 避免直接斷言使用者具有敏感個人屬性或健康狀況。
4. 依品牌規範使用語氣、標點、禁用詞與台灣用語。
5. 每組文案標示主要測試變因，確保能解讀成效。
6. 字數限制以實際版位與需求為準；若使用者未提供，提供精簡版與完整版本，不宣稱平台絕對上限。
## 參數解析
- `--seed`：核心賣點、原始 Hook 或勝出角度。
- `--product`：產品或服務資訊。
- `--audience`：受眾、情境、認知階段與痛點。
- `--goal`：銷售、名單、流量、互動或其他目標。
- `--frameworks`：預設 `PAS,AIDA,BAB,pattern-interrupt,social-proof,curiosity`。
- `--count`：預設 30，最高 100。
- `--brand-guide`：品牌規範或路徑。
- `--output`：預設 `./creatives/hooks-YYYY-MM-DD.csv`。
## 執行流程
1. 先整理已確認事實：產品、功能、利益、證據、優惠、限制與 CTA。
2. 分析 seed 的核心角度與受眾認知階段。
3. 建立文案測試矩陣，至少涵蓋：
- 框架：PAS、AIDA、BAB、反差、情境、社會證明、好奇。
- 情緒：安心、期待、效率、損失避免、幽默、急迫。
- 視角：第二人稱、第一人稱經驗、客觀資訊。
4. 平均分配數量，避免某一框架佔比過高。
5. 每組產生：
- `primary_text`
- `headline`
- `description`
- `cta`
- `framework`
- `awareness_stage`
- `emotional_register`
- `test_variable`
- `policy_note`
6. 檢查文案是否語意重複、宣稱無依據、與落地頁不一致或可能違規。
7. 選出 5–10 組首測文案，說明選擇理由；不要宣稱哪一組必然勝出。
8. 輸出 CSV 與 Markdown 預覽。
## 輸出格式
1. 已確認事實與限制
2. 測試矩陣
3. 完整文案表
4. 首測推薦組
5. 法遵與人工確認事項
6. 產出檔案位置
## 完成條件
- 文案變體有實質差異。
- 所有宣稱可由 Brief 或來源支持。
- 產出能直接交給素材與投放人員審稿。使用範例
/hooks --seed="核心賣點" --product="產品資訊" --audience="受眾與情境" --count=309. /audience-audit：受眾架構稽核
盤點自訂受眾、類似受眾、Ad Set targeting 與排除規則，整理冷暖受眾漏斗及可能互搶的地方。若工具沒有實際重疊率，報告只會標示邏輯風險，不冒充量測數據。
SKILL.md 完整 Prompt
---
name: audience-audit
description: 盤點 Meta 廣告帳號的自訂受眾、類似受眾、廣告組合受眾與排除規則，分析漏斗配置、重疊風險與缺口。
compatibility: 需要已授權的 Meta Ads MCP。部分受眾規模或重疊資料可能因平台限制無法取得。
---
# Meta 受眾架構稽核
使用者參數：`$ARGUMENTS`
## 任務目標
整理廣告帳號目前使用的受眾及排除規則，辨識冷受眾、暖受眾、再行銷與既有客戶之間可能互搶、漏排或配置不一致的情況，提出新的受眾架構。
## 分析與真實性規則
1. 明確區分「API／MCP 可確認的設定」與「依設定推論的重疊風險」。
2. 若工具未提供實際 Audience Overlap 百分比，不得寫成已量測的重疊率。
3. 受眾規模小不等於一定無效；需搭配目標、預算與成效。
4. 不直接修改受眾、排除條件或線上 Ad Set。
5. 特殊廣告類別與隱私限制需另行標示，不提出不允許的 targeting 建議。
## 參數解析
- `--account`：廣告帳號。
- `--include-paused`：是否納入暫停項目。
- `--lookback`：成效參考期間，預設 30 個完整日。
- `--goal`：主要業務目標與轉換事件。
- `--output`：預設 `./reports/audience-audit-YYYY-MM-DD.md`。
## 執行流程
1. 讀取可取得的 Custom Audience、Lookalike Audience 與相關資訊。
2. 讀取 Campaign／Ad Set 的 targeting、地區、年齡、排除條件、優化事件、預算及成效。
3. 依實際用途分類：
- Prospecting／冷受眾
- Consideration／暖受眾
- Retargeting／高意圖
- Existing Customer／留存與再購
4. 檢查：
- 冷受眾是否排除近期購買者與高意圖再行銷受眾。
- 多個同時投放 Ad Set 是否具有相近地區、目標、素材與受眾邏輯。
- 再行銷視窗是否重複或漏接。
- 類似受眾種子是否合理、是否過度細分。
- 既有客戶是否被錯誤納入新客活動。
5. 風險分級：高、中、低，並標示「設定可確認」或「邏輯推論」。
6. 產生建議架構：每一層的受眾、排除、視窗、目標與命名規則。
7. 產生簡化 Mermaid 圖；節點過多時只畫建議架構，不強行塞入所有 Ad Set。
8. 提出需人工在 Ads Manager 驗證的項目。
## 輸出格式
1. 稽核範圍與資料限制
2. 目前受眾資產表
3. 漏斗對應表
4. 重疊／互搶風險表
5. 缺少排除清單
6. 建議受眾架構與 Mermaid 圖
7. 優先處理順序
8. 人工驗證事項
## 完成條件
- 不把推論冒充實際重疊數據。
- 每個建議都指出對應的現況問題。
- 不直接改動線上投放設定。使用範例
/audience-audit --account=act_xxx --include-paused --lookback=3010. /weekly-report：每週廣告成效報告
固定查詢日期、時區、幣別、歸因與轉換事件，整理本期與前期的帳號、Campaign、Ad Set、Ad 成效，再將數據事實、分析推論與行動建議分開。
SKILL.md 完整 Prompt
---
name: weekly-report
description: 讀取 Meta 廣告最近完整期間與比較期間的帳號、Campaign、Ad Set、Ad 成效，產生週報、異常摘要與下一步建議。
compatibility: 需要已授權的 Meta Ads MCP 與報表讀取權限。
---
# Meta 廣告每週成效報告
使用者參數：`$ARGUMENTS`
## 任務目標
產生可供主管、顧問與投放人員使用的 Meta 廣告週報。報告必須固定查詢條件、區分數據事實與分析推論，並指出資料限制。
## 報表規則
1. 優先使用「完整日」，除非使用者明確要求包含今天。
2. 必須先確認帳號、時區、幣別、日期、歸因設定與主要轉換事件。
3. 本期與比較期需使用相同欄位、層級、篩選與歸因。
4. 除百分比變化外，也提供絕對值，避免小基數造成誤導。
5. CPA、ROAS 或轉換為零時，正確處理除以零，不輸出無意義百分比。
6. 報告只提供建議，不修改任何廣告。
## 參數解析
- `--account`：廣告帳號名稱或 ID。
- `--period`：預設最近 7 個完整日；可輸入日期區間。
- `--compare`：預設前 7 個完整日。
- `--timezone`：預設使用帳號時區；可指定 `Asia/Taipei`。
- `--conversion`：主要轉換事件。
- `--target`：目標 CPA／CPL／ROAS，可省略。
- `--levels`：預設 `account,campaign,adset,ad`。
- `--top-n`：預設 5。
- `--output-dir`：預設 `./reports/`。
## 執行流程
1. 列出查詢設定並確認可讀取的廣告帳號。
2. 取得本期與比較期的帳號層級指標：花費、曝光、觸及、頻次、點擊、CTR、CPC、CPM、主要轉換、CPA、轉換價值、ROAS。
3. 取得 Campaign、Ad Set、Ad 層級相同欄位。
4. 計算絕對差與百分比變化，標示基數過小或無法計算的項目。
5. 找出：
- 花費與成果貢獻最高項目。
- 成效改善最大項目。
- 高花費低成果項目。
- 素材疲乏、CPM 異常、追蹤疑慮或資料缺口。
6. 產生健康燈號：
- 綠：達成使用者目標且主要指標穩定。
- 黃：接近目標、單一重要指標惡化或資料不足。
- 紅：明顯未達目標且有足夠樣本，或追蹤資料異常。
若未提供目標，不得武斷給綠／黃／紅；改用「改善、持平、惡化」。
7. 提出 3–5 個下一步，每項引用具體 Campaign／Ad Set／Ad 名稱與數據。
8. 輸出完整 Markdown；若有 Slack／郵件工具，只建立摘要草稿，不自動發送，除非使用者明確要求。
## 輸出格式
1. 報表條件
2. 一頁摘要
3. 帳號 KPI 本期／前期比較表
4. Campaign 表
5. Ad Set 表
6. 素材表
7. 贏家、觀察與異常
8. 數據事實
9. 分析推論
10. 下週行動建議
11. 資料限制與人工核對項目
## 完成條件
- 日期與比較區間都是明確完整日。
- 所有層級使用一致條件。
- 事實、推論與建議分開呈現。
- 不做任何帳號寫入。使用範例
/weekly-report --account=act_xxx --period=last_7_complete_days --compare=previous_7_days --conversion=Purchase如何一次安裝這 10 個 Skills？
在專案根目錄建立資料夾：
mkdir -p .claude/skills再建立各 Skill 資料夾：
.claude/skills/
├── spy/SKILL.md
├── bulk-creative/SKILL.md
├── deploy-ads/SKILL.md
├── bleed-check/SKILL.md
├── fatigue-scan/SKILL.md
├── rebalance/SKILL.md
├── setup-capi/SKILL.md
├── hooks/SKILL.md
├── audience-audit/SKILL.md
└── weekly-report/SKILL.md儲存後，Claude Code 通常會偵測到 Skill 變更。若本次啟動時原本沒有 Skills 資料夾，可重新啟動 Claude Code，再輸入：
What skills are available?確認 10 個 Skill 是否出現。也可直接輸入 /weekly-report 測試。
建議導入順序
第一階段：先驗證唯讀資料
建議先使用：
/weekly-report
/fatigue-scan
/audience-audit這三個 Skill 不需要修改線上廣告，適合先確認帳號、日期、幣別、歸因及轉換欄位是否與 Ads Manager 一致。
第二階段：建立內容與本機檔案
接著導入：
/hooks
/bulk-creative
/setup-capi
/spy這些工作主要產生文案、程式、報告或素材規格，正式使用前可以人工審查。
第三階段：最後才開放帳號寫入
最後才測試：
/deploy-ads
/bleed-check
/rebalance正式廣告帳號應保留以下防線：
- 預設 dry-run 或 report-only。
- 每次寫入都重述帳號與項目 ID。
- 明確列出原設定與新設定。
- 使用者在目前對話再次確認。
- 建立廣告預設為 PAUSED。
- 寫入後重新讀取並核對。
這些 Skills 可以用在 Codex、Cursor 或其他 AI 工具嗎？
工作流程可以移植，但檔案格式不一定相同。Claude Code 使用 .claude/skills/<name>/SKILL.md；其他工具可能使用自己的 Agent Skills、Rules、Prompt Files 或 Automation 格式。
由於 Claude Code Skills 採用 Agent Skills 開放規格，部分基礎欄位具可攜性；但 Claude Code 特有的工具權限、動態內容與斜線指令行為，不保證能原封不動移到所有工具。
比較實際的作法是保留 Prompt 中的四個核心部分，再依工具改寫包裝：
- 任務目標
- 資料與工具前提
- 安全／人工批准規則
- 輸出格式與完成條件
常見問題
Claude Code Skill 是什麼？
Claude Code Skill 是一組可重複使用的任務說明。你可以把常用的分析步驟、檢查規則、輸出格式與安全限制寫進 SKILL.md，Claude Code 會在適合的情境載入，也能透過斜線指令直接執行。
依 Anthropic 目前文件，建議使用以下結構：
.claude/
└── skills/
└── weekly-report/
└── SKILL.md資料夾名稱會成為指令名稱，所以：
.claude/skills/weekly-report/SKILL.md對應的指令就是：
/weekly-reportHeyOz 原文採用 .claude/commands/weekly-report.md。Anthropic 已將 Custom Commands 併入 Skills，因此舊格式仍可使用；不過新建工作流程時，建議採用 .claude/skills/<skill-name>/SKILL.md，較方便加入模板、腳本與參考檔案。
Skill 與 MCP 有什麼不同？
兩者解決的問題不同：
| 項目 | 主要作用 | Meta 廣告情境 |
|---|---|---|
| MCP | 提供外部資料與可呼叫工具 | 讀取帳號報表、建立廣告、查詢資產或管理資料集 |
| Skill | 規定 Claude 應按照什麼流程完成任務 | 固定週報欄位、素材疲乏門檻、預算調整規則與輸出格式 |
簡單說，MCP 像是 Claude 的資料與操作接口，Skill 則像公司內部 SOP。 只有 Skill、沒有資料工具時，Claude 只能依你提供的檔案工作；只有 MCP、沒有 Skill 時，每次仍要重新說明分析流程。
完成 Meta Ads MCP 串接後，這 10 個 Skills 會自動出現嗎？
不會。MCP 提供的是資料和操作工具，Skill 是你自行建立的工作流程。需要把本文 Prompt 存成對應的 SKILL.md，Claude Code 才會出現 /weekly-report 等指令。
可以只複製 Prompt，不使用 MCP 嗎？
可以，但 Claude 必須有其他資料來源。例如你可以匯出 Meta 報表 CSV，再讓 /weekly-report 分析檔案。沒有 MCP 或報表檔時，Claude 不能取得即時帳號數據。
為什麼 Prompt 沒有寫死 MCP 工具名稱？
不同 MCP Server、帳號權限與版本公開的工具名稱可能不同。本文讓 Claude 先盤點可用工具，再選擇符合任務的工具，可避免 Skill 因工具重新命名而失效。
/bleed-check 可以排程後自動停掉廣告嗎？
技術上可建立排程，但正式帳號不建議在沒有人工確認的情況下自動暫停。轉換回傳延遲、追蹤中斷、低量高客單與學習期，都可能造成錯誤判斷。本文版本預設只回報。
哪一個 Skill 最適合先做？
建議先從 /weekly-report 開始。它能驗證 Meta 資料是否可讀、日期與歸因是否一致，也能立即減少每週整理報表的重複工作。
Skill Prompt 越長越好嗎？
不一定。好的 Skill 需要清楚限制、可驗證步驟與固定輸出，但不應塞入與任務無關的背景。實際使用後，可以根據常見錯誤逐步補規則，而不是一次加入所有可能情境。
總結：先把 Meta 廣告 SOP 寫清楚，再交給 Claude 執行
Claude Code Skills 的價值，不只是把一段 Prompt 存起來，而是把團隊原本依賴個人經驗的工作流程，整理成可重複、可檢查的 SOP。
這 10 個 Skills 涵蓋競品研究、素材產製、廣告部署、燒錢檢查、素材疲乏、預算規畫、CAPI、文案、受眾與週報。導入時不需要一次全部啟用，先從唯讀報表開始，確認數據與權限正確，再逐步開放本機產出與帳號寫入，會更安全也更容易維護。
資料來源
- Anthropic：Extend Claude with skills
- Anthropic：Connect Claude Code to tools via MCP
- Meta for Developers：Ads MCP Server overview
- Meta for Developers：Ads MCP Server available tools
- HeyOz：10 Claude Code Skills for Meta Ads
本文參考 HeyOz〈10 Claude Code Skills for Meta Ads〉提出的 10 種工作流程，再依目前 Claude Code Skills 格式、Meta Ads MCP 的使用方式，以及正式廣告帳號需要的人工確認機制，重新撰寫成繁體中文版本。