research-log 是做什麼的？
以工程師事後口述的方式來記錄研究：一個測量的故事、一份精確到足以重新實作的規格、一份帶有數字的驗證記錄，以及一份誠實的未知事項清單——全部交付為一份自包含的 HTML 檔案（內嵌 CSS 和圖片，無需外部資源）。
核心承諾：每項主張要不是有測量為證，就是標記為未經證實，或者列為有待解決。 如果需要一句指導方針：閱讀成品只能知道某人寫了什麼；唯有真實的系統能告訴你它的意義。
工作流程
1. 先盤點證據
在開始寫作之前，從對話、儲存庫、日誌和使用者收集：
- 時間順序：日期、嘗試過什麼、失敗了什麼、什麼讓人意外
- 每項測量的精確數值及其取得方式
- 驗證執行：拿什麼跟什麼比較，以及誤差數據
- 重複該工作所需的工具、檔案路徑與命令
- 未解決的問題與純粹的假說
不要編造測量值、日期或數字。 如果缺少數字，請詢問或將其標記為 OPEN。帶有虛構數據的文章比沒有文章還糟——記錄中的缺口本身就是記錄的一部分。
2. 了解慣例
在寫作前請先閱讀 references/style-guide.md ——風格體現在細節中（能證明觀點的圖說、保留在敘述中的失敗、精確的數字、無行銷用語）。準備撰寫內容模組時，請閱讀 references/content-format.md。
3. 選擇骨架
六個核心章節，編號，依此順序。除非有明確理由，否則不可省略；如果在「建構真實事物」的弧線中存在案例研究章節，則將其插入規格與工具之間。
| # | 章節 | 必須包含的內容 |
|---|---|---|
| 1 | 故事 | 逐日時間軸；每個步驟都歸因於某次測量；包含死胡同和意外 |
| 2 | 方法 | 一句認識論句子 + 表格：測試工件 → 問題 → 答案 |
| 3+ | 規格 | 精確到足以重新實作的位元組/協定/格式表格，附帶信心標籤；數學運算以程式碼區塊呈現 |
| −2 | 工具與操作說明 | 實際可複製貼上執行的命令與路徑 |
| −1 | 驗證記錄 | 每次測量執行都包含定量誤差 + 一個底線提示框 |
| −0 | 未解決的問題 | 誠實的未知項目，每個都標記為 OPEN 或 HYP |
4. 編寫與建置
將內容以 Python 模組的形式撰寫，定義 DOC（格式參見 references/content-format.md），將其保留在專案中以便文件可重新產生，然後執行：
python3 <skill-dir>/scripts/build_doc.py content.py out.html
開啟輸出檔案並確認其能正確渲染，然後再展示給使用者。
5. 自我審查
- 每個事實性主張都帶有標籤，或位於驗證記錄中
- 故事中至少包含一次意外、失敗或修正——如果工作中完全沒有這些，應直白地說明，而不是製造戲劇性
- 數字是精確的並帶有單位（0.445 秒，而不是「很快」；64,779 像素，而不是「很多」）
- 每個圖片的說明文字應說明該圖片證明了什麼，而不只是顯示了什麼
- 操作說明的命令需實際執行過，或清楚標示為未經測試
- 必須存在未解決的問題（總是會有未解決的問題）
- 底線是一句讓人能憑記憶複述的話
標籤
四個信心標籤，內聯放置在其所限定主張的結尾：
- HW（綠色）——在真實受測系統上量測得到。對於非裝置型工作同樣適用：在實際運行中、在測試台上、在生產環境中量測。
- FILE（藍色）——在檢查過的所有工件（檔案、封包、日誌）中皆成立。
- HYP（紫色）——與所有證據一致，但未經證實。
- OPEN（灰色）——未知；沒有任何證據。
事實帶有標籤；評論則不需要。如果領域中有更適合的名稱，請在文件開頭統一重新命名並一致使用——但務必保留完全相同的四層劃分。
語調
同儕工程師，第一人稱複數，零行銷用語。數字精確並帶單位。句子簡短。幽默保持低調且少用。失敗與修正屬於故事的一部分，而不是註腳。同事以角色稱呼（「一位同事提供了兩組 PNG 序列……」）。
起源
萃取自 TriCaster DVE 研究日誌（waldobjekt.org，2026 年 11 月 1–3 日，與 Claude 共同創作）——原始文件附帶自己的 build_doc.py；此技能將該設定一般化。