社群日曆回顧
每週一次的檢查，形成閉環。它會回顧過去 7 天並展望未來 14 天，然後撰寫一份簡短報告，並提出對驅動 social-calendar 技能的 Markdown 檔案的修改建議。
此技能會讀取 Airtable，但絕不會寫入。除非例行提示另有說明，否則它只會在使用者核准變更後，才修改作戰策略和頻道檔案。
設定
AIRTABLE_TOKEN和AIRTABLE_BASE_ID，需置於環境變數或工作目錄／儲存庫根目錄的.env檔案中。STRATEGY_DIR指向包含strategy.md和channels/的資料夾。若未設定，則會在工作目錄、./my-strategy/和./strategy/中尋找strategy.md。- 主要技能中的日曆腳本：
skills/social-calendar/scripts/airtable_calendar.py（以下簡稱$CAL）。若已連接，Airtable MCP 連接器也可使用。
步驟
1. 載入規則
讀取 strategy.md 和所有活躍頻道的 channels/*.md（使用 python3 $CAL channels）。記錄每個頻道的：目標發布節奏、允許的貼文類型、語調規則、禁用詞彙或主題、Hashtag 規則，以及負責人。同時記錄作戰策略中當前的 OKR 和內容支柱。
如果 $STRATEGY_DIR/reviews/ 中存在上週的回顧報告，請閱讀它，並檢查其通過的修改建議是否已被套用。
2. 回顧過去 7 天
python3 $CAL list --from -7 --to today --json > /tmp/review-past.json
從這份列表中，檢查：
Live貼文。這些是主要檢查對象。Failed和Manual貼文。失敗的貼文是否已修正？有人實際發布了那些手動貼文嗎？- 日期在過去的
To approve、Needs media和Approved貼文。這些是遺漏的核准或未執行的發布。
對每篇 Live 貼文，根據其頻道檔案和作戰策略進行檢查：
- 語調和格式。聽起來像頻道檔案中的範例嗎？長度、Hashtag、連結、表情符號是否符合檔案規定？
- 契合度。是否能服務
strategy.md中的某個支柱或 OKR？該貼文類型是否被該頻道允許？ - 節奏。計算每個頻道的發文數，與目標比較。標記過多或不足的頻道。
- 重複性。同一頻道上幾乎相同的貼文，或同一天在所有頻道上發布的相同訊息。
- 事實。
Source欄位無法佐證的主張、數字和名稱。
僅報告你能指出具體貼文的問題。引用記錄名稱和日期。
3. 展望未來 14 天
python3 $CAL list --from +1 --to +14 --json > /tmp/review-next.json
按頻道和週次，標記：
- 缺口：發布量低於目標節奏的週次。建議從現有內容中（例如有未使用片段的有聲節目、近期文章）填補哪些貼文類型。
- 過載：某個頻道一天超過一篇貼文，或一週內被某一種類型主導（三篇新聞貼文、連續的促銷貼文）。
- 偏離策略的貼文：不符合任何支柱或頻道檔案排除的內容。
- 核准瓶頸：未來 3 天內到期的
To approve貼文，按Owner分組，以便有人可以跟進。 - 未來 7 天內到期的
Needs media貼文，以及各自所需的素材。
4. 盡可能拉取數據
按順序嘗試以下方法，使用任何可用的來源：
- 平台連接器，例如 LinkedIn 連接器或其他分析用 MCP。拉取過去 7 天每篇貼文的曝光、反應、留言、分享和點擊次數，並透過
Live link或日期與頻道來比對到記錄。 - 網路分析連接器（GA4 或類似服務）。拉取本週來自社群推薦來源或帶有 UTM 標籤連結的會話資料。
- 手動匯出：
$STRATEGY_DIR/metrics/中的 CSV 檔案（例如 LinkedIn 頁面分析匯出）。每個頻道使用最新的檔案，並說明你讀取了哪個檔案。
當某個頻道沒有任何上述來源時，寫下「本週無 <頻道> 的數據」然後繼續。絕對不要猜測、推論或憑空捏造數字。即使沒有數據，這份回顧在策略和節奏檢查上仍然有用。
有了數據後，只對同一頻道內的貼文進行比較。尋找至少在 3 篇貼文中重複出現的模式，例如貼文類型、開頭風格、有無媒體、發布於星期幾。單一一篇表現好或壞的貼文不算是一個模式。
5. 撰寫報告
將報告儲存至 $STRATEGY_DIR/reviews/YYYY-MM-DD.md（必要時建立資料夾），並列印出來。保持在一個畫面內：
# Social review, week of 2026-11-02
## Summary
三到五句簡潔的句子。發布了什麼內容、出了什麼問題、值得做出的一項改變。
## Last 7 days
| Channel | Live | Target | Failed | Notes |
|---|---|---|---|---|
具體問題，每項一列，附上記錄名稱和日期。
## Metrics
每個頻道：發現了什麼及其來源，或「本週無 <頻道> 的數據」。
## Next 14 days
缺口、過載、偏離策略的貼文、待跟進的核准（按負責人）、仍需要的媒體素材。
## Proposed changes
編號列表。每項指出檔案名稱、用一句話說明原因，並顯示差異。
6. 提出對作戰策略和頻道檔案的修改建議
僅當本週的證據支持時才提出修改：重複的錯誤、無人遵守的規則、無法維持的節奏，或跨多篇貼文的數據模式。每個建議是針對當前檔案的 unified diff：
--- channels/brightloop-linkedin.md
+++ channels/brightloop-linkedin.md
@@ Cadence @@
-- 5 posts per week, Monday to Friday
+- 4 posts per week, Monday to Thursday. Friday posts got under half the reactions of other days over the last 6 weeks.
不要套用這些差異。列出它們，然後等待使用者決定要套用哪些。僅當例行提示明確允許時，才無需詢問直接套用修改，且僅限於提示中指定的變更類型。即使被允許套用修改，也絕不能未經對方同意就更改他人的頻道檔案。
不要從此技能編輯 Airtable 記錄。如果某篇已排定的貼文需要更改，請說明是哪一篇以及原因。修改由使用者或 social-calendar 技能來執行。
範例行提示
將其設定為每週排程任務或例行工作，例如每週一 08:00，並將儲存庫設為工作目錄：
以過去一週為範圍執行 social-calendar-review 技能。
STRATEGY_DIR 是 ./my-strategy。Airtable 憑證在 .env 檔案中。
如果可用的話，請使用 LinkedIn 連接器取得數據。否則，請為每個頻道讀取
./my-strategy/metrics/ 中最新的 CSV 檔案，並明確指出哪些頻道沒有數據。
將報告儲存至 ./my-strategy/reviews/，並將 Summary 和 Proposed changes
這兩個章節發布到 Slack 的 #marketing 頻道。
不要套用任何提出的修改。我會回覆我想要套用的編號。
若要讓例行任務自行處理小幅修正，請將最後一行替換為類似「你可以對我自己的頻道檔案中的 Hashtag 清單和發布日期提出修改建議。其餘的則保持為建議。」的內容。