メニュー
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 ページを確認してインストールできます。
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.
SOC 職業分類に基づく
| 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 沒說思路 | 一定要加 ## 思路 解釋核心觀察 |
當用戶要求改善文章寫作時，依照以下步驟：
重要：改善文筆的目標是讓作者的原始聲音更清晰，不是把文章改成另一種風格。