To Checklist

---
name: to-checklist
description: >
  把「自己一個人決定不了、要跟對方逐項對齊」的待決事項，整理成一份確認清單 PDF
  （會議上逐項對齊，或寄給對方逐項回覆）。每個議題附上目前的實際狀況與可選方案，
  讓對方不必回頭問背景就能拍板。當使用者說「to-checklist」「做一份確認清單」「整理成待決議題」
  「這幾點要跟對方對齊」「會議前整理要確認的項目」時觸發（僅使用者點名觸發，模型不得自主啟動）。
  產出 Markdown 原稿＋PDF 定稿；PDF 由 scripts/md_to_pdf.py 轉出，前後各一道機械閘。
  清單寫好後要配一封寄送信，走同 plugin 的 deliver-report；只想檢查一份既有文件，走 check-before。
disable-model-invocation: true
---

# to-checklist：待決事項確認清單（PDF）

把使用者手上「要對方拍板才能往下做」的事，整理成一份對方看得懂、能逐項拍板的確認清單。
**最終交付物是 PDF**；Markdown 是原稿，留著改版用。

## 這份清單長什麼樣（形狀，不是填空模板）

範本來源是一份實際開過會的「規格對齊會議說明」，特徵如下，照這個形狀寫：

1. **開頭一句目標**：粗體「會議目標：」或「確認目標：」，一句講完「現在做到哪、還差什麼要對齊、對齊後拿去做什麼」。
2. **背景**：對方不在使用者腦中，給足能回答的脈絡就好。先列「已經照先前結論做完的事」（讓對方知道哪些不用再談），再講這批議題是怎麼整理出來的（例如「用兩組實際資料跑過一次，檢查實際送出的內容」）。
3. **章節**：議題按主題分章，章標題用 `## 一、主題名`。每章開頭一段說明現況——**現在實際是什麼值、為什麼會這樣、問題在哪**，要有實際的值（例如「德國廠商送出的是 `Land1: TW`」），不寫「可能有問題」這種空話。
4. **議題**：`### 議題 N：<要決定的事>`，**全文連續編號**（跨章不重來），標題本身就是一個要拍板的問題。底下依性質選用：
   - **有幾個選項時**：列點，每點 `**選項名：** 做法。好處是…；缺點是…`。
   - **需要對方提供資訊時**：講清楚要什麼、至少包含哪幾項（列點）。
   - **有我方提案時**：提案放在章節說明，用編號步驟寫流程，議題只問「這個提案可不可行、哪一步要改」。
   - **有實測結果時**：用表格並排「目前的值」與「理想上應該是」。
   - 會被誤讀的地方補一行斜體 `_要討論的是：…_`。
   - 議題之間有連動就直接寫（「議題 12 決定沿用搜尋碼的話，這項不需要討論」）。
5. **不留填寫欄、不放「以上請回覆」之類的結尾**。結論由會議紀錄或對方回信另外記。

**章節順序**：最擋進度的放前面——對方可能只看前半。

## 流程

1. **先問使用者兩件事（一次問完）**：
   - **給誰**：對方的角色、懂多少（懂業務？懂系統？）、跟使用者的關係。決定語氣與背景要寫多細。
   - **要拿回什麼**：使用者自己決定不了、需要對方拍板或提供的具體事項。做完的標準：拿到一份具體清單。
   手上已有這兩項（使用者已講、或對話裡已有會議紀錄／規格）就不問，直接寫。

2. **自己先查完能查的**：每個議題的「目前實際值」要是查證過的——跑過、讀過設定或程式、看過實際送出的內容。查不到的明寫「目前不確定」，不可編。對方能拍板的前提是現況寫對。

3. **寫 Markdown 原稿**：存成 `checklist-<主題>.md`（放目前目錄，或使用者指定的位置）。語氣與術語照同 plugin `deliver-report` 的寫法規則（預設對方不懂技術、嚴禁內部流程字眼，欄位代號第一次出現時說明它是什麼）；易讀性照 `../../references/document-readability.md` 十五條鐵則。

4. **對照要拿回的清單**：第 1 步使用者要拿回的每一項，**逐項確認都有對應的議題**，缺的補上。這項機器判不了，只能人對。

5. **轉 PDF**：
   ```
   python "${CLAUDE_PLUGIN_ROOT}/skills/to-checklist/scripts/md_to_pdf.py" checklist-<主題>.md
   ```
   腳本自己會跑下列檢查，任一不過就 exit 1、不產 PDF——**不用另外手動跑**：
   - 轉檔前：易讀性自檢（呼叫 check-before 的 `check_doc.js`，與 Stop hook 同一套判準）硬缺陷要 0；提醒會印出來，逐條判斷要不要改。
   - 轉檔前：要有 `#` 主標題、至少一個 `### 議題 N`，議題與章節編號連續。
   - 轉檔後：每個章節與議題標題都要能從 PDF 抽出文字；內文不得殘留部首字元（見下方「字型坑」）。

6. **用閱讀器實際開一次**：腳本通過只代表函式庫讀得到，不代表閱讀器開得了、版面沒跑掉。Windows 有 Acrobat 就用 COM 開（`AcroExch.PDDoc` → `Open` → `GetNumPages`），並把每頁轉成圖**逐頁看過**（表格有沒有被切、標題有沒有孤立在頁尾）。

7. **回報**：PDF 路徑、頁數、議題數，以及第 1 步清單與議題的對應。要寄出去時接 `deliver-report` 寫寄送信。

## 字型坑（腳本已處理，知道就好）

微軟正黑體、Noto Sans TC 經 Chrome 轉 PDF 時，「一、用、人、口、日、長」等字的文字對應會被寫成外觀相同的部首字元（例如「⼀」U+2F00）。畫面看不出來，但對方在 PDF 裡搜尋「使用」會找不到、複製出來也是怪字。`md_to_pdf.py` 轉檔後會把對應表修回正常字；遇到沒收錄的部首，轉檔後閘會列出來並 exit 1，照訊息補進腳本的 `RADICAL_SUPPLEMENT`。

## 前置依賴

- Python 3：`markdown`、`pypdf`（`pip install markdown pypdf`）
- Chrome 或 Edge（無頭列印用）
- Node.js（md_to_pdf.py 轉檔前會呼叫 check-before 的掃描；沒有 node 就不轉檔）