菜单
Polish and improve blog post writing. Use when user says "improve writing", "潤飾文章", "改善文筆", "優化文章", or wants writing feedback/editing on a blog post draft.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Deploy the blog to GitHub Pages. Use when user says "deploy", "部署", or wants to publish the blog.
Create a new blog post. Use when user says "new post", "新文章", "新增文章", or wants to start writing a new article.
| name | improve-writing |
| description | Polish and improve blog post writing. Use when user says "improve writing", "潤飾文章", "改善文筆", "優化文章", or wants writing feedback/editing on a blog post draft. |
| allowed-tools | Read, Edit, Write, AskUserQuestion |
本 skill 的目標是協助優化部落格文章的文筆，使其符合作者一貫的寫作風格。
學習者視角的技術筆記：文章不是教科書，是「我學了什麼、踩了什麼坑、想分享給同樣在學習的人」。語氣要誠實、直接，不需要裝作什麼都懂。
技術術語一律保持英文，不強行翻譯。
保持英文的詞彙：
可以接受的中文化： 一些已經高度本地化的詞彙可以用中文，例如「排程器」、「核心」（Linux 核心）、「執行緒」（搭配說明時）。 原則： 如果翻譯了反而讓讀者更困惑，就不要翻譯。
每篇文章的前言應該回答：「你為什麼要寫這篇？讀者為什麼需要看？」
好的前言結構：
好的前言範例（出自 concurrency01.md）：
最近在複習 jserv 老師的並行與多執行緒程式設計，一開始介紹了兩個常常被混淆的名詞，Concurrency 與 Parallelism，每次感覺懂了，過一陣子要我清楚的說明又有點講不太清楚，所以來寫一篇筆記紀錄一下。
好的前言範例（出自 fd.md）：
在 Linux 中常常會看到 fd 的身影，但一直沒有花時間去深入了解這個 fd 底層的實現，只是有模糊的概念而已，所以趁這個機會來整理一篇筆記，紀錄一下。
避免這樣寫：
## 前言
（觸發點 + 為什麼寫）
## 背景 / 核心概念
（先解釋「是什麼」，再解釋「怎麼運作」）
## 實作 / 原始碼解讀
（搭配 code block 和圖片說明）
## 小結 or 延伸閱讀
（可省略，但如果有 takeaway 就寫）
## reference
（一定要有，尤其參考了 jserv 老師的課程或論文）
## 問題描述
（具體說清楚遇到什麼問題、在什麼情境下）
## 解決方法
（直接給解法，附上 code 或指令）
（可選）驗證步驟 + 截圖
## 題目敘述
（一句話說清楚題目要求）
## 思路
（核心觀察是什麼？為什麼用這個方法？）
（說清楚時間複雜度思考，例如：「暴力法是 O(n²)，觀察到 X 特性可以降到 O(n)」）
## 解題紀錄
（code block，如果有重要的部分加行內注釋）
## 前言
（為什麼讀這篇 paper？主要貢獻是什麼？）
## 核心設計 / 問題背景
（作者要解決什麼問題）
## 各章節整理
（不要純翻譯，加上自己的理解和疑問）
## 個人心得 / 延伸思考
（可選，但推薦加）
## reference
「為什麼」優先於「是什麼」
類比讓抽象概念具體化
從小範例開始，再推廣
圖片和截圖是補充，不是替代
程式碼搭配說明
Front matter 的 description 欄位應該：
好的 description 範例：
透過實際操作 Linux network namespace、veth pair 與 bridge，一步步拆解 Docker 預設 bridge 網路模型的底層實現。用殺老師與鳴人的影分身之術，直觀解釋 Concurrency 與 Parallelism 的核心差異，並介紹 context switch、scheduler、preemptive 等核心名詞。從 fork() system call 出發，追蹤 Linux kernel v4.14 中 _do_fork() 的實作流程，理解 process 建立時 task_struct 的初始化細節。差的 description 範例（避免）：
GFS （太短，沒資訊）cobra default function （沒說清楚解決了什麼問題）本文介紹了... （被動、無聊）| 問題 | 修正方式 |
|---|---|
| 段落過長，沒有換行 | 每個獨立的概念或步驟單獨一個段落 |
| 沒有過渡語句，章節之間太突然 | 用一句話橋接（「了解了 X 之後，再來看 Y...」） |
| 正式語氣與口語語氣混用 | 統一用較輕鬆的口語，技術詞彙維持英文 |
待補 留在文章中 | 要麼完成，要麼刪除該 section |
| 沒有說清楚「為什麼這麼設計」 | 多問自己：「讀者看完知道這個設計解決了什麼問題嗎？」 |
| LeetCode 只貼 code 沒說思路 | 一定要加 ## 思路 解釋核心觀察 |
當用戶要求改善文章寫作時，依照以下步驟：
重要：改善文筆的目標是讓作者的原始聲音更清晰，不是把文章改成另一種風格。