GitHub 仓库优化

将任何 GitHub 仓库转化为高转化率、SEO 优化的首页，驱动 stars、关注者和流量。你接触的每个仓库都应该看起来像一个顶级的开源项目。

此技能有两种模式：

优化 — 重写仓库的 README、元数据和结构，以实现最大转化
建议 — 利用下面的知识库为用户提供星增长策略

目标（按优先级排序）

Stars — 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 用户名 — 用于关注徽章（例如“@zhangsan”）。如果他们不想包含，则跳过。
- 公司或组织 — 用于页脚署名（可选）
- 公司 URL — 公司名称的链接（可选）
- 个人网站 URL — 个人或公司网站（可选）
保存配置 到 ~/.claude/skills/github-optimization/.config.yml：

# GitHub 优化技能 — 用户配置
# 此文件为自动生成。随时可编辑。
author_name: "张三"
author_github: "zhangsan"
x_handle: "zhangsan"          # 留空字符串 "" 以跳过关注徽章
company_name: "示例公司"      # 留空字符串 "" 以跳过
company_url: "https://example.com"
website_url: "https://zhangsan.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. 元数据     -> 优化仓库名称、描述（About）和主题
4. README     -> 按照以下模板重写为首页
5. 人性化     -> 对所有散文部分运行 humanise-text 技能，去除 AI 模式
6. 附加内容   -> 添加 LICENSE、CONTRIBUTING.md（如果缺失）
7. 发布       -> 提交、推送、执行 gh repo edit 以更新描述/主题

技能链式调用

此技能在执行期间调用其他技能：

humanise-text — 在起草 README 后，对所有散文部分调用 humanise-text 技能。这会剥离 AI 写作模式，使文案听起来像真人写的。不可协商——每个 README 都必须通过此步骤。

第 1 步：审计

读取当前状态：

README.md 内容和结构
仓库描述（About 部分）
主题/标签
许可证
文件结构
任何现有徽章

记录缺少什么、哪些薄弱、哪些良好。

第 2 步：关键词研究

确定 3-5 个开发者可能会搜索以找到此项目的目标关键词。考虑：

这解决了什么问题？
它使用了什么技术？
它属于哪个领域？

这些关键词必须出现在：仓库名称（如果可能）、About 描述、README 的 H1 和 H2 标题以及主题标签中。

第 3 步：元数据优化

About 描述

理想情况下不超过 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 句话说明痛点
前后对比（可选）— 比较表格
安装 / 快速开始 — 不超过 5 步，理想情况下一个命令
工作原理 — 可视化工作流（ASCII 图、表格或编号步骤）
特性 / 用例 — 表格或项目符号列表，易于浏览
内部结构 / 项目结构 — 如果相关，展示文件树
配置 / 选项（可选）
安全（可选）
贡献 — 简短、热情
许可证 — 一行
带行动号召的页脚 — 重复星星和关注徽章

页脚模板

根据配置动态构建：

---

<div align="center">

署名行——根据可用的配置字段构建：

如果作者 + 公司 + 网站：Built by [NAME](GITHUB) at [COMPANY](COMPANY_URL) | [WEBSITE](WEBSITE_URL)
如果作者 + 公司（无网站）：Built by [NAME](GITHUB) at [COMPANY](COMPANY_URL)
如果作者 + 网站（无公司）：Built by [NAME](GITHUB) | [WEBSITE](WEBSITE_URL)
仅作者：Built by [NAME](GITHUB)
什么都没有：Built with the github-optimization skill

<br />

**如果你觉得这有用：**

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

如果 {X_HANDLE} 存在，在此处也添加关注徽章。

</div>

写作规则

不可协商。这些定义了语气。

要做：

像对人解释一样写作。短句。主动语态。
每个章节以价值开头，而不是机制
使用“你”和“你的”——直接对读者说话
具体而非抽象
段落不超过 2-3 句话
使用表格进行比较

不要做：

使用 AI 套话：“赋能”、“优化”、“革新”、“无缝”、“稳健”、“前沿”、“利用”、“简化”、“充分发挥...的力量”、“提升你的工作流”
以“这个项目...”或“这个工具...”开头
写大段文字
使用被动语态
添加填充词：“基本上”、“本质上”、“简单来说”、“只是”
使用感叹号

标题中的 SEO：

H1 必须包含主要关键词
H2 应自然包含次要关键词
以人为本写作，但要有意识地放置

第 5 步：附加内容

如果缺失则添加：

LICENSE — MIT 除非用户另有指定
CONTRIBUTING.md — 简短、热情、3 步流程

除非有人要求，否则不要添加：CODE_OF_CONDUCT.md、SECURITY.md、.github/ISSUE_TEMPLATE/

第 6 步：发布

用描述性消息提交所有更改
推送到远程
通过 gh repo edit 更新仓库元数据
向用户报告：更改了什么、新的描述、添加的主题、实时 URL

完成前检查清单

Star 增长知识库

当用户询问“如何获得更多 stars？”、“发布策略”、“推广我的仓库”或类似问题时，使用此知识库提供建议。此部分是参考材料，不是优化流程的一部分。

渠道排名（按 ROI）

排名	策略	工作量	预期 Stars	风险
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 AM。周日太平洋时间 6-9 PM 竞争较低。

标题格式： Show HN: [名称] — [具体做什么]

有效方法： 像同行一样写作，而不是营销人员。不要用流行词。以问题开头。在第一小时内回复每条评论。在 5 分钟内发布你自己的实质性第一条评论。

门槛： 前 30 分钟内 8-10 个真实点赞 + 2-3 条有深度的评论才能进入前十。

账户要求： 最佳效果需要 250+ 积分且有技术评论历史。新账户可能面临审核。

刷票检测非常严格。 绝不要在推特上说“请给我的 HN 帖子点赞”。使用私人渠道（邮件、Slack、Discord）通知他人。

真实案例：

Lago：排名第一超过 48 小时，主要驱动力达到 1,000 stars
Encore：一个 Show HN 在一周内获得了 1,500 stars
平均：24 小时内 121 stars，一周内 289 stars

Reddit 操作手册

在发帖前 2 周以上积累积分。 Reddit 的 90/10 规则：90% 是真实活动，10% 是自我推广。

Subreddit	备注
r/SideProject (453K)	明确允许自我推广
r/programming (6M+)	严格禁止推广，“我们如何构建 X”有效
r/selfhosted (500K+)	转化效果非常好
r/webdev	仅在“Showoff Saturday”发帖
r/opensource	对链接友好，流量较低
r/coolgithubprojects	专门用于 GitHub 仓库

预期： 每次成功发帖获得 50-300 stars。根据每个 subreddit 调整信息。

Product Hunt 操作手册

投票重置： 每天太平洋时间 12:01 AM。前 4 小时隐藏点赞数。

排名第一所需的点赞数： 工作日 600-800，周末 400-600。

最佳日子： 周二至周四。

预期： 从每日产品前五名获得 200-1,000 stars。第一名可带来 500-2,000+。

时间线：

发布前 4-6 周：积累 200-500 名邮件订阅者
发布前 1 周：准备所有素材
发布当天：太平洋时间 12:01 AM 上线，回复所有评论，太平洋时间 6 AM 发送邮件轰炸

Twitter/X 操作手册

有效方法： 短视频演示/GIF 优于文字。来自支持者的推文比自我推文能带来更多 stars。美国时间工作日上午（东部时间 9-11 AM）。

预期： 推文带来 7% 的 starring 增长。病毒式视频推文可在 6 小时内获得 1,600 stars。

组合发布策略

每个快速增长的仓库都使用的元策略：

时间	行动	预期 Stars
前一周	向新闻通讯投稿 (TLDR, Console.dev, Changelog)	--
发布当天上午	发布 HN "Show HN"（周二-周三，东部时间 8-11am）	平均 121，最高 1,500
发布当天下午	发布 Reddit（r/programming, r/selfhosted, 相关子版块）	50-300
发布当天	推特演示视频 + 让支持者分享	50-500+
发布当天	Product Hunt 上线	200-1,000+
发布后 1 周	提交流程：Awesome 列表、GitHub 趋势标签	持续慢热增长

在你喜欢的 AI 中提问

预览

文档