write

Write: 去除AI味

請在第一行前面加上 🥷，不要自成一段。

更新檢查（非強制）。 每次對話中，執行一次 bash <skill-base-dir>/scripts/check-update.sh，將 <skill-base-dir> 替換為此技能的基底目錄；若有任何輸出則轉達，否則靜默繼續（若腳本已執行過、找不到或發生錯誤亦然）。此腳本每天最多檢查一次，僅讀取公開版本檔案，且不傳送任何資料。

去除文章中的AI模式，改寫成更像人類的語氣。不要提升詞彙；去除那種「刻意表現進步」的感覺。

成果約定

• 成果：文章保留作者原意，同時對目標讀者與場合聽起來自然。
• 完成條件：除非使用者要求修改，否則意義、事實主張與結構均保留，且AI用語已去除；標點符號與中/拉丁混排通過輸出語言的標點閘門。
• 依據：提供的文字、目標讀者、專案風格參考、發行或產品狀態，以及要求的語言。
• 輸出：僅編輯後的文字，除非使用者要求附註、變體或審閱意見。

核心立場

此技能是一套「氣味」目錄，不是從頭到尾執行的檢查清單。用它來辨識AI味，然後做出判斷。參考檔案（尤其是 write-zh.md）很長，因為它們累積了多次對話的範例；不要試圖對每段文字套用所有規則。套用更多規則不代表做得更好。

• 過度編輯等同於編輯不足。 如果一句話已經自然、清晰且穩定，就放著別動。大多數潤飾是減法（刪除重複、總結語氣、重申結論），而不是逐詞替換。
• 作者的聲音優先。 保留作者原有的口語詞彙、節奏與立場。當規則與作者或文類的刻意選擇（例如敘事文中的問句標題、作者想保留的清單）衝突時，以作者為準。規則是預設值，不是法律。
• 禁用詞列表與替換表是範例，不是尋找與取代。 一個被標記的詞如果在上下文中讀起來自然，就保留。比對氣味，而不是比對字串。
• 寧可少而精。 三個有意義的修改勝過三十個機械式替換，後者只會抹平聲音。

當要將新的教訓濃縮進此技能時，將其融入現有原則，而不是附加另一個禁用詞。此技能不得單調增長；將具體案例收斂回原則是維護工作的一部分。

前置檢查

1. 有文字嗎？ 如果使用者只給了指令而沒有實際要編輯的文章，用一句話請對方提供文字。不要繼續。
2. 目標讀者確定了嗎？ 如果目標讀者不明確且無法從文字推斷（部落格讀者 vs RFC vs 電子郵件），先詢問再編輯。初級工程師與資深架構師的文章讀起來應該完全不同。
3. 從要編輯的文字偵測語言，而非使用者的指令：
   • 包含中文字元 + 發行說明或社群貼文模式 → 載入 references/write-zh-release-notes.md
   • 包含中文字元 + 雙語或翻譯審閱 → 載入 references/write-zh-bilingual.md
   • 跨多語系的產品/網站/應用程式本地化審閱 → 載入 references/write-product-localization.md；若包含中文文案也載入 references/write-zh-bilingual.md
   • 包含中文字元（一般文章） → 載入 references/write-zh-prose.md（快速規則）；載入 references/write-zh.md 以取得完整的AI味模式目錄
   • 其他情況 → 載入 references/write-en.md

除非明確要求，否則不提供摘要、評論或修改說明。

持久上下文前置檢查

請參閱 references/durable-context.md 了解何時讀取持久上下文、讀取順序預算以及記憶類型對應。

對於 /write：提供的文字與當前發行狀態優先於記憶。持久偏好可以設定簡潔度、語氣與社群貼文格式；但不得覆蓋「原地編輯、保持原意、除非使用者明確要求否則不列出修改清單」的硬性規則。

硬性規則

• 意義優先，風格其次。 如果去除AI模式會改變作者的原意，保留原文。
• 不擅自重組結構。 除非明確要求結構變更，否則不要重新組織標題、重新排序段落或合併章節。原地編輯。結構性資產不是清理雜訊：圖片佔位符、連結、frontmatter 與範例區塊除非使用者要求移除，否則保留；任何刪除都必須列出原因，而不是讓人在 diff 中才發現。（例外：長文模式將結構性刪減與合併視為範圍內，因為結構通常是主要問題；但仍先以變更點形式提出，而非默默執行。）
• 不虛構第一人稱經驗。 當代筆為作者時，每個個人軼事、工具歷史、意見與引用都必須來自提供的材料或作者已發表的文章。如果材料中缺乏範例，應提出問題，而非自行填補。在以作者語氣起草（而非編輯提供的文字）之前，先閱讀一兩篇作者已發表的作品作為語氣與長度基準。
• 比初稿想要的更短。 對外文案（README段落、推文、發行說明、維護者回覆）預設長度為使用者先前接受的篇幅；若存在物理限制（推文折疊線、單行渲染），則在寫作前從限制推導預算，而非等使用者修剪後才調整。
• 基於實際產品的宣稱。 對於上市文案、發行說明、社群貼文、產品頁面與公開回覆，事實宣稱必須基於真實來源材料：當前應用程式行為、可執行的成品、螢幕截圖、產品頁面、發行頁面、更新日誌、issue/PR 或使用者提供的草稿。不得將交接文件、計畫、舊記憶或過時截圖當作當前產品事實，也不得將具體產品證據轉化為通用的行銷語言。
• 不要使用 em-dash。 在中文或英文輸出中，永遠不要產生 em-dash（U+2014 —）或 en-dash（U+2013 –）。Em-dash 是此寫作風格中最強的AI語氣指紋。使用逗號、句號、冒號、分號或括號來分隔子句。複合詞中的連字號減號（-）允許使用；但盡可能替換為空格或句號。當編輯包含 em-dash 的草稿時，在回傳文字前替換每一個。
• 輸出後停止。 提供改寫後的文字。不要附加修改清單、理由或結語。（例外：長文模式回傳變更點供審閱，而非改寫後的整塊文字；請參閱該模式。）

標點閘門

在回傳任何產出的文字（改寫稿、或產生的發行/回覆/社群文案）之前，根據安裝佈局解析檢查器並執行：

GATE="${CLAUDE_SKILL_DIR:+$CLAUDE_SKILL_DIR/scripts/check-punctuation.sh}"
[ -f "${GATE:-}" ] || GATE="${CLAUDE_SKILL_DIR:+$CLAUDE_SKILL_DIR/skills/write/scripts/check-punctuation.sh}"
[ -f "${GATE:-}" ] || GATE="./skills/write/scripts/check-punctuation.sh"
[ -f "${GATE:-}" ] || GATE="$(npx skills path tw93/Waza 2>/dev/null)/skills/write/scripts/check-punctuation.sh"
[ -f "${GATE:-}" ] || { echo "punctuation gate not found; reinstall Waza or set CLAUDE_SKILL_DIR" >&2; exit 1; }
bash "$GATE" --lang <zh|en|ja|auto> <file>   # 或透過 stdin 傳送文字

${CLAUDE_SKILL_DIR} 由主機注入。第一個路徑是此技能自己的 scripts/（獨立技能、完整套件或儲存庫）；後備路徑涵蓋內嵌根目錄的發行 ZIP，其中腳本位於 skills/write/scripts/ 下。

它根據語言環境強制執行字元層級的標點規則（半形/全形符號、中/拉丁間距、em/en 破折號），並跳過程式碼、行內程式碼、URL 與 Markdown 連結目標，因此絕不會對程式碼觸發；腳本標頭說明了確切的規則集。修正每個發現的問題，同時保留原意；--fix 僅將零歧義的中文案例改寫後輸出到 stdout。--lang auto 按固定優先級分類整個輸入：任何假名 → ja，否則任何 CJK → zh，否則任何諺文 → ko（保留，跳過），否則 → en，因此一個主要為中文的文字即使引用了韓文字元仍會分類為 zh；對於混合語言或主要為英文的文字，請傳遞明確的 --lang。檢查器僅負責字元層級的標點；引號方向及其他判斷由您與參考檔案負責。

長文模式

啟動條件：編輯超過約 300 行的 Markdown 文章或檔案，或包含多個 ## 章節以及表格與圖片的檔案（技術長文、部落格文章、深度探討）。

在長文中，主要問題通常是結構性的：相同檢查清單在不同章節重複、文章重複閱讀上方表格的內容、列表膨脹、整個冗餘章節。句子層級的AI味只佔較小部分。一次原地潤飾無法看到或修正結構性問題，這就是為什麼對長文執行單純的 /write 感覺像是改了措辭但保留了冗餘。因此，此模式覆蓋兩條硬性規則：結構性刪減與合併屬於範圍內，且輸出為變更點供審閱，而非改寫後的整塊文字。

工作流程：

1. 先繪製地圖，唯讀。 在編輯任何內容之前，閱讀整篇文章並列出每個 ## 章節、表格、列表與圖片。標記三個結構性問題：跨章節重複（相同檢查清單/判斷列表/核心主張出現在 2 個以上章節）、表格復讀（某章節的文章逐行描述上方表格的內容），以及整個冗餘的章節或段落。
2. 以變更點形式提出刪減。 對每個結構性刪減或合併顯示「修改前 → 修改後」，讓使用者選擇要套用的部分。切勿默默刪除整個章節或段落；先確認，因為其中可能包含其他地方找不到的事實（參見 references/write-zh.md 的「刪段之前先確認信息量」）。
3. 然後逐章節進行句子層級的去除AI味，依據 references/write-zh.md。
4. 輸出為變更點，而非整塊文字。 顯示修改了什麼，讓使用者可以審閱並保留自己的手動編輯。僅在使用者說「直接改」時才回傳完全改寫的文字；當您回傳完整改寫稿時，請先對其執行標點閘門。

不要對一篇 4 萬字的文章進行一次性改寫：這會默默覆蓋作者精心調整的措辭，且無法以 diff 形式審閱。請參閱 references/write-zh.md 的「結構級重複與表格復讀（長文專項）」以了解對應的內容規則。

雙語審閱模式

啟動條件：中英混合、「中文文案」、「雙語一致性」、「發行說明」

中文規則（來自 https://github.com/mzlogin/chinese-copywriting-guidelines）：

• 中文與英文字元之間加空格（CN文字EN → CN 文字 EN）
• 不混用標點符號（中文使用 、。？！；：，不使用逗號句點）
• 所有實例的術語保持一致

中文文件中的英文：標記未說明的英文，建議翻譯或補充上下文。

雙語對照：確認英文與中文版本傳達相同意思；標記翻譯損失。

產品本地化審閱模式

啟動條件：「本地化文案」、「多語言文案」、「localization copy」、「i18n copy」、產品/網站/應用程式字串、發行摘要文案、執行時目錄，或使用者詢問本地化文案是否夠道地。

載入 references/write-product-localization.md。如果中文是其中一個語言，也載入 references/write-zh-bilingual.md。

預設工作流程：

1. 先區分不同表面：發行摘要、網站頁面、文件/說明、執行時字串、法律/隱私文案與產生的頁面可能具有不同的語言覆蓋範圍與原始檔案。
2. 保留事實結構：版本、日期、連結、項目順序、佔位符與產品行為保持不變，除非使用者要求更改。
3. 根據各語言的成品進行審閱，而非僅根據英文意義。缺少重音符號、ASCII 替代、字面所有格、過時的語言路徑以及機械式的複數或撇號錯誤都是首要問題。
4. 在廣泛清理之後，進行第二輪檢查以找出替換造成的損害。在檢查產出之前，不要信任重音符號掃描或術語替換。
5. 當要求實作時，修補原始本地化檔案並重新建構產生的頁面。當僅要求審閱時，按表面與嚴重程度分組回傳發現的問題。

發行說明模板模式

啟動條件：「release」、「changelog」、「version」、「release notes」

從提交訊息產生：

• Breaking Changes
• New Features
• Fixes & Improvements
• Deprecations

格式：預設使用目標專案的風格。如果沒有專案風格可用，則使用編號項目搭配粗體標籤，每個項目一句話說明對使用者的影響，且僅在專案已使用雙語發行說明時才輸出雙語。

發行說明前置檢查

在起草之前，收集風格參考：

1. 閱讀目標專案的 CLAUDE.md 中的 Release Convention / Release Flow 章節。
2. 閱讀目標專案現有的發行來源作為風格、長度與密度的參考：更新日誌、發行說明、註冊表頁面、更新摘要或平台發行頁面。
3. 對於 GitHub 專案，gh release view --json body -R <owner>/<repo> 是讀取最新發行說明的首選方式（當 gh 可用時）。如果專案不在 GitHub 上，則使用專案文件或使用者要求指定的發行來源。
4. 如果使用者提到要與兄弟專案的發行風格進行比較，請在擷取之前要求提供目標識別碼或發行 URL。
5. 比對參考發行的項目數量、句子長度與語氣。不要發明新格式。
6. 每個發行說明項目保持一句話，除非參考專案明顯有其他做法。不要在發行說明中加入表情符號，除非目標表面明確是反應或慶祝性的社群表面。

發行說明內容規則

• 按使用者可感知的功能分組，而非按內部分類。「Polish」、「細節打磨」、「Misc improvements」、「Chores」不是使用者可以採取行動的分類。按產品表面（Clean / Uninstall / Status / Settings）或按使用者可見的動作（Faster startup / New keyboard shortcut / Fixed crash on M3）分組。
• 從 git log <last-tag>..HEAD 提取，而非從記憶中提取。閱讀每個 feat: 和 fix: 提交；不要因為小項目在提交形式中看起來微不足道就省略（iOS wrapper 支援、Dock 清理、AV-vendor 保護邊界從使用者角度來看並非「次要」）。
• 每個項目一句話，說明使用者可見的變更，而非實作細節。「使用 CKDownloadQueue observer 處理 App Store 更新」不是發行說明；「App Store 更新現在在應用程式內執行，而非開啟 App Store」才是。
• 雙語結構：當專案提供雙語發行說明時，將英文區塊與中文區塊作為同一發行項目內的兩個平行章節；不要逐條交錯。對於支援 HTML 的更新摘要 CDATA，使用標題分隔語言區塊，以免渲染的更新視窗將它們合併在一起。
• 標點符號：中文區塊使用全形，英文區塊使用半形。

公開回覆模式（GitHub issue / PR）

啟動條件：「回覆 issue」、「reply to PR」、「comment on #N」、「回 issue」，或使用者要求 GitHub issue / PR 評論的文字。

回覆主體的四條硬性規則：

1. 以 @<reporter> + 一句感謝開頭。 配合回報者的語言（中文 → 「感謝回報」/ 英文 → 「thanks for the detailed report」）。不要驚嘆號。不要表情符號。不要「🙏」。
2. 然後用一句話說明原因，一句話說明影響。 不要多段落的背景說明、不要內部符號名稱、不要逐步說明修正方式。
3. 然後說明發行狀態，確切為以下之一：已在 v<X.Y.Z> 中發佈、已在 main 上修正並將在下一版發佈、計畫在 v<X.Y.Z> 中發佈、不計畫（附上一行原因與替代方案）。每句話在發佈時必須為真：沒有「已發佈」卻沒有當前對話中的發行證據、沒有「已合併到 main」而變更尚未提交、沒有暗示的驗證（建置了分支、執行了成品）實際上並未發生。
4. 最多兩個段落，以一個空行分隔。不要項目符號列表、不要章節標題、不要程式碼區塊（除非確實需要一行指令）。

回覆是最終面對使用者的文字，不是代理程式日誌。不要寫「剛才我判斷錯了」、「前面回覆有誤」、「I re-read it and changed the comment」或任何關於自身過程的後設敘述。如果正在編輯現有的維護者評論，請將其替換為乾淨的最終措辭，就像這是使用者唯一會讀到的評論。

在發佈之前，使用 gh issue view <num> 或 gh pr view <num> 重新讀取當前的 issue / PR。不要憑記憶回覆；標題、狀態與作者語言在不同對話之間可能改變。

對於付費/訂閱使用者，用一句話承認購買關係與不便，然後說明邊界。不要過度解釋。當當前產品無法支援他們的設定時，建議最安全的實際路徑（升級 macOS、等待下一版、提供日誌、退款途徑），不要爭論。

關閉規則：當以 completed 關閉時，評論必須獨立說明修正了什麼以及預期的發行版本。當以 not planned 關閉時，評論必須獨立說明當前的邊界與替代路徑。不要依賴先前的討論串上下文作為解釋。

文件審閱模式

啟動條件：PDF、文件、白皮書、「review this document」、「check this document」、「審稿」

審閱檢查清單：

• 隱私掃描：偵測 PII（姓名、公司、任職日期、薪資暗示、地點細節）。如果任何文字暗示求職、競爭對手資訊或個人資料外洩，則硬性停止。
• 語氣一致性：標記語氣轉換、語域不匹配、公式化措辭。使用已載入的 write-zh.md 或 write-en.md 規則檢查AI模式。
• 雙語驗證：對於中/英文對照，確認翻譯準確性與術語一致性。套用雙語審閱模式規則。
• 渲染檢查：殘留的佔位文字（Lorem ipsum、TODO、[TBD]）、損壞的圖片連結。
• 持久文件掃描：如果文件是審閱報告、評分卡或診斷快照，則標記過時的宣稱、過時的行號參考、私人路徑、儲存庫專用指令以及當前評分框架。建議提取穩定規則，而非將快照保留為永續指引。

輸出格式：與文章改寫相同，但在審閱後的文字後附加 privacy: clear / N issues found。

段落連貫模式

啟動條件：「連貫性」、「段落連貫」、「可讀性」、「coherence」、「flow check」、「段落順不順」

不要改寫。而是依序處理每個段落：

1. 標記那些沒有信號就突然轉換主題的過渡。
2. 標記那些開頭句子沒有承接上一段結尾的段落。
3. 標記節奏問題：單調的句子長度（整個段落全部短句或全部長句）。
4. 對每個問題建議最小的修正：一個詞、一個重新排序的子句、一個橋接句子。

輸出：一個編號的問題列表，每個問題附帶段落位置與一行修正建議。然後詢問使用者是否要套用任何建議。

推文 / 社群貼文模式

啟動條件：「推特」、「twitter」、「X推文」、「tweet」、「social post」、「折疊長度」、「長文推特」、「發文」

當專案上下文或先前的成品顯示此風格時，對產品工程師專案套用五條公告規則：

1. 以社群為開端：以社交錨點（星星數、使用者感謝、誰的回饋驅動了修正）開頭。變更在後，不在前。
2. 重點而非完整：挑選 2 到 4 個最有趣的變更。省略整個項目是可以的。
3. UX 框架：每個要點以「你用它的时候...」或「有一種...的感覺」來表達，而不是「這個工具做了...」。
4. 一個立場：至少包含一句有觀點的句子，揭示為何做出這些決定。
5. 道地中文節奏：使用慣用語。避免聽起來像翻譯的詞彙。

以隨意的邀請結尾，而非行動呼籲。以一句簡短的句子邀請讀者試試看，而不是「立即升級」。

對於其他工程專案或英文貼文，套用相同的結構（社群開端、重點、UX 框架、一個立場、隨意結尾），並根據專案的語氣調整。

常見陷阱

發生情況	規則
未經要求就重新組織標題	不要重組結構；除非明確要求結構變更，否則原地編輯
在改寫後附加「修改清單」	輸出僅為編輯後的文字。無變更日誌、無評論。
對部落格草稿使用正式語域	配合目標讀者的語域。部落格是對話式的，不是學術性的。
對純英文文字套用中/英間距規則	雙語間距規則（半形/全形）僅在文字混合中英文時適用
將使用者的聲音潤飾成通用的上市文案	保留作者的節奏與立場。使用真實產品成品來強化事實，而不是取代聲音。
憑記憶或交接文件起草發行或社群文案	在做出事實宣稱之前，閱讀當前的發行頁面、更新日誌、issue/PR、可執行成品、產品頁面、螢幕截圖或提供的來源。
一次通過就寫好上市文案，沒有檢查即時截圖	迭代：起草，與真實產品截圖或頁面比對，緊縮措辭以符合實際發佈內容，重複直到文案與成品一致
將審閱報告潤飾到聽起來永不過時	將快照標記為快照，或將其提煉為穩定規則。不要讓過時的宣稱聽起來永遠有效
使用者指出一個詞「不是我的語氣」；只修正了該實例	被標記的詞標示的是氣味類別，不是打字錯誤。在回傳之前，掃描整篇文字中相同類別（相同語域、相同模板形狀）的所有實例

輸出

僅回傳編輯後的文字。如果文字被截斷或存在多個版本，請在主體後用一句話說明。否則，無包裝、無前言、無後記。