腳本是工具，skill 是流程說明書

把 Planner 巡檢包成 skill 的過程，用幾個問題釐清腳本與 skill 的分界，途中還修正了一個判斷規則的前提錯誤。

背景

公司的四個內部系統都用 Teams Planner 收同仁的問題：同仁在看板上開卡，或者我從通話與 Teams 郵件代他們整理成卡。原本有一支 check-issues.py 腳本，session 一開始會自動列出「待回覆」的卡片；抓下來之後怎麼修、怎麼部署、怎麼回覆，每次都靠 AI 臨場組流程。最近用了 /insight 指令讓 AI 分析我的使用紀錄後提議，把「抓問題、修復、部署、回卡片」整條包成一個叫 planner-patrol 的 skill。

問題一：是因為步驟都是我自己呼叫嗎？

動手前我先問了動機：要這樣做，是因為步驟原本都得我自己呼叫嗎？

AI 回答不是這個原因。抓卡片的腳本、回卡片的 skill 本來就在，它也能臨場把零件串起來。包成 skill 的價值在別處：把品質關卡寫死在流程裡（寫給同仁的根因必須附 diff 或 blame 證據、絕不自動把卡標完成、CI 綠燈之後才能說「已部署」）、讓四個系統共用同一套標準、把觸發成本降到一個詞，過去這些關卡靠 AI 當場記得。

糾正一：看板上明明有一張

skill 建好，AI 回報四個看板實測通過、都沒有待回覆卡。我記得 OEE 系統的需求貯體有一張還沒回，提了出來。

AI 查下去發現，規則的前提錯了。腳本定義「待回覆＝同仁最後修改的卡」，但我也會幫同仁建卡，這種卡的最後修改人是我自己，規則天生看不見它們。OEE 看板上五張未完成的卡全部隱形。問題出在規則的假設，跟掃描範圍無關；少檢查一個貯體只會漏一張，假設錯了是整批消失。

糾正二：已經回覆三張了

AI 接著提議一個修法：看卡片筆記裡有沒有「開發回覆」這個標題，有就算已回覆。我再指出其中三張早就回覆過了，只是還沒標完成。回覆的形式有「上線紀錄」「查證結果」「通話補充」好幾種，標題不固定，字串比對抓不到。

最後定案的分工：腳本只負責盤點，把未完成的問題卡與需求卡全部列出來；每張卡處於什麼狀態（已回覆待標完成、已決策待實作、還沒動），讓讀筆記的模型判斷。語意判斷寫死在程式裡，換一種寫法就誤判一次。

問題二：怎麼知道會呼叫哪個 skill？

之後我說「去抓有沒有 issue 或 bug 要處理」，AI 呼叫了 planner-patrol。我趁機問了機制：它怎麼知道要用哪個 skill？為什麼不是另一個「抓問題下來」的 skill？

AI 的釐清是：挑選靠每個 skill 描述欄的語意比對。session 開始時只載入所有 skill 的名稱和描述，我說一句話，它比對最吻合的那個才展開內文。而我以為存在的那個「抓問題的 skill」其實從來不存在——check-issues.py 只是住在另一個 skill（負責巡查Planner 看板腳本）目錄裡的工具腳本，不是觸發對象。