github-profile

GitHub 个人主页优化器

这项技能会审核 GitHub 个人主页，并生成经过优化的个人主页 README，同时提供有关元数据、置顶仓库和统计小组件的建议。优秀的 GitHub 个人主页就像开发者的门面——在别人读到任何一行代码之前，它就已影响他人对你的印象。

代码示例位于 AGENTS.md 中——需要实现特定修复时请阅读。本文包含工作流和审核清单。

工作流

1. 收集个人主页背景信息 — 了解此人或组织的身份，以及他们想展示的内容
2. 审核当前个人主页 — 为个人主页在公开平台上的各项内容评分
3. 生成个人主页 README — 撰写精致、易于浏览的 README.md
4. 建议元数据和配置 — 针对简介、置顶仓库、设置和小组件提供建议
5. 验证 — 确认渲染效果和徽章 URL，并总结后续步骤

---

阶段 0：收集背景信息

确定个人主页类型

询问用户（如果无法明确判断）：这是个人主页还是组织主页？两者的实现方式有很大差异：

功能	个人主页	组织主页
README 位置	username/username/README.md	.github/profile/README.md
可见性选项	仅公开	公开 + 仅成员可见（通过 .github-private 仓库）
置顶仓库	最多 6 个	最多 6 个公开仓库 + 6 个仅成员可见的仓库
贡献图	有	无
成就	有	无

收集信息

开始撰写前，收集以下信息：用户名、当前职位/公司、主要技术、希望展示的内容、风格（专业/随和/创意/简约）以及目标受众（招聘人员/协作者/投资者/开源社区）。

如果可以使用 gh（gh auth status），则自动获取：

• gh api user — 姓名、简介、公司、位置、博客、Twitter
• gh api users/{username}/repos?sort=stars&per_page=10 — 最热门的仓库，用于推荐置顶仓库
• gh repo view {username}/{username} --json name 2>/dev/null — 检查是否存在特殊仓库

---

阶段 1：审核

如果用户已有个人主页，则进行审核；如果是从头开始，则跳到阶段 2。为四个类别评分（每项 x/10，总分 x/40）：

个人主页 README（x/10）

• 是否存在？ 没有 username/username 仓库和 README.md 是最大的问题。
• 结构 — 理想顺序：问候/身份 → 当前工作 → 技术栈（徽章）→ GitHub 统计 → 精选项目 → 社交链接 → 个人特色。
• 长度 — 400-800 个单词。少于 200 个会显得内容单薄；超过 2,000 个则会显得杂乱。
• 易于浏览 — 10 秒内能抓住要点吗？使用 <details> 创建可折叠部分。
• 内容时效性 — 动态内容是否仍在更新？仓库连续 60 天没有活动后，GitHub 会停止定时 Actions。

个人主页元数据（x/10）

每个空字段都是错失的机会：

• 照片 — 清晰的头像照片，且在各个平台保持一致？
• 简介 — 已填写（上限 160 个字符），并说明职位、主要技术和个人特点？
• 公司 — 是否使用 @ 前缀添加链接？位置、网站 — 是否已填写？
• 社交账号 — 是否添加 Twitter/X、LinkedIn 链接？交叉链接有助于建立信任。
• 代词 — 体现包容性。状态 — 显示当前工作或可用状态？

置顶仓库（x/10）

最多 6 个仓库（包括参与贡献的仓库）：

• 是否用满全部 6 个位置？是否填写了仓库描述？技术类型是否多样？
• 优先选择有星标（社会认可度高）且符合职业/业务目标的仓库。
• 每个置顶仓库都应配有完善的 README（此处适用 github-repo 技能）。

贡献活动（x/10）

• 贡献图 — 活跃度是否合理？完全空白会引发疑问。
• 私人贡献 — 设置中是否启用了“Include private contributions”？
• 成就 — Starstruck、Pull Shark、Arctic Code Vault Contributor 等成就有助于提升可信度。

第 2 阶段：生成个人资料 README

根据审查结果（或从头开始），编写个人资料 README。阅读 AGENTS.md，了解详细方案。

个人资料 README 应易于浏览、体现个性且目标明确——每个部分都应服务于个人目标。根据受众调整语气和结构。

AGENTS.md 中的章节：个人资料 README 模板、统计小组件、技术栈和社交链接徽章、动态自动更新内容、组织资料 README、个人资料生成器。

---

第 2.5 阶段：元数据和可读性检查

1. metadata-check skill — 检查 GitHub 简介（160 个字符）以及你重写过的任何置顶仓库描述。检查重点：前置关键信息、内容具体、使用主动语态、适合截断显示（GitHub 在个人资料卡片中显示约 100 个字符）。
2. readability-check skill — 检查个人资料 README 正文。个人资料 README 通常会被快速浏览；一句被动语态或冗长的句子就会格外显眼。

直接应用修改。重点关注：(1) 简介 / README 开篇句（影响远超其他内容）；(2) 每个部分的第一句话（浏览时的切入点）；(3) 被动语态（用于第一人称内容时显得平淡）。

---

第 3 阶段：建议

要更新的元数据

提出具体建议：“将简介设置为：[文本，不超过 160 个字符]”、“为你的主要仓库添加以下主题：[列表]”、“将状态设置为：[建议]”。

置顶仓库策略

推荐置顶的 6 个仓库，并说明理由——技术多样性、星标数（社会认同）、README 质量、与目标的一致性。如果置顶仓库的 README 较弱，建议先改进（使用 github-repo skill）。

---

第 4 阶段：验证

• 确认 README 渲染正确（检查 Markdown 语法、徽章 URL、图片链接）
• 检查所有 shields.io 徽章 URL 是否有效（徽标名称和十六进制颜色是否正确）
• 验证统计小组件 URL 使用了正确的用户名
• 如果在本地生成，请提醒用户：如果魔法仓库（username/username）尚不存在，则创建它，并将 README 推送到该仓库
• 总结后续步骤：需要提交 / 推送的内容，以及需要在 GitHub 设置中手动修改的内容

---

输出格式

评分表（4 个类别，每项 x/10，总分 x/40）→ 按类别归纳的发现 → 生成或修改的文件 → 后续步骤（设置修改、置顶仓库、GitHub 手动配置）。

---

核心原则

• 易于浏览胜过面面俱到。 个人资料会在 10 秒内被快速浏览。删去所有不值得占据版面的内容。
• 个性胜过模板。 根据个人目标和受众调整语气、结构和内容。创意开发者和初创公司创始人需要不同的个人资料。
• 填全每个字段。 空白的元数据字段、缺少的置顶仓库和空白描述都是错失的机会。
• 在能增加价值的地方使用动态内容。 统计图片（通过 lowlighter/metrics）和可选的自动更新博客订阅源能让个人资料保持新鲜——通常各用一个就足够。避免使用由第三方托管、可能会随机返回 502 错误的小组件；请参阅 AGENTS.md。
• 添加所有交叉链接。 GitHub、LinkedIn、Twitter/X、个人网站——每个个人资料都应链接到其他资料。