Wong — 下班後的學習指南書（原名 daily-log）
將一整天的 Claude Code 工作（橫跨所有對話和儲存庫）變成一張單一的、附有日期的 Markdown 檔案，以教學指南的形式撰寫，讓使用者能真正學到工作內容：親手重新實作程式碼，理解每個決策背後的 原因，並因為真正理解而能夠解釋其運作方式。
輸出不是變更日誌。它是一本給初學者的教科書——寫得如此簡單和口語化，以至於沒有任何軟體背景的人也能從頭到尾讀懂，並理解做了什麼以及為什麼要這麼做。每個技術名詞在首次出現時都會用白話文定義；程式碼保持技術性，但會用白話文解釋包裹。深度和「為什麼」遠比瑣事的完整性重要。請參閱步驟 4 中完整的寫作風格 — 必要規則。
步驟 0. 從指令讀取努力程度
使用者可以傳遞一個努力程度作為第一個參數：light、medium 或 heavy。如果沒有給出，預設為 heavy。（他們也可以傳遞一個日期；YYYY-MM-DD 格式是日期，light/medium/heavy 是努力程度。順序不拘，兩者皆可選。例如 /wong medium、/wong light 2026-06-25。）
努力程度控制 token 用量——它同時影響摘要的大小（透過收集器的 --effort）以及你在寫作時花費的心力：
- light — 最省成本。只記錄前 2-3 項工作。不要執行
git show/額外的檔案讀取；依賴摘要 + 提交訊息即可，且總共最多包含一個簡短的程式碼片段。每個部分保持簡潔。仍需產出 Git 技能部分、Slack 摘要、PDF 和上傳。 - medium — 平衡。記錄前 ~5 項工作。只對其中2-3 個最重要的項目提取真實程式碼（
git show）。中等深度。 - heavy（預設）— 下面描述的完整處理方式：每個獨立的工作項目，為每個項目提取真實程式碼，完整深度。
在所有後續步驟中遵循所選的程度。
步驟
1. 收集當天的原始素材
使用所選的努力程度執行收集器（它會從磁碟讀取每個對話的記錄，因此能擷取所有並行/已關閉的對話，不只是目前這個）：
python3 ~/.claude/skills/wong/collect_day.py --effort heavy
將 heavy 替換為步驟 0 的程度。若要記錄某個過去日期，請加上日期：python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25
它會輸出一個摘要檔案的路径（~/Daily Log/.digest-<date>.md）。完整閱讀該摘要。 它包含每個儲存庫：當天的 Git 提交映射、未提交的變更統計，以及每個對話的——使用者的提示、Claude 編輯過的檔案、Claude 的解釋性文字，以及任何子代理的結果。
也請閱讀詞彙表，位於 ~/Daily Log/.glossary.md（如果不存在，則視為空）。它列出了先前天數已經解釋過的基礎/基礎術語。你不會重新解釋任何已經在其中的東西——請參閱步驟 4 中的「僅解釋一次基礎術語」。
如果摘要顯示沒有活躍的對話，請告知使用者並停止。
2. 識別不同的功能/任務
將當天的工作分組為不同的工作項目，而不是每個對話一個章節。合併那些推進了相同功能的對話/提交。一個「工作項目」是使用者可以指出的一個獨立工作單元（例如「verto 代理呼叫傳遞的錯誤修復」、「預測式撥號器的放棄率上限」）。專注於那些真正重要的事項；不要用細枝末節來填充內容。
3. 為每個項目獲取真實程式碼
努力程度限制： 若為 light，完全跳過此步驟（不使用 git show/檔案讀取——使用摘要 + 提交訊息，最多一個片段）。若為 medium，只對 2-3 個最重要的項目執行此操作。若為 heavy，對每個項目執行。
摘要會列出提交 SHA 和編輯過的檔案，但不包含完整的差異。對於你正在記錄的每個項目，提取實際程式碼，使片段是真實的而非改寫的：
git -C <repo> show <sha> # 一個提交的完整差異
git -C <repo> show <sha> -- <path> # 一個檔案的差異
git -C <repo> diff -- <path> # 未提交的工作
或者，在相關行數讀取當前檔案。偏好顯示關鍵行（承載想法的行），而不是傾倒整個檔案。
查閱儲存庫的 CLAUDE.md 和 docs/GOTCHAS.md（如果存在）以了解與工作相關的潛在陷阱——它們是「陷阱與教訓」章節的黃金素材。
4. 撰寫教學指南——增量式，永不覆蓋
檔案名稱格式。 檔案儲存在 ~/Daily Log/ 中，命名為：
<YYYY-MM> - <DD> - <当天工作的一行摘要>.md
例如 2026-06 - 26 - 修復了代理呼叫傳遞並開始 Yotel 3D 著陸頁.md。一行摘要部分是當天工作的簡短、白話標題（其中不含連字號，因為日期分隔符已經使用「 - 」；保持在約 12 個字以內）。檔案的頂層 # 標題必須與不含 .md 的檔案名稱相同。
尋找今天的檔案（對於追加邏輯很重要）。 因為一行摘要後綴各不相同，永遠不要尋找精確的 <date>.md。相反，透過日期前綴找到今天的檔案——列出 ~/Daily Log/ 並匹配以 <YYYY-MM> - <DD> - 開頭的檔案（例如 ls "~/Daily Log/" 並選取以 2026-06 - 26 - 開頭的檔案）。每天最多有一個檔案。
這個技能一天內可能被執行好幾次。在第一次之後的每次執行中，你必須只添加尚未記錄的工作——絕不覆蓋或重複已有的內容。
程序：
- 如果今天還沒有檔案（沒有匹配日期前綴的檔案）：使用下面的完整結構（當天概述 + 每個工作項目一個章節，編號為
## 1.、## 2.、……）建立它，並以上述格式命名。 - 如果今天的檔案已經存在（通過日期前綴找到）：先讀取它。透過掃描其現有的
## N. <title>標題以及每個參考資料行中的提交 SHA / 對話 ID，建立一個已涵蓋內容的集合。然後，從今天的摘要中，識別那些提交/對話尚未在該集合中的工作項目。- 保持檔案名稱的一行摘要對整個天數的準確性： 如果新增的工作改變了當天的總標題，則重新命名檔案（並更新其
#標題以匹配），使一行摘要仍然反映當天完成的所有事情。如果標題仍然合適，則保持名稱不變。 - 如果沒有新內容，告知使用者該檔案已經是最新的並停止（不要重寫它）。
- 否則，追加新的
## N.章節（接續現有編號），僅針對新工作，使用相同的每個功能模板。 - 就地更新當天概述區塊：提高提交/對話計數，並擴展摘要以提及新增加的工作。不要觸碰現有的功能章節。
- 使用編輯（有針對性的插入），而不是完整的覆寫，以便先前的章節——包括任何你手動編輯過的——能夠逐字保留。
- 保持檔案名稱的一行摘要對整個天數的準確性： 如果新增的工作改變了當天的總標題，則重新命名檔案（並更新其
如果一個工作項目的提交 SHA 或對話 ID 已經出現在檔案中，則視為已涵蓋。根據這些識別碼進行匹配，而不是根據措辭，這樣重新執行就不會產生幾乎重複的章節。
寫作風格 — 必要（這是重點）
寫得像一本給完全初學者的教科書章節——一個聰明但對軟體一無所知的人。讀者應該能夠從頭到尾跟隨每個章節，而不需要任何前置背景知識。
- 口語化且簡單。 短句。白話。解釋時就像在跟朋友說話，而不是寫報告。避免在敘述中使用行話。
- 在整個系列中只定義每個技術名詞一次——而不是每天一次。 一個名詞首次出現時，用日常用語在一個引用區塊中定義：
> **「X」是什麼意思。** …（使用真實世界的比喻）。但首先檢查詞彙表（~/Daily Log/.glossary.md），絕不重新定義已經列在其中的名詞。 這對瑣碎、反覆出現的基礎知識最為重要——什麼是儲存庫/提交/分支、什麼是 Yotel、基本的 git——解釋一次，然後就只是使用它們。一個全新的、真正是今天工作核心的複雜名詞仍然可以獲得它的解釋區塊；一個已經涵蓋過的基本名詞則不需要。參閱下面的「僅解釋一次基礎術語」以了解具體做法。 - 只在技術精確是重點時保持技術性——例如實際的程式碼變更、確切的檔案、真實的取捨。展示真實的程式碼，但用前後的白話文解釋包裹，並用白話文註解程式碼片段。永遠不要只是傾倒程式碼。
- 每個章節以「日常版本」開頭——用白話故事說明什麼東西壞了/需要什麼以及為什麼它很重要——然後才進入任何技術細節。
- 在最頂端使用一個簡短的**「如何閱讀此文件」** 說明，以及一個**「大局觀（先讀這個）」** 概述，用白話解釋這些專案（這是什麼產品、誰在使用它、為什麼）。
- 保持「如何解釋它」的要點為白話、自信、一句話的形式，然後緊跟著一個簡單說明的巧妙見解。
- 要誠實：清晰地區分真正上線的程式碼與設定/探索，並用白話說出來。
與 ~/Daily Log/ 中最新的現有檔案語氣相匹配（如果存在，則將其作為參考範例閱讀）。
僅解釋一次基礎術語（詞彙表）
整個系列的讀者不應該每天看到「什麼是儲存庫」或「什麼是 Yotel」被重複解釋。所以：
- 寫作前，閱讀
~/Daily Log/.glossary.md（已經解釋過的術語列表）。將其中的所有內容視為已知——不要為列表上的任何術語撰寫> **「X」是什麼意思。**的區塊。正常使用該術語即可。 - 寫作時，只為真正對這個系列來說是新的（不在詞彙表中）的術語添加定義區塊。強烈傾向於不重新定義基礎知識；如果對某個基礎名詞有疑問，假設它已經被涵蓋過並跳過。
- 寫作/追加完成後，更新
~/Daily Log/.glossary.md：追加（每行一個）你今天首次定義的任何術語。永遠不要移除現有條目。如果檔案不存在，則建立它。
這尤其適用於瑣碎、反覆出現的術語（儲存庫、提交、分支、工作樹、產品是什麼、基礎 git）。一個複雜的術語，如果是一天工作的核心，仍然可以在該天解釋，但一旦它被列入詞彙表，之後就不再重新解釋。
每個功能的模板和當天概述結構（將標題調整為上述的初學者友好語氣——這些是需要涵蓋的內容，而不是要逐字複製的僵化標籤）：
# <YYYY-MM> - <DD> - <当天工作的一行摘要>
> **如何閱讀此文件。** （用 1-2 句話告訴初學者如何使用它。）
## 大局觀（先讀這個）
白話概述今天完成了什麼。**僅在它們尚未出現在詞彙表中時**（也就是在第一份日誌中）在這裡定義「專案/儲存庫」、「提交」以及產品（例如 Yotel）是什麼。在之後的每一天，跳過這些基礎知識和「這個產品是什麼」的解釋；只需提及它們並繼續。
---
## 1. <该工作项目的白話標題> （<repo>）
### 日常版本
沒有行話的故事——什麼東西壞了或需要什麼，以及為什麼它對一個真實的人很重要。使用一個比喻。
### 實際情況 / 修正（技術部分）
現在是精確的細節：真正的原因、真實的程式碼變更（用白話顯示和解釋，帶有註解的片段）、確切的檔案 `path`。在每個新的技術詞彙前放置一個 `> **「術語」是什麼意思。**` 的區塊。
### 如何自己動手做，逐步
編號、具體的步驟，初學者可以遵循。
### 如何解釋它（一旦你理解之後）
- 關於這個工作作用的一句白話摘要。
- 一個巧妙見解，簡單地解釋。
- 需要用日常用語捍衛的取捨。
### 值得記住的教訓
白話的總結 + 任何來自 CLAUDE.md / docs/GOTCHAS.md 的相關潛在陷阱。
**在哪裡找到它：** 檔案、提交 SHA、對話 ID。
---
## 2. <下一個項目……>
---
## 今天使用的 Git 技能
（總是文件的**最後一個**章節。從摘要的「Claude 執行的 Git 指令」區塊構建——請參閱下面的專用說明。）
### <git 操作，例如 提交變更> `git commit`
**它做了什麼** — 用白話說明這個指令今天完成了什麼。
**為什麼** — 為什麼在工作流程的這個時間點需要這個步驟。
**如何自己操作** — 真實的指令，並附上每個部分和旗標含義的簡短說明，讓讀者可以手動執行它。
### <下一個 git 操作……>
「今天使用的 Git 技能」章節 — 必要（總是最後一個章節）
每一天的文件都以一個 ## 今天使用的 Git 技能 章節結束，該章節來自摘要中的 「Claude 執行的 Git 指令」 區塊（每個對話一個區塊）。
如何構建它：
- 收集摘要中每個對話的所有 git 指令。一個捕獲的條目可能是一個組合指令（例如
cd repo && git add ... && git commit ...）；提取出 git 部分。 - 按 git 操作分組（例如提交、建立分支、建立工作樹、推送、暫存、 stash、還原、變基、使用 log/diff/show/status 檢查）。每個不同的操作一個子章節——不要多次列出相同的操作。如果許多指令只是唯讀檢查（
git status、git log、git diff、git show），將它們一起放在一個簡短的「瀏覽儲存庫」子章節中，而不是各一個。 - 對於每個操作，使用文件中其他地方使用的初學者友好語氣撰寫三件事：
- 它做了什麼 — 這在今天的實際工作中完成了什麼。
- 為什麼 — 為什麼在工作流程的那個時間點需要這個步驟。
- 如何自己操作 — 真實的指令，並附上每個部分和重要旗標含義的簡單說明，讓讀者可以手動執行它。
在首次使用每個新指令前放置一個
> **「X」是什麼意思。**的區塊（如果該指令的操作在之前的日誌中已經解釋過，則不需要重複；查閱詞彙表）。
Dormammu — 直到成功為止的暴力測試
Dormammu 會重複執行你的程式碼，直到它成功為止。不像一個有耐心的導師，Dormammu 會不斷地對你的程式碼進行迭代，根據編譯錯誤或運行時錯誤進行修正，直到沒有錯誤殘留，且程式碼通過所有測試。
本質上就是：
- 你給 Dormammu 一個要運行的命令。
- 它會運行該命令。
- 如果命令失敗，它會讀取錯誤訊息，思考如何修復，編輯程式碼，然後回到步驟 2。
- 如果命令成功，它就可以停下了。
這對於破解那些你不太理解而且懶得去修正的討厭錯誤非常有用。
用法範例：
/dormammu npm run build
/dormammu python test_suite.py
它會持續嘗試直到成功或達到了合理的嘗試次數（然後放棄）。
Agamotto — AI 評論家
Agamotto 會召喚一個嚴格的 AI 評論家來徹底地拆解你的計畫、架構或程式碼。
這個技能旨在幫助你在投入大量時間實作之前，抓出邏輯缺陷、被忽略的邊界情況、安全性問題以及架構上的權衡取捨。
用法範例：
/aagamotto
之後，Agamotto 可能會提示你描述你正在計畫的內容，或者它會分析你目前的上下文。
這項技能套件由 ShockRock2004 建立，旨在與 Claude Code 和其他 AI 代理工具協同工作。