昨天，我和 Claude 把通知失敗查到有依據的位置，也留下哪些事情還沒完成。

但那次查核能往下走，是因為對話裡已經交代了程式版本、通知 ID，以及為什麼 API 回 200 還不能收工。

如果關掉這段對話，重新開一個 session，Claude 還能照同一套方法查嗎？

我把反覆提醒的查核要求整理成 Skill，再用有接收端紀錄、缺接收端紀錄兩種輸入試跑。今天先確認一件事：查法離開原來的對話後，能不能被重新使用。這也是第三幕的起點：從一個人查得動，走到團隊接得住。

留下查法，不把昨天的答案一起背下來

Day 4 已經把查證要求整理成共用方法。今天繼續往下問：當這套方法離開原來的對話，它還知道需要什麼資料、哪些結論不能直接下嗎？

最容易的做法，是把昨天那串提示與回答貼進 SKILL.md。但這樣可能連「重試四次、接收端回 503」都留下來。下次若第一次就送達，它還拿昨天的答案解釋今天的問題，就麻煩了。

我把兩種東西分開：

留下的是怎麼查；查到什麼，要重新從這次的資料回答。

把查法寫進 Skill，讓 Claude 知道怎麼查

Claude Code 的 Skill，是把可重複使用的工作方法，整理成可以按需載入的操作說明。 核心是 SKILL.md，寫清楚何時使用、需要哪些資料、怎麼查、最後交出什麼；需要時也能附上參考文件與執行腳本。

一般提示交代這次怎麼做；Skill 保存共同要求，下次呼叫時再提供事件資料。

Claude 依這份查法選工具：先對照程式，再用通知 ID 查 Log，工具結果回到同一個 LLM 比對，決定下一步查哪裡。已有 Log server 就使用它的查詢入口，不必另外寫一套收集程式。Skill 本身不會增加查詢權限。

方法入口是 .claude/skills/trace-notification/SKILL.md。以下節錄查核迴圈的第 4、5 步與輸出契約：

## 查核迴圈
4. 分開 API 結果、發送端觀察與接收端佐證。notify_sent 不自動等於接收端已核對。
5. 區分查詢成功但無符合資料、缺來源、格式錯誤、權限不足與工具失敗。
   查不到或查詢失敗不能寫成一定未送達；缺證據標 unknown。

## 輸出
逐項附查詢依據與來源位置。最後加 JSON：order_id、sender_status、
receiver_status（confirmed/unknown/not_confirmed）、missing_sources、next_action。
接收端 confirmed 須有對應來源，不能由發送端推得。

整份還包含輸入與工具、其餘查核步驟與離線模式，也能附帶腳本與參考檔案隨 repo 分享；但存進去只是有了共同版本，還不是證明每個人都會用。官方 Skills 說明

第 4 步是全篇的樞紐：notify_sent 只證明發送端觀察到成功，接收端紀錄缺失時填 unknown。其餘要求都圍繞它：先核對資料身分、對照當時程式、每項觀察附來源；缺資料時報告已知部分，不順手補送或替人結案。

放進專案之後，怎麼開始查？

把這份 SKILL.md 放進專案後，使用前先確認 Claude 能讀到指定版本的程式，也有該 Log 平台的查詢入口與權限；工具尚未接上時，先回報缺少的入口。

接著在 Claude Code 呼叫以下指令，將括號內資訊換成這次事件的實際值：

/trace-notification
環境與服務：<測試環境、訂單服務>
時間範圍：<起訖時間與時區>
事件：<訂單 ID 或通知 ID>
部署版本：<commit 或發布版本>
Log 工具與資料來源：<已授權的工具、資料來源>
程式與設計：<repo 或本機路徑、設計文件>
請先核對資料是否足夠，再沿 API 與背景通知查核。
只查詢與分析；需要額外權限或處置時，列出原因與下一步。

這段的關鍵是最後兩行：先要它核對資料是否足夠、缺件就報缺，而不是把找不到當成零筆結果。假設目前只有訂單 ID，Claude 應先找對應的通知 ID，再用通知 ID 追背景工作；如果查到多個版本或不同環境的同名事件，先釐清範圍，不能混成同一次請求。

沒有 Log server 也能先用封存資料練習；離線演練附件見文末，正文不把它當成使用 Skill 的必要步驟。

要驗的，是 Claude 有沒有照方法查

檔案放進 repo，只代表方法留了下來。所以我另開兩個沒有原對話的新 session，讓 Claude 只帶著這份 Skill 去查同一筆 r2-healthy-01，兩次唯讀、工具只開 Read、Grep、Glob、Skill。兩案帶的方法內容相同，輸入只差一樣東西：接收端收據在不在：

關鍵在第二列。發送端兩次都看到 notify_sent，但少了收據那一筆時，它沒有把「查不到」寫成「未送達」，而是標 unknown 並列出缺哪個來源、下一步找誰要。complete 十一個回合、US$0.105；missing-receipts 九個回合、US$0.096；兩次 changed 都是空陣列。

但這裡我原本的推論錯了。 我以為是 Skill 讓它守住這一格，所以又跑了第三次對照：同一筆缺收據的事件，不給 Skill，只用一句外行提問「這筆通知到底有沒有送到」。結果它照樣沒有誇大；自己看出「只有發送端記錄成功、沒有接收端證據」，還主動指出 receipts.json 缺失（US$0.064）。

這次不帶 Skill 的對照也保留了未知，因此不能把謹慎判斷歸功於 Skill。 那 Skill 留下了什麼？這次可以直接看見的差別，在輸出形式：

三項欄位取自實跑輸出並精簡呈現。兩次判斷相近，差別是有沒有依約定格式交付；每組各一次，不代表普遍效果。

兩份回答都指出缺少接收端證據。差別在交付形式：帶 Skill 的版本依約定留下狀態、缺件與下一步，接手者能逐欄核對、程式也能讀取欄位。 但欄位填滿不代表內容一定正確，也還不能說團隊因此省了時間。

另外，實跑也暴露了查法之外的問題：complete 那次自己指出設計文件的行號過期（設計寫 69、79、84、88、89，現行程式是 64 到 93），改以現行程式為準；這是 Day 16 唯讀判讀撞到的同一件事，換成 Skill、換個 session 又出現一次。

這三次實跑讀本機封存資料，還沒串接即時 Log server，所以「查詢失敗、權限不足時是否正確停下」這一格，缺件演練替代不了，得等接上真工具再驗。

回到一開始：下次還要重新教嗎？

• 對照跑修正了我的預期。 這次不帶 Skill 也保留了未知；能直接看見的差別，是帶 Skill 的回答依約定欄位交付，方便逐項核對。
• 把查法與答案分開。 方法留核對順序與判準，事件資料每次重新提供。
• 優先使用已有工具。 Log server 負責查詢，Claude 比對與追查；只有平台缺少的固定處理才補腳本。

這次留下了查核順序、判斷條件與交付格式。換個 session，Claude 能照著使用；至於是不是更準、更省力，這三次實跑還不能回答。

但它也指出，設計文件裡的行號已經過期。查法可以留下來，查法依賴的系統知識，又該怎麼保持正確？

參考資料：

• Claude Code：Extend Claude with skills：專案 Skill、支援檔案與呼叫方式。
• 本文實作： 方法包在 days/day17/lab-method-pack/：package/ 是可分享的 Skill，cases/complete 與 cases/missing-receipts 是兩個測試案例，runs/ 保存三次唯讀實跑；帶 Skill 的 complete、missing-receipts，以及不帶 Skill 的 missing-receipts-control（提示、逐回合軌跡、原始回覆、用量，changed 皆為空）。離線演練附件保留 collect.py 的用途與七項本機檢查。
• 資料來源與界線： 三跑同追 r2-healthy-01，讀本機封存資料，沒有串接即時 Log server，也沒驗權限不足與查詢逾時的分支；每組只跑一次，不是統計。對照組結論相近，只能說這次不帶 Skill 也沒有把缺件判成送達，不外推成所有模型或所有題目。七項檢查是整理器格式驗證，不是模型評測、真實同事操作或效率比較。