社群行事曆
將一則內容轉換為多個頻道的貼文，並放入 Airtable 行事曆供人員審核。發佈作業透過 scripts/publish_approved.py 執行，它會將已核准的貼文交給 Upload-Post 的排程器。你只在使用者提出要求時執行此指令稿。
欄位名稱、狀態值與環境變數均來自 repo 中的 docs/data-model.md。請勿重新命名。以下指令稿路徑皆相對於此技能所屬的資料夾。
開始之前
- 確認
AIRTABLE_TOKEN與AIRTABLE_BASE_ID已設定（環境變數或位於工作目錄 / repo 根目錄的.env檔案中）。執行python3 scripts/airtable_calendar.py channels作為一次煙霧測試。若資料表尚未存在，請引導使用者執行 repo 根目錄的scripts/setup_airtable.py。 - 找到策略資料夾。若設定了
STRATEGY_DIR則使用該路徑。否則依序查詢工作目錄下的strategy.md、./my-strategy/與./strategy/。若不存在，詢問策略檔案位置。若使用者尚無策略檔案，提議複製templates/strategy.md與templates/channels/_channel-template.md，並在開始撰寫任何貼文前一起填入內容。
若 Airtable MCP 連接器可用，你亦可使用它來取代指令稿進行讀寫。此文件中的規則仍然適用。詳見 references/airtable.md。
工作流程
1. 讀取策略與頻道檔案
完整讀取 strategy.md：目標、OKR、受眾、內容支柱、全域規則。接著列出 channels/*.md，並閱讀此內容可能投放之頻道的對應檔案。每個頻道檔案包含該帳號的語氣、目標、發文頻率、格式、注意事項以及範例貼文。
將頻道檔案與 Airtable 中的 Channels 資料表列透過 Channel file 欄位進行比對。只有 Airtable 中狀態為 Active 的頻道才能接收貼文。若某頻道檔案找不到對應的 Channels 列，請告知使用者並跳過該頻道。
2. 識別貼文類型與行銷活動
判斷內容的性質：功能發布、新聞、Podcast 或影片片段、客戶評論、活動照片、數據或文字見解、文章推廣，或其他類型。閱讀 references/post-types.md，了解各類型如何轉化為貼文、適合哪些頻道以及應在多大時間範圍內散布。
為此批次賦予一個行銷活動標籤，格式為 YYYY-MM <類型> <標籤>，例如 2026-11 Podcast Ep 12 或 2026-11 Feature CSV export。將原始輸入放入 Source 欄位（連結、檔案名稱、集數或一行備註）。
僅當答案會改變貼文內容時才提問，例如「投放哪些頻道？」（當策略未明確指示時），或「此內容是否有發布時間限制？」。否則自行決定並告知你的決策。
3. 檢視行事曆
列出即將填入時間段內（預設未來 4 週，Podcast 片段則更長）已規劃的內容：
python3 scripts/airtable_calendar.py list --from today --to +28 --json > /tmp/calendar.json
針對每個目標頻道，確定：
- 發文頻率間隔。 每週貼文數相較於頻道檔案目標。計算時排除狀態為
Rejected與Failed的貼文。 - 時間碰撞。 該頻道當日是否已有貼文。預設為每個頻道每天最多一篇貼文，除非頻道檔案另有規定。
- 主題混合。 一週內是否有太多同一類型的貼文（例如三篇新聞、連續兩則促銷）。將新貼文移至較空的一週。
- 重複內容。 相同的訊息是否已排程或近期已發布。
create指令會執行相似度檢查。你也可以單獨使用check-duplicates指令執行此檢查。
4. 草擬貼文
每個頻道、每個日期撰寫一篇貼文。每篇貼文都需遵循對應頻道檔案的規定：語氣、長度、格式、話題標籤、行動呼籲。以下是適用於所有貼文的規則：
- 僅使用來源檔案或策略檔案中的事實。請勿憑空捏造數字、引言、客戶名稱或結果。
- 請勿在不同頻道貼上相同文字。創辦人的個人檔案與公司頁面對同一功能的描述應有所不同。
- 員工與共同創辦人頻道需以該人員的語氣撰寫，並需要他們的核准。將
Owner設為頻道檔案中指定的核可人。 PostContent欄位應包含最終文字，並使用真實的換行符號。Emoji 與 Unicode 皆可使用。話題標籤通常放在內文中，通常位於結尾，依頻道檔案規定。- LinkedIn 與 X 會將
**text**顯示為星號。僅當頻道使用者會將內容貼入支援 Markdown 的編輯器時（例如 Substack），才使用**粗體**。若頻道檔案另有規定，則依其規定。 - 字數限制：X 超過 280 字會自動成串，Threads 為 500，Bluesky 為 300。除非頻道檔案要求使用串文，否則請使貼文符合長度限制。
- 遵循
strategy.md中的寫作規則。若策略檔案中無相關規則，請使用簡潔直接的句子，並避免填充物、空泛詞語與套話。
5. 選擇日期
Scheduled for 僅包含日期，格式為 YYYY-MM-DD。時間來自頻道的 Post time 與 Timezone 欄位，因此請勿在貼文中加入時間。
- 先填補發文頻率間隔，再散布其餘貼文。單一項目的推廣貼文應分散於 2 至 3 週內，而非集中在同一天。
- 新聞應於當天或隔天發布，否則不予發布。
- Podcast 片段約以每個頻道每週一至兩則，持續約 3 個月。
- 將不同類型的貼文混合於一週內：教育、互動、產品、社會證明。
- 切勿使用過去的日期。僅在使用者明確要求且知曉當日排程可能已執行完畢時，才使用「今天」這個日期。
- 若某週已滿，將貼文移至下一週，並於報告中說明。
6. 處理媒體檔案
Airtable 僅能接收公開 URL。本機路徑與 file:// 連結會被默默忽略。批次建立貼文時使用的圖片與影片可以為本機路徑。指令稿會先將它們上傳至 catbox.moe，再將公開 URL 傳遞給 Airtable，Airtable 會將檔案複製到自己的儲存空間。Catbox 的上傳內容是公開且無法刪除的，因此請勿用於任何機密內容。如有此情況，請要求使用者改用其他主機。詳情請見 references/airtable.md。
對於需要視覺元素的文字或數據貼文（例如 Instagram、TikTok 或頻道檔案要求的情況），請製作一張簡單的圖片。請遵循 references/visuals.md。
7. 建立紀錄
將批次內容以 JSON 列表格式寫入，使用 Posts 欄位名稱：
[
{
"Name": "Feature - CSV export",
"Status": "To approve",
"Scheduled for": "2026-11-12",
"Channel": "Brightloop LinkedIn",
"PostContent": "You can now export any report to CSV.\n\nOne click, top right.",
"Media": ["/tmp/csv-export.png"],
"Source": "Release note 2026-11-10",
"Campaign": "2026-11 Feature CSV export",
"Owner": "[email protected]"
}
]
狀態選擇方式如下：
| 情況 | 狀態 |
|---|---|
| 準備好讓擁有者審閱（預設） | To approve |
| Instagram、TikTok、YouTube 或 Pinterest 的貼文尚無媒體 | Needs media |
| 使用者想先來回修改文字 | Draft |
| 使用者明確為自己的頻道核准（見下方說明） | Approved |
先進行模擬執行，向使用者展示計畫，然後再建立：
python3 scripts/airtable_calendar.py create /tmp/batch.json --dry-run
python3 scripts/airtable_calendar.py create /tmp/batch.json
create 指令會驗證欄位名稱、狀態、日期與頻道名稱；將僅限圖片平台中缺乏媒體的貼文降級為 Needs media 狀態；並在偵測到可能的重複內容時拒絕寫入。請修正批次內容，或在使用者確認後傳遞 --allow-duplicates 參數。每次寫入以 10 筆為一批。已儲存在 CSV 中的計畫（包含欄位：Date, Channel, Content Type, Post Text, Hashtags, Image Suggestion）可直接使用 --csv 參數匯入。
8. 回報結果
最後提供一個表格，每個已建立的紀錄佔一列，按日期排序：
| 日期 | 頻道 | 狀態 | 名稱 | 開場白 |
|---|
在表格下方，以簡潔的句子列出：跳過的頻道與原因、延至後續一週的貼文、狀態為 Needs media 的貼文及其所需內容，以及任何需要擁有者檢查的事項（主張、姓名、連結）。
其他請求
- 「為這些貼文加上圖片。」 執行
python3 scripts/airtable_calendar.py attach <record_id> <file or URL>。狀態為Needs media的貼文會自動變更為To approve。 - 「移動這則貼文」、「拒絕那則。」 執行
update <record_id> --set "Scheduled for=2026-11-20"或--set Status=Rejected。若貼文狀態已是Scheduled，則後續需執行python3 scripts/publish_approved.py --sync，以便 Upload-Post 端的副本也同步更新。 - 「這週有哪些貼文要發布？」 執行
list --from today --to +7，並按頻道與日期進行摘要。 - 策略或語氣的變更。 編輯 Markdown 檔案，而非 Airtable。每週的
social-calendar-review技能會負責提出這些編輯建議。
代表使用者核准
僅當使用者明確提出要求（例如「核准我的貼文」、「這些可以直接發布」），且僅針對使用者本人為 Owner 的頻道。絕對不要核准員工或共同創辦人個人檔案的貼文，即使對方隨口提及也不行。請引導使用者去找該人員處理。將這些貼文設為 Approved（可在建立時設定，或使用 update <record_id> --set Status=Approved 指令事後設定），並在報告中將它們獨立列出。
交接給發布程序
當使用者要求排程已核准的貼文時（例如「排程所有已核准的貼文」、「把這些發出去」）：
- 執行
python3 scripts/publish_approved.py --sync --reconcile --mode schedule --dry-run，並顯示它將傳送的內容：頻道、日期與時間、媒體類型、文字第一行。 - 使用者確認後，不加
--dry-run參數再次執行。Upload-Post 會保存排程，貼文狀態將變為Scheduled。 - 若任何已核准貼文的時間段已過，請告知使用者，並提供
--mode now選項。
使用者可能也有例行工作或定時任務正在執行該指令稿，在這種情況下，已核准的貼文會自動被排程，無需你介入。請閱讀 references/publishing.md 以了解重新排程、取消、調節以及完整的欄位對應。優先使用指令稿而非自行呼叫 Upload-Post API，因為指令稿在每次貼文上不會耗費 token。
永遠不要發布或排程任何使用者未在此對話中要求的內容。 建立狀態為 To approve 的貼文紀錄是此技能的正常終結點。