GitHub 倉庫優化

將任何 GitHub 倉庫轉變為一個高轉換、SEO 優化的登陸頁面，以驅動星星、追隨者和流量。你接觸的每個倉庫都應該看起來像一個前 100 名的開源專案。

此技能有兩種模式：

優化 — 重寫倉庫的 README、後設資料和結構以獲得最大轉換率
諮詢 — 使用下面的知識庫為使用者提供星星成長策略

目標（按優先順序）

星星 -- GitHub 上主要的社會證明指標
追隨者 -- 為倉庫擁有者的社交檔案帶來流量
可發現性 -- 在 GitHub 搜尋、Google 和 LLM 答案引擎中排名
流量 -- 將訪客轉變為使用者/追隨者
專業信譽 -- 透過結構和打磨傳達品質

步驟 0：使用者設定（自動更新）

在進行優化之前，你需要知道這個倉庫的擁有者是誰。此步驟僅執行一次——之後，設定將被重複使用。

檢查現有設定

尋找 ~/.claude/skills/github-optimization/.config.yml。如果存在，載入值並跳至步驟 1。向使用者顯示載入的內容，並詢問是否有任何變更。

如果沒有設定，偵測 + 詢問

自動偵測 來自 git 設定和 GitHub API：
- gh api user -- 獲取已驗證的 GitHub 使用者名稱和個人檔案 URL
- gh api repos/<owner>/<repo> -- 獲取倉庫擁有者（可能是組織或使用者）
- git config user.name -- 獲取本地 git 顯示名稱
詢問使用者 任何你無法偵測的內容：
- 顯示名稱 -- 他們的真實姓名或偏好的署名（例如，「張小明」）
- X/Twitter 帳號 -- 用於追蹤徽章（例如，「@zhangxiaoming」）。如果他們不想要，就跳過。
- 公司或組織 -- 用於頁尾署名（可選）
- 公司 URL -- 公司名稱的連結（可選）
- 網站 URL -- 個人或公司網站（可選）
儲存設定 到 ~/.claude/skills/github-optimization/.config.yml：

# GitHub 優化技能 — 使用者設定
# 此檔案為自動產生。可隨時編輯。
author_name: "張小明"
author_github: "zhangxiaoming"
x_handle: "zhangxiaoming"          # 留空字串 "" 以跳過追蹤徽章
company_name: "範例公司"      # 留空字串 "" 以跳過
company_url: "https://example.com"
website_url: "https://zhangxiaoming.dev"

在整個流程中使用這些變數：
- {OWNER} -- GitHub 使用者名稱或組織（來自倉庫 URL，依倉庫偵測）
- {REPO} -- 倉庫名稱（依倉庫偵測）
- {AUTHOR_NAME} -- 來自設定
- {AUTHOR_GITHUB} -- 來自設定
- {X_HANDLE} -- 來自設定（可能為空）
- {COMPANY_NAME} -- 來自設定（可能為空）
- {COMPANY_URL} -- 來自設定（可能為空）
- {WEBSITE_URL} -- 來自設定（可能為空）

如果任何欄位為空，則從輸出中完全省略該元素。不要有空佔位符或損壞的徽章。

更新設定

如果使用者說「更新我的設定」、「更改我的 X 帳號」或類似內容，請更新 .config.yml 檔案並確認變更。

優化流程

0. 設定         -> 載入或建立使用者設定（僅執行一次，自動更新）
1. 審核         -> 讀取當前的 README、描述、主題、倉庫結構
2. 關鍵字       -> 為此倉庫領域識別目標搜尋字詞
3. 後設資料     -> 優化倉庫名稱、描述（關於）和主題
4. README       -> 按照以下範本重寫為登陸頁面
5. 人性化       -> 在所有散文上執行人性化文字技能，以去除 AI 模式
6. 額外項目     -> 如果缺少 LICENSE、CONTRIBUTING.md 則添加
7. 發布         -> 提交、推送、應用 gh repo edit 以更新描述/主題

技能鏈接

此技能在執行過程中會呼叫其他技能：

humanise-text -- 起草 README 後，在所有散文部分調用 humanise-text 技能。這會去除 AI 寫作模式，使文案聽起來像真人寫的。不可協商——每個 README 都必須經過此處理。

步驟 1：審核

讀取當前狀態：

README.md 的內容和結構
倉庫描述（關於區塊）
主題/標籤
授權
檔案結構
任何現有的徽章

記錄缺少什麼、哪些部分薄弱、哪些部分良好。

步驟 2：關鍵字研究

識別 3-5 個開發人員會搜尋以找到此專案的目標關鍵字。考慮：

這解決了什麼問題？
它使用了什麼技術？
它屬於哪個領域？

這些關鍵字必須出現在：倉庫名稱（如果可能）、關於描述、README H1 和 H2 標題以及主題標籤中。

步驟 3：後設資料優化

關於描述

理想情況下少於 120 個字元，最多 250
以它做什麼開頭，而不是它是什麼
自然地包含主要關鍵字
格式：<動作動詞><什麼>為<誰/什麼>。<關鍵區別>

主題標籤

選擇 10-20 個跨三個類別的標籤：

目的標籤 -- 專案的用途
技術棧標籤 -- 使用的技術
領域標籤 -- 領域或行業

使用以下方式應用：

gh repo edit {OWNER}/{REPO} --add-topic tag1 --add-topic tag2 ...

步驟 4：README 重寫

README 是一個登陸頁面，不是文件。

README 範本

根據設定中可用的使用者資訊調整徽章：

<div align="center">

# <專案名稱>

**<一句話介紹 -- 用白話說明它的功能>**

<br />

[![Star this repo](https://img.shields.io/github/stars/{OWNER}/{REPO}?style=for-the-badge&logo=github&label=%E2%AD%90%20Star%20this%20repo&color=yellow)](https://github.com/{OWNER}/{REPO}/stargazers)

如果設定了 {X_HANDLE}，在星星徽章旁邊添加：

&nbsp;&nbsp;
[![Follow @{X_HANDLE}](https://img.shields.io/badge/Follow_%40{X_HANDLE}-000000?style=for-the-badge&logo=x&logoColor=white)](https://x.com/{X_HANDLE})

如果 {X_HANDLE} 為空，則完全跳過追蹤徽章。

然後繼續使用信譽徽章：

<br />

[![<徽章 1>](shields-url)](<link>)
&nbsp;
[![<徽章 2>](shields-url)](<link>)

---

<一段介紹。這解決了什麼痛點？為什麼人們應該關心？>

[安裝](#install) | [運作方式](#how-it-works) | [功能](#features) | [貢獻](#contributing)

</div>

徽章規則

第 1 行（號召性用語——大而醒目）：

帶即時計數的星星徽章 -- 始終放在第一位，style=for-the-badge，黃色
在 X 上追蹤徽章 -- 僅在設定了 {X_HANDLE} 時顯示

第 2 行（信譽徽章——相同大小）：

所有徽章使用 style=for-the-badge -- 切勿混合大小
選擇 2-4 個相關的：授權、歡迎 PR、語言/框架、建置狀態

區塊順序

為何存在 / 問題 -- 2-3 句關於痛點
之前 vs 之後（可選）-- 比較表格
安裝 / 快速開始 -- 少於 5 個步驟，理想情況下只有一個指令
運作方式 -- 視覺化工作流程（ASCII 圖、表格或編號步驟）
功能 / 使用案例 -- 表格或項目列表，易於掃讀
內部結構 -- 檔案樹（如果相關）
設定 / 選項（可選）
安全性（可選）
貢獻 -- 簡短、歡迎
授權 -- 一行
含號召性用語的頁尾 -- 重複星星 + 追蹤徽章

頁尾範本

根據設定動態建置：

---

<div align="center">

署名行——根據可用設定欄位建置：

如果作者 + 公司 + 網站：由 [姓名](GITHUB) 在 [公司](COMPANY_URL) 建立 | [網站](WEBSITE_URL)
如果作者 + 公司（無網站）：由 [姓名](GITHUB) 在 [公司](COMPANY_URL) 建立
如果作者 + 網站（無公司）：由 [姓名](GITHUB) 建立 | [網站](WEBSITE_URL)
如果僅作者：由 [姓名](GITHUB) 建立
如果都沒有：使用 github-optimization 技能建立

<br />

**如果這對你有幫助：**

[![Star this repo](star-badge-url)](stargazers-url)

如果 {X_HANDLE} 存在，也在此處添加追蹤徽章。

</div>

寫作規則

不可協商。這些定義了語調。

應該：

像對朋友解釋一樣寫。短句。主動語態。
每個區塊都以價值開頭，而不是機制
使用「你」和「你的」——直接對讀者說話
具體而非抽象
段落最多 2-3 句
使用表格進行比較

不應該：

使用 AI 廢話：「利用」、「簡化」、「賦能」、「無縫」、「穩健」、「尖端」、「革新」、「發揮力量」、「提升工作流程」、「加速」
以「這個專案...」或「這個工具...」開頭
寫大段文字
使用被動語態
添加填充詞：「基本上」、「本質上」、「簡單地」、「只是」
使用驚嘆號

標題中的 SEO：

H1 必須包含主要關鍵字
H2 應自然地包含次要關鍵字
為人類而寫，但要刻意考慮放置位置

步驟 5：額外項目

如果缺少則添加：

LICENSE -- MIT，除非使用者另有指定
CONTRIBUTING.md -- 簡短、歡迎、三個步驟的流程

除非被要求，否則不要添加：CODE_OF_CONDUCT.md、SECURITY.md、.github/ISSUE_TEMPLATE/

步驟 6：發布

使用描述性訊息提交所有變更
推送至遠端
透過 gh repo edit 更新倉庫後設資料
向使用者報告：變更內容、新描述、添加的主題、即時 URL

完成前檢查清單

星星成長知識庫

當使用者詢問「如何獲得更多星星？」、「發佈策略」、「推廣我的倉庫」或類似問題時，使用此知識庫提供建議。此區段為參考資料，不屬於優化流程的一部分。

渠道排名（按投資回報率）

排名	策略	努力程度	預期星星數	風險
1	疊加發布（HN + Reddit + X + PH 同一天）	高（1 天準備）	200-2,000+	無
2	Awesome 列表提交	低（PR）	緩慢積累，複利效應	無
3	README 優化 + 社交預覽	中（1 小時）	所有其他努力的 3 倍乘數	無
4	GitHub SEO（名稱、主題、描述）	低（30 分鐘）	被動長期發現	無
5	README 中的示範 GIF/影片	中	顯著提高轉換率	無
6	建立你自己的 awesome 列表	中	緩慢積累 + 交叉推廣	無
7	電子報投稿	低（電子郵件）	每次報導 50-500	無
8	YouTube 教學	高	最佳的持續長期驅動力	無
9	在 X 上的互惠列表	低	依賴人脈	無
10	Hacktoberfest 標記（十月）	低	50-200 季節性	垃圾 PR
11	Discord/社群建立	高持續	留存/倡導	無
12	會議演講	高	直接影響低，複利效應高	無

Hacker News 攻略

最佳時間： 週二至週四，太平洋時間上午 8-10 點。週日下午 6-9 點（競爭較低）。

標題格式： Show HN: [名稱] — [具體功能]

有效方法： 像同儕一樣寫，而不是行銷人員。不要用流行詞。以問題開頭。在第一小時內回覆每一條評論。在 5 分鐘內發布你自己的第一篇實質性評論。

門檻： 在前 30 分鐘內獲得 8-10 個真實讚 + 2-3 條深思熟慮的評論，才能進入前 10 名。

帳號要求： 最佳結果需要 250+ 經驗值且有技術評論歷史。新帳號會面臨審核。

抱團偵測很嚴格。 切勿在推文中說「請給我的 HN 貼文按讚」。使用私人渠道（電子郵件、Slack、Discord）通知他人。

實際結果：

Lago：連續 48 小時以上排名第一，主要驅動力達到 1,000 顆星
Encore：單次 Show HN 在一週內獲得 1,500 顆星
平均：24 小時內獲得 121 顆星，一週內獲得 289 顆星

Reddit 攻略

在發布前 2 週以上建立經驗值。 Reddit 的 90/10 規則：90% 真實活動，10% 自我推廣。

子版塊	備註
r/SideProject (453K)	明確允許自我推廣
r/programming (6M+)	嚴格禁止推廣，「我們如何建構 X」有效
r/selfhosted (500K+)	轉換率極高
r/webdev	僅限「Showoff Saturday」
r/opensource	歡迎連結，流量較低
r/coolgithubprojects	專門針對 GitHub 倉庫

預期： 每次成功貼文可獲得 50-300 顆星。根據每個子版塊調整訊息。

Product Hunt 攻略

投票重置： 太平洋時間每天凌晨 12:01。前 4 小時隱藏讚數。

獲得第一名所需的讚數： 工作日 600-800，週末 400-600。

最佳日子： 週二至週四。

預期： 進入前 5 名的每日產品可獲得 200-1,000 顆星。第一名可帶來 500-2,000+ 顆星。

時間表：

提前 4-6 週：建立 200-500 個電子郵件訂閱者
提前 1 週：準備所有素材
發布當天：太平洋時間凌晨 12:01 上線，回覆所有內容，太平洋時間早上 6 點發送電子郵件爆破

Twitter/X 攻略

有效方法： 短示範影片/GIF 優於文字。來自支持者的推文比自我推銷更能驅動星星。美國時間工作日早上（東部時間上午 9-11 點）。

預期： 發推文可使星標數增加 7%。病毒式影片推文可在 6 小時內達到 1,600 顆星。

疊加發布策略

每個快速增長的倉庫都使用的元策略：

時機	行動	預期星星數
前一周	投稿至電子報 (TLDR, Console.dev, Changelog)	--
發布當天上午	在 HN 發布「Show HN」（週二-週三，東部時間上午 8-11 點）	平均 121，最多 1,500
發布當天下午	在 Reddit 發布（r/programming, r/selfhosted, 領域子版塊）	50-300
發布當天	在 X 發布示範影片並讓支持者分享	50-500+
發布當天	Product Hunt 發布（東部時間凌晨 12:01）	200-1,000+
發布後一週	提交至 Awesome 列表	每個 10-50，持續累積
發布後一個月	根據反饋發布 v2，進行第二次推廣	50-200

實際案例：

Cal.com: 疊加發布 → 一週內 3,500 顆星，兩週內 6,000 顆星
Documenso: 疊加發布 → 使用 LaunchRock，3 天內 3,000 顆星
Hanko: 僅 HN 發布 → 一週內 1,800 顆星
Plane: 疊加發布 → 兩週內 2,000+ 顆星，一年內 15,000 顆星
Langfuse: 疊加發布 (HN + Reddit + PH) → 一週內 1,000 顆星

關於此技能

此技能旨在將你的 GitHub 倉庫變成一個星星磁鐵。它基於成長最快的開源專案使用的模式——清晰的 README、SEO 優化的後設資料以及人性化的文案。如果你有任何問題或回饋，請在倉庫上開啟一個問題。

在你喜歡的 AI 中提問

預覽

說明文件