| name | good-writing-zh |
| version | 1.1.0 |
| description | 中文好寫作指南：提升中文寫作品質與改寫既有文章。基於 Paul Graham、余光中、王鼎鈞的寫作智慧。
使用時機：
- 用戶說「潤稿」「改寫」「rewrite」「讓文字更順」
- 用戶要求「改善文筆」「寫好一點」「高品質中文」
- 用戶提供文章並要求修改或潤飾
- 需要產出高品質中文內容時
技術文件（README、API 文件、CLI 說明）請使用保守模式（見下方模式三），避免改動結構化列舉與術語連綴。
觸發詞：/good-writing、/潤稿、good writing、潤稿、改寫、rewrite、文筆、讓文字更順、技術文件潤飾、conservative 模式
|
| user_invocable | true |
| argument_hint | <article text or file path to rewrite> |
中文好寫作
注意： 本 Skill 專注於句型結構精簡與節奏打磨。若需處理 AI 生成痕跡、翻譯腔與中國用語，請搭配 humanizer-tw。建議順序：先 humanizer-tw（去機器味）→ 再 good-writing-zh（打磨節奏）。
節奏規則
氣口
兩個標點符號（，。；：！？）之間，連續字數不超過 15–20 字。超過就該斷句或加逗號。
錯落
相鄰兩句長度差異應 > 5 字。避免連續 3 句以上長度相近（±3 字）。
句尾
- 名詞收尾 → 穩
- 動詞收尾 → 勁
- 助詞收尾（的、了、呢）→ 軟
避免連續句尾都落在同類型。
改寫技法
一、刪贅字（連續「的」）
連續三個「的」→ 想法沒整理好，至少刪一個。
原句：這是公司的新的產品的宣傳方案。
改寫：這是公司新產品的宣傳方案。
（理由：三連「的」刪為一個，語意不變）
原句：他提出的關於市場的未來的發展報告。
改寫：他提出的市場未來發展報告。
（理由：「關於」多餘，「的」可精簡為一個）
二、刪贅字（進行/實施/加以）
「進行」「實施」「加以」通常可直接刪除。
原句：我們對此問題進行了深入的討論。
改寫：我們深入討論了這個問題。
（理由：刪「進行」，動詞前移）
原句：相關部門已對該方案加以審核。
改寫：相關部門已審核該方案。
（理由：刪「加以」，直接用動詞）
三、拆長句
原則上不超過 30 字。例外：緊密條件句、排比句、專業術語連綴可放寬，但需以標點確保內部停頓。
原句：由於天氣不好加上交通阻塞的關係，所以他沒有辦法準時抵達會場參加會議。
改寫：天氣差，路又塞。他遲到了。
（理由：一句塞了兩個因果，拆開各自獨立）
原句：為了能夠更好地滿足客戶在不同場景下對於產品功能的多樣化需求，我們決定重新設計整個系統架構。
改寫：客戶需求多樣，現有架構撐不住。我們決定重新設計。
（理由：40+ 字壓縮為兩句，因果更清晰）
四、砍開頭
直接刪掉填充開頭，從重點開始。
原句：關於這個問題，我認為我們應該重新思考策略。
改寫：我們應該重新思考策略。
（理由：「關於這個問題」是廢話）
原句：基本上來說，這個方案的可行性是比較高的。
改寫：這個方案可行性高。
（理由：砍開頭 + 刪「是...的」句式）
五、還原強動詞
「弱動詞 ＋ 抽象名詞」→ 還原為單一強動詞。被動語態 → 主動語態。
常見模式：
- 「進行 X」→「X」
- 「做出 X」→「X」（做出決定 → 決定）
- 「給予 X」→「X」（給予協助 → 協助）
- 「加以 X」→「X」（加以改善 → 改善）
- 「達到 X 的目的」→「為了 X」
- 「被...所...」→ 主動語態
原句：我們需要對現有流程做出改善。
改寫：我們需要改善現有流程。
（理由：「做出改善」→ 直接用「改善」）
原句：這個問題被許多研究者所關注。
改寫：許多研究者關注這個問題。
（理由：「被...所...」→ 主動句，更有力）
原句：本計畫旨在達到提升效率的目的。
改寫：本計畫旨在提升效率。
（理由：「達到...的目的」是多餘包裝）
檢查清單
改寫完成後逐項檢查：
- 原則上沒有超過 30 字的句子（緊密條件句、排比句、術語連綴除外，但需有標點停頓）
- 沒有連續三個「的」
- 相鄰句長差異 > 5 字，無 3 句以上等長（±3 字）
- 開頭沒有填充廢話
- 句尾沒有連續相同類型（連續「的」「了」「呢」）
- 「進行」「實施」「加以」能刪的都刪了
- 「弱動詞＋抽象名詞」已還原為強動詞，被動語態已轉主動
工作流程
模式一：改寫既有文章
依序輸出三個區塊：
<diagnosis> — 逐句掃描原文，列出所有違規：
- 哪些句子超過 30 字
- 哪裡有連續「的」
- 哪些開頭是廢話
- 哪些「弱動詞＋名詞」可還原
- 節奏是否單調（連續等長句）
<planning> — 對每個違規擬定修改策略：
- 在哪裡斷句、刪哪個贅字、怎麼還原動詞
- 確保拆句後邏輯仍連貫（必要時補銜接詞）
<rewrite> — 輸出改寫版本，以粗體標註主要修改處。
<diagnosis> 和 <planning> 是改寫流程的必要輸出，確保修改全面且一致。
模式二：寫作時自動套用
寫中文內容時，自動遵循上述節奏規則、改寫技法與檢查清單，不需額外提示。
模式三：技術文件保守模式（conservative）
觸發時機：處理技術 README、API 文件、CLI 說明、錯誤訊息、技術 blog，或使用者明確要求「只改標點/氣口，不動結構」。
這個模式之所以存在，是因為技術文件有大量不該被「潤飾」的內容：程式碼範例、命令列片段、錯誤訊息字串、API 名稱、參數列表。完整模式的「錯落」「打破公式化」規則若強行套用，會把結構化列舉（例如表格說明、指令解釋）改得面目全非，反而傷害資訊傳達。
只執行（四類）：
- 刪連續三「的」—— 語意無損時
- 刪「進行／加以／實施」—— 能直接用動詞時
- 拆超過 30 字的單句 —— 但見下方術語連綴例外
- 修氣口 —— 標點間連續 15–20 字加逗號斷開
停用：
- 「錯落」規則（相鄰句長差異 > 5 字）—— 技術列舉同結構是刻意的
- 「打破公式化段落」—— 首先/其次/最後在操作步驟中反而清楚
- 重組段落順序、重寫語義
- 動用「句尾類型輪換」
絕對不碰：
- 程式碼區塊（
…、inline）
- CLI 指令、檔案路徑、URL、Markdown 連結語法
- 表格結構與欄位
- 英文技術術語（保留原樣，即使夾在中文句中）
- YAML front matter、語言選單、版本標註
- 使用者明確標示「不改」的區塊
術語連綴例外（即使超過 30 字也不強拆）：
以下情境的長片段視為已有「內部停頓」，不需要加逗號：
- 頓號列表：「
.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php」—— 每個副檔名都是一個停頓點
- 破折號引介：「完全多模態 —— graphify 會用 Claude vision 從這些內容中提取概念」—— 破折號已分段
- 括號補充：「對程式碼檔案做結構分析（類、函式、匯入、呼叫圖、docstring）」—— 括號本身是停頓
- 連字符連綴：「程式碼-論文之間的邊會比程式碼-程式碼邊權重更高」——
- 提供視覺停頓
判斷原則：一個片段若去掉中英文/數字/標點後剩不到 15 個中文字，即使字元計數長也不算違規。
理論背景見 references/guide.md。整合自 Paul Graham〈Good Writing〉、余光中、王鼎鈞。
