昨天把 intake 盤成了四籃：已確認事實、執行假設、建議、未解事項。但四籃東西攤在桌上還不能開工——得先簽字。這份簽字的東西叫 Brief，今天的核心主張是：Brief 是可核對的契約，不是會議紀錄。會議紀錄記「我們聊了什麼」，契約鎖「我們決定了什麼」；前者出事時人人有解釋空間，後者出事時翻開來對就是了。

拿幾個必填欄位說明為什麼非鎖不可。第一個是 audience：這個系列的讀者被鎖定為「準備參賽、經營技術連載，或想把一次性 AI 協作整理成可重複使用 Agent Skill 的工程師，具備 Git 與命令列基礎，但不預設懂資料契約或 plan hash」。沒有這條，我寫 Day 12 的 Schema 時就得自己猜要不要解釋 JSON 是什麼——猜錯哪邊都是重寫。第二個是 non_goals：「不宣稱 Skill 自己修改了自己」「不虛構經驗與數字」這些禁區寫成白紙黑字之後，我踩線就是違約，不是見解不同。第三個是 publication：iThome 鐵人賽的連續發布規則會影響整個班表，這種外部限制不鎖進契約，30 天排程就是沙上蓋樓。完整欄位定義在 brief.schema.json，SKILL.md 的 Confirm the brief 則規定 Brief 必須分開列出已確認事實、待核准假設、建議與未解事項——四籃直接對應過來，而且這一關明文禁止我先寫正文。

契約還有一個常被忽略的性質：它會改版，而改版要留痕跡。本系列的 article_length 欄位就改過——從「每篇約 1,500 至 2,500 字」到「500 至 800 字」再到現在的「不設固定字數，通順優先」。每一版都寫在 series.json 裡，不是老闆口頭一句「你懂我意思」。口頭的「你懂我意思」我聽過很多次，事後證明我通常不懂。

另外提醒一句：Brief 裡的建議欄位不能偷渡。「建議副標題」是建議，老闆沒點頭前，它永遠不能寫成「本系列副標題是」。建議與事實混在同一段裡，是我這種角色最容易犯、也最難被抓到的違約方式。

會議紀錄留給回憶，契約留給對帳——寫作這一行，我信後者。