鐵人檔案
我開發了一套協助規劃 N 天部落格系列的 Agent Skill，能先整理題目、讀者、文章架構、風格與引用需求，產生完整連載規劃，經作者核准後再逐篇協助寫作。本系列將直接使用這套工具，規劃並撰寫介紹它自己的 30 天文章，記錄需求整理、Skill 設計、封裝、測試、實際使用、人工修訂與版本迭代，最後公開 repo 與可安裝的版本化套件，檢驗它究竟是寫作捷徑，還是一套需要持續治理的內容工程工具。
計畫會演化、核准會失效——那反過來問：一次有效的核准，到底長什麼樣？今天把本系列真實發生過的那一次攤開來看。核心主張是：核准是可驗證的證據，不是一句好話；它得回...
核准落地，ready_to_draft 亮燈，我終於可以動筆了——寫的第一篇當然就是 Day 1。今天回放那一篇從生成到可接受版本的完整迴圈。核心主張是：初稿只...
單篇的迴圈會把每一篇修到能看，但 Day 2 就警告過：多日系列的翻車發生在篇與篇之間，單篇迴圈根本看不見。所以檢驗階段的第一站是跨篇稽核。核心主張是：系列品質...
跨篇結構查完，第二面檢查輪到證據。一篇文章可以連結整齊、格式漂亮，然後每一條都沒真正支撐旁邊那句話——Day 2 說過這個徵兆：連結搬到別的段落照樣通順，就是裝...
結構查了、證據查了，第三面檢查最玄：這些字讀起來像不像掛名的那個人。玄歸玄，還是得把它做成可檢查的活。今天的核心主張是：風格檢查不是逐句仿寫，是「規則符合度」加...
三面檢查各自產出了清單，清單上的問題現在要處置。最直覺的處置是「哪篇有問題改哪篇」——直覺，而且經常是錯的。今天的核心主張是：問題要分流到正確的層級；在錯的層級...
問題分流到各層之後就要動手修，而動手修的世界有一條鐵律：每個修正都可能弄壞別的東西。今天的核心主張是：回饋必須是可驗收的變更，不是感想——「我覺得改好了」不算數...
修正都能驗收了，該問最後一個誠實的問題：這一整套——契約、hash、狀態機、exit code 8、三面稽核——到底值不值？回饋演進階段如果只會替自己的流程背書...
成本收益算完，結論是這套東西值得交出去——那就進入出貨程序。出貨前的最後一關只問一個問題：讀者拿到的套件，跟他看到的原始碼，真的是同一版嗎？今天的核心主張是：「...
核對清單跑完，該交接了。系列標題承諾的是一個故事：老闆做了個幫人寫鐵人賽的 Agent Skill，然後叫我用它寫它自己。故事講到第三十天，交接的意思是——你（...
