GitHub Repository Optimization 是一个把 GitHub 仓库当作落地页来优化的技能。它的核心主张是：每经过它处理的仓库，都应该看起来像一个前 100 名的开源项目。该技能有两个模式：Optimize 模式负责重写仓库的 README、元数据和结构以追求最大转化；Advise 模式则利用内置知识库为用户提供涨星策略。
【优化目标】按优先级排序为：Stars（GitHub 上主要的社交证明指标）、Followers（为仓库作者引流）、Discoverability（在 GitHub 搜索、Google 和 LLM 答案引擎中排名靠前）、Traffic（把访客转化为用户/关注者）、Professional credibility（通过结构与打磨体现专业度）。
【工作流程】技能按以下流水线执行：0. 配置（加载或创建用户配置，只运行一次并自动更新）；1. 审计（读取现有 README、描述、话题、仓库结构）；2. 关键词（确定该仓库领域的目标搜索词）；3. 元数据（优化仓库名、About 描述与话题标签）；4. README（按下述模板重写为落地页）；5. 人性化（对所有正文调用 humanise-text 技能以去除 AI 写作痕迹，这是强制步骤）；6. 附加项（缺失时补充 LICENSE、CONTRIBUTING.md）；7. 发布（提交、推送，并用 gh repo edit 应用描述与话题）。
【用户配置】优化前需要知道仓库归属，检测方式包括 gh api user、gh api repos/<owner>/<repo> 与 git config user.name，无法检测的项会询问用户：显示名、X/Twitter 账号、公司或组织、公司 URL、网站 URL。配置保存于 ~/.claude/skills/github-optimization/.config.yml，并在整个流程中使用 {OWNER}、{REPO}、{AUTHOR_NAME}、{AUTHOR_GITHUB}、{X_HANDLE}、{COMPANY_NAME}、{COMPANY_URL}、{WEBSITE_URL} 等变量；任一字段为空时，对应元素会整体省略，避免出现空占位符或失效徽章。
【元数据优化】About 描述建议不超过 120 字符（最多 250），以“做什么”开头而非“是什么”，自然包含主关键词，格式类似“<动作动词> <做什么> for <面向谁/什么>。<关键差异点>。”话题标签选择 10–20 个，覆盖三类：用途标签、技术栈标签、领域标签，通过 gh repo edit {OWNER}/{REPO} --add-topic 逐个添加。
【README 重写】README 被视为落地页而非文档。模板要求：居中标题、H1 下的一行卖点、星标徽章（始终第一位，for-the-badge 样式，黄色，带实时数量）、X 关注徽章（仅当配置了 X_HANDLE 时）、第二行 2–4 个凭证徽章（License、PRs Welcome、语言/框架、构建状态等，全部同一尺寸）。正文段落顺序为：为什么存在/问题、前后对比（可选）、安装/快速开始（5 步以内，最好一条命令）、工作原理（图示/表格/编号步骤）、功能/用例（表格或列表）、内含结构（文件树）、配置/选项（可选）、安全（可选）、贡献、License 一行、带 CTA 的页脚。页脚根据配置动态生成作者归属，并重复星标与关注 CTA。
【写作规则】要求像人对朋友解释一样写：短句、主动语态、每节先讲价值、使用“你/你的”、具体胜过抽象、段落不超过 2–3 句、善用表格。禁止 AI 套话词汇（如 leverage、streamline、empower、seamlessly、robust、cutting-edge、revolutionize、harness the power of、elevate your workflow、supercharge），禁止以“This project...”开头、禁止大段文字、被动语态、填充词（basically、essentially、simply、just）和感叹号。H1 必须包含主关键词，H2 自然包含次级关键词。
【附加项与发布】缺失时补充 LICENSE（默认 MIT，除非用户另有指定）和简短的 CONTRIBUTING.md；除非被要求，不添加 CODE_OF_CONDUCT.md、SECURITY.md、.github/ISSUE_TEMPLATE/。发布阶段提交所有改动、推送远端、用 gh repo edit 更新元数据，并向用户报告改动内容、新描述、新增话题与线上地址。完成前有一份检查清单，涵盖配置、星标徽章、关注徽章、徽章尺寸一致、一行卖点、落地页风格、无 AI 套话、安装步骤少于 5 步、存在可视化元素、H1/H2 关键词、About 描述少于 120 字符、10–20 个话题标签、页脚 CTA 归属正确、LICENSE 存在、无失效链接、已提交推送等。
【涨星知识库】当用户询问“如何获得更多 star”、发布策略或推广仓库时，技能会使用内置知识库给出建议（该部分为参考资料，不属于优化流水线）。内容涵盖：按 ROI 排序的渠道清单（如 HN + Reddit + X + PH 同日叠加发布、Awesome list 投稿、README 优化与社交预览图、GitHub SEO、演示 GIF、Newsletter 投稿、YouTube 教程等，并标注投入、预期 star 与风险）；Hacker News 打法（最佳时间周二至周四太平洋时间 8–10 点、标题格式“Show HN: [Name] — [具体做什么]”、30 分钟内争取 8–10 个真实点赞、账号需 250+ karma、避免拉票）；Reddit 打法（提前 2 周养号、90/10 规则、各 subreddit 特性与预期 50–300 star）；Product Hunt 打法（投票每日太平洋时间 12:01 重置、前 4 小时隐藏票数、第 1 名所需票数、4–6 周预热时间线）；Twitter/X 打法（短视频/GIF 优于文字、支持者转发比自己发更有效、预期提升约 7% 星标）；叠加发布策略时间表；GitHub Trending 算法（衡量相对历史均值的增速，约每日 UTC 10–11 点更新）；GitHub SEO（仓库名即 H1、About 描述像 meta description、话题标签是最被低估的字段、新鲜度信号）；Awesome Lists 策略（含 sindresorhus/awesome 的 30 天仓库年龄、非 AI 生成、先审 4 个 PR、主分支须为 main 等要求）；Newsletter 投稿目录；快速增长技巧（社交预览图、首页演示 GIF、价值时刻的 star 提示、互推榜单、把 GitHub 主页当漏斗、Hacktoberfest 标签、里程碑抽奖、GitHub Actions 市场、跨仓库互链、All Contributors 机器人）；冷启动前 100 star 的分阶段策略（0–100 熟人私信约 60% 转化、100–1,000 社交证明开始复利、1,000+ 可达 Trending、上榜后自我加速）；以及核心洞察：增长最快的仓库恰逢开发者注意力浪潮顶峰，无法人为制造，但可以控制转化层。原文末尾以“The stacked launch is”中断，后续内容暂未提供。
【限制】原文未说明该技能的价格、收费方式、支持的平台范围或与其他工具的兼容性，这些信息暂未提供。