deliver-reportlisted

# deliver-report — 交付訊息產生器 > 使用者常要把一批產出（報告、Excel、log、設定檔…）交付給他的收件人。**語氣固定，形狀依當次情境而定。** > > **三個鐵則**：①**收件人沒指定就寫 `Hi，`，永遠不留 `<收件人>` 這種佔位符**（忘了改會很難看）。②**預設讀者不懂技術**——寫給主管/客戶/業務看的，用白話，術語只留在給工程端的那一檔。③**這是對外說明，嚴禁任何內部術語/流程字眼**（紅藍對抗、QA、code-review、adopt/bump/publish、skill、plugin、session、AI…）——只講交付物與結論，不講我方怎麼做出來的。 ## 這個 skill 產出「訊息」；要「報告檔」請走另一個 判準一句：**對方收到的是「文字」還是「檔案」？** - **一段訊息／一封信**（把已產好的檔案交出去、回覆對方提問）→ 走本文。 - **一份測試報告 DOCX**（修復／功能的測試證明文件，給 PM 或客戶簽核轉發）→ 改用 **`test-report-docx` skill**，本文不處理。 兩者常前後接續：報告檔產好之後若還要寫一段訊息把它交出去，那一段回到本文走四個決定——報告檔在信中的地位（主體或佐證）由決定一逐案判，不預設。 **文件易讀性鐵則：任何要交給別人看的產出都適用**（交付訊息本身、施作說明書、驗收清單、提案、評估報告、交接文件）——一律先讀 `../../references/document-readability.md`：十二條鐵則＋交付前必做的五項機械掃描。**不要因為「這份只是內部參考」「這份不用照著做」就放寬**（2026-08-25 使用者裁決：「不只吧，所有的文件你都有可能發生這種低級錯誤啊」）。該檔每一條都是使用者當面指出過 2~4 次的實案，**不是理論**。 ## 何時用 / 何時不用 **該用**：一批檔案已產好、要寫一段訊息把它們交給收件人（客戶、工程端、主管）。典型是分析報告 + 明細 + 原始資料 + 實作/設定檔的組合交付；或對方來信提問、我方附報告回覆。 **不該用**：還在做分析、檔案還沒定案（先把東西做完）；單一檔案隨手丟一句話就好（不需要正式交付結構）；要寫的是內部技術文件本身而非「交付說明」（那是寫文件，不是交付訊息）；交付物是測試報告檔本身（用 `test-report-docx` skill）。 ## 第一步：蒐集這次要交付什麼 在動筆前，先湊齊這些資訊。能從上下文推出來的就自己填，缺的才問使用者——一次把缺的問完，不要逐項來回。 必要素材： 1. **對方到底問了什麼**（若這次是回覆提問）：**以對方最新來信/最新會議紀錄原文為準**核對題號與題目，別沿用先前討論或舊版草稿的框架。題數變了（四題變三題）、或某題前提已變（問「測試環境費用」但環境已由我方建好），整封信的形狀都要跟著改。**先把對方的提問逐條列出來給使用者確認，再動筆。** 2. **收件人**：若使用者這次有講收件人（例如「給 A」），就寫 `Hi A，`。**沒講就直接寫 `Hi，`**——絕不輸出 `Hi <收件人>，`、`Hi ___，` 這類佔位符（忘了改會很難看）。乾淨的 `Hi，` 本身就成立，寧可留白也不留佔位符。 **順帶判斷收件人是單類還是多類**：若收件人涵蓋多種角色（業務端＋工程端＋第三方單位…）且各自只需要讀這批檔案的一部分，記下「每類受眾 × 各自關心哪幾份 × 各自的關鍵重點」。 3