github-profile-authority-page

GitHub 个人主页权威展示页技能

目的

将 GitHub 个人主页打造成开发者展示页。

优秀的个人主页应回答以下问题：

1. 这个人是谁？
2. 他们解决哪类问题？
3. 我应该先看什么？
4. 他们为何值得信赖？
5. 他们目前在做什么？
6. 我可以在哪里了解更多信息或联系他们？

目标不是罗列所有内容，而是精选最有力的证明。

适用场景

当用户要求以下事项时，使用此技能：

• 重新设计 GitHub 个人主页 README
• 让 GitHub 个人主页显得更可信、更令人印象深刻或更专业
• 选择置顶仓库
• 展示项目、文章、成就或公开成果
• 让 GitHub 与 LinkedIn、作品集、博客、简历或求职定位保持一致
• 从众多项目中整理出“从这里开始”部分
• 避免显得自大，同时仍能展现专业权威性

首先：检查个人主页内容

检查：

• USERNAME/USERNAME 仓库
• 个人主页 README.md
• 置顶仓库
• 公开仓库及其描述
• 个人简介、网站、所在地、组织、社交链接
• 博客／作品集链接
• 最近的公开活动
• README 徽章、统计卡片和图片
• 文章列表或由 RSS 生成的博客部分（如果有）
• 个人主页是否暴露私人雇主的工作、家庭住址、机密信息或误导性声明

如果无法自动读取 GitHub 元数据，请输出一份手动检查清单。

个人主页策略

个人主页 README 与仓库 README 的作用不同。

仓库 README 推介一个项目。 个人主页 README 展示多个项目之间的一致脉络。

个人主页不应成为所有仓库的堆放处，而应体现一个聚焦且可信的专业方向。

命名与生态依赖

选择置顶仓库或重写个人主页时，请检查仓库名称。

如果置顶项目名称不佳、边界不清晰，或生态定位不一致，请使用 github-repo-product-naming。

一致的命名体系有助于打造优秀的个人主页。例如：

ProofStack   -> public-safe career proof
AgentDesk    -> agent-ready workstation setup
SystemSmith  -> engineering methods for code, agents, and architecture

这比置顶名称泛泛的仓库更好，例如：

proofstack
agentdesk
systemsmith

个人主页应展示产品名称，并以副标题说明具体用途。

反向总结的个人主页模式

优秀的技术类个人主页通常包含以下部分：

1. 首屏呈现明确的专业方向

常见公式：

# Hi, I'm <Name>

📍 <location or remote context> | <current role/wedge> | <credible anchor>

I build <category of things> for <audience/problem>. Right now I’m focused on <current focus>.

优秀示例：

# Hi, I'm Arthur

Junior Data Engineer building practical cloud/data workflows and agentic automation tools.

I use Python, AWS, Databricks, and browser automation to turn recurring high-friction workflows into small, reusable systems.

较弱示例：

# Hi there 👋

I'm passionate about technology and always learning new things.

2. 在长列表前添加“从这里开始”

使用 ## Start Here 指引访客查看 3-6 个最佳内容。

每个条目应为一行：

- **[Project](link)** — concrete outcome or reason to inspect it.

更好的写法：

- **[SystemSmith](link)** — reusable engineering methods for code, agents, docs, security, reviews, and architecture.

较差的写法：

- **[engineering-methods](link)** — my cool engineering docs.

3. 按类别展示项目组合

在“从这里开始”之后，按主题对项目分组。

类别示例：

• Agentic AI 与浏览器自动化
• 数据工程与云工作流
• 开发者效率
• 个人运营系统
• 机器学习／研究实现
• 写作与案例研究

避免列出一份没有尽头的清单。

4. 证据阶梯

使用最有力且可公开的证明材料。

可用的证明类型：

• 当前职位（如果公开）
• 已发布的公开仓库
• 文章／案例研究
• 开源贡献
• 毕业论文／研究项目
• 竞赛
• 演示
• 公开项目的指标
• 演讲／媒体报道
• 相关认证

绝不要包含私人雇主的指标、内部代码、私人客户数据或机密项目详情。

5. 当前重点

使用简短的部分：

## Current Focus

- Building agentic automation tools for browser-heavy workflows.
- Improving data/cloud engineering workflows with small CLIs and repeatable pipelines.
- Writing case studies about turning messy work into reusable systems.

6. 写作部分

如果用户有文章，请将其加入。对于技术可信度而言，写作往往比仓库数量更能体现项目判断力。

## Writing

- **[How I cleared 100 tickets in 2 days](link)** — workflow design, automation, and operational leverage.
- **[Article title](link)** — one-line reason to read.

7. 联系方式部分

使用精简的链接行或徽章：

## Connect

[Website](...) · [LinkedIn](...) · [Blog](...) · [Email](mailto:...)

不要公开私人家庭住址或个人电话号码。

推荐的个人主页 README 结构

使用以下默认结构。

# Hi, I'm <Name>

<One-line role/wedge.>

<2-3 sentence positioning paragraph: what you build, for whom, with what stack, and why.>

<p align="left">
  <a href="...">Website</a> ·
  <a href="...">LinkedIn</a> ·
  <a href="...">Blog</a>
</p>

## Start Here

- **[Project 1](...)** — outcome-oriented one-liner.
- **[Project 2](...)** — outcome-oriented one-liner.
- **[Article / case study](...)** — why it matters.

## Current Focus

- ...
- ...
- ...

## Projects

### Agentic AI & Automation

- **[Repo](...)** — what it does and why it matters.

### Data Engineering & Cloud

- **[Repo](...)** — what it does and why it matters.

### Developer Productivity

- **[Repo](...)** — what it does and why it matters.

## Writing

- **[Article](...)** — one-line takeaway.

## Background

- <Public-safe credibility anchor>
- <Relevant education/thesis/competition/open-source contribution>
- <Tools/stack, if useful>

## Connect

...

置顶仓库策略

GitHub 最多允许置顶 6 个项目。只有每个项目都足够优秀时，才使用全部 6 个名额。

推荐组合：

1. 当前最出色的旗舰项目
2. 最能体现专业技术栈的项目
3. 最出色的自动化/开发工具项目
4. 最出色的写作/作品集仓库或网站
5. 仍然相关的较早期研究/论文/机器学习仓库
6. 仅当某个实验性仓库有助于展现当前方向时，才将其纳入

不要置顶：

• 空仓库
• 已放弃的玩具应用，除非将其标注为学习档案
• 名称看起来像私有仓库的仓库
• 没有 README 的仓库
• About 描述含糊的仓库
• 多个高度相似的仓库

置顶仓库应与“从这里开始”部分相匹配。

项目一句话介绍公式

使用以下其中一种。

成果公式

<Repo> — helps <audience> achieve <outcome> by <mechanism>.

问题到解决方案公式

<Repo> — turns <messy recurring problem> into <repeatable workflow/system>.

案例研究公式

<Repo> — case study in <skill>, showing <specific technical judgment>.

学习档案公式

<Repo> — implementation of <paper/system> to understand <concept>; archived as a learning project.

GitHub 个人资料元数据检查清单

个人资料 README 的可见性

满足以下条件时，个人资料 README 会显示：

• 存在一个与 GitHub 用户名同名的公开仓库
• 该仓库的根目录中包含非空的 README.md

个人资料置顶项目

最多选择 6 个仓库/代码片段。

个人简介

推荐长度：一句话。

公式：

<Data/cloud/AI engineer> building <specific kind of tools> for <specific kind of workflows>.

示例：

Junior Data Engineer building practical automation systems for data, cloud, and agentic workflows.

网站

使用最有代表性的单个 URL：

• 作品集
• 博客
• 当前旗舰项目
• 仅当没有更好的选择时，才使用个人链接页

仓库描述

每个置顶仓库都需要一段 About 描述。使用以成果为导向的文案，而不要写“包含……代码”。

主题

每个置顶仓库都应添加相关主题。

确定性审核检查

首屏检查

• 前 7 行包含姓名。
• 前 10 行包含角色/专长方向。
• 前 15 行说明此人解决哪类问题。
• 顶部附近至少有一个公开链接。
• 不再出现“我对技术充满热情”之类的泛泛表述。

策展检查

• ## Start Here 出现在较长的项目列表之前。
• “从这里开始”包含 3-6 个条目。
• 每个“从这里开始”条目都有链接和以成果为导向的一句话介绍。
• 项目部分按主题分组。
• 除非有合理原因，否则任何部分的条目都不超过 8 个。

命名检查

• 置顶仓库的名称具有产品感，或能清晰描述仓库内容。
• 对较弱的名称标记 github-repo-product-naming。
• 产品名称和副标题的使用保持一致。
• 个人资料中的项目生态具有清晰可见的模式。
• 如果存在更合适的产品名称，“从这里开始”部分就不要展示令人困惑的内部文件夹名称。

可信度检查

• 至少有一个适合公开展示的可信度锚点。
• 如果有写作/文章，应将其纳入。
• 明确说明当前关注方向。
• 所有声明都有公开作品或用户提供的信息作为依据。
• 不详细描述雇主相关工作的机密内容。
• 不编造指标、星标、奖项、所属关系或生产环境使用情况。

置顶仓库检查

• 置顶项目不超过 6 个。
• 置顶项目与“从这里开始”所呈现的内容相符。
• 每个置顶仓库都有 README。
• 每个置顶仓库都有实用的 About 描述。
• 每个置顶仓库都有主题。
• 除非明确将空仓库或过时仓库作为档案，否则不要置顶。

风格检查

• 个人资料可在 30 秒内快速浏览完毕。
• 不要堆砌徽章却不作说明。
• 不要过度使用 GitHub 统计卡片。
• 除非动画有助于呈现内容，否则不要添加过多动态元素。
• 不要包含家庭住址、电话号码、API 密钥、含有机密信息的截图或雇主的机密数据。

输出格式

应用此技能时，请提供：

1. 个人资料诊断：当前个人资料传达了什么，以及缺少什么。
2. 定位选择：建议采用的身份切入点。
3. 项目命名／置顶诊断：
   • 较弱的项目名称
   • 建议的产品名称
   • 置顶仓库策略
4. 个人资料 README：完整替换内容或补丁。
5. 置顶仓库计划：最多六个置顶仓库，按顺序排列并说明理由。
6. 仓库元数据更新：
   • 每个置顶仓库的 About 描述
   • 每个置顶仓库的主题标签
   • 主页 URL（如有）
7. 写作／文章部分：精选链接和简短介绍。
8. 安全性删改：需要省略或匿名化的内容。
9. 确定性检查清单结果。

语气规则

使用：

• 直接、实用、具体的语言
• 克制而自信的表达
• 具体成果
• 项目处于实验阶段时，称其为“公开实验室”
• 旧教育类仓库称其为“学习档案”
• 项目列表中的简短介绍

避免：

• 过度自夸
• 缺乏依据的权威性宣称
• 泛泛而谈的热情表达
• 过多使用“AI”，却不说明具体任务
• 暴露雇主的私人信息
• 把实验项目说成生产级产品

Arthur 专属的默认个人资料方向

处理 Arthur Zakirov 的个人资料时，除非有更新的证据，否则默认采用以下叙述方向：

# Hi, I'm Arthur

Junior Data Engineer building practical data/cloud workflows and agentic automation tools.

I work with Python, AWS, Databricks, and automation-heavy developer workflows. My public GitHub is a lab for turning recurring friction — apartment search, profile/resume workflows, research, personal operations, and developer tooling — into small, reusable systems.

建议的章节主题：

• Agentic AI 与浏览器自动化
• 数据工程与云工作流
• 开发者效率
• 个人运营系统
• 机器学习／研究档案
• 写作／案例研究

默认的公开安全表述：

This GitHub contains public personal projects and learning work. It does not represent private employer code.

偏好的生态系统名称：

ProofStack   -> career proof and public-safe positioning
AgentDesk    -> machine and AI-agent workstation setup
SystemSmith  -> engineering methods for code, agents, and architecture

Arthur 的置顶仓库选择建议：

1. ProofStack，或当前最有力的职业／个人资料自动化仓库
2. AgentDesk，或当前最有力的设置／工作站／Agent 环境仓库
3. SystemSmith，或当前最有力的工程方法仓库
4. 写作／博客／作品集仓库
5. 一个数据／云工程仓库
6. 一个经过打磨的旧机器学习／论文／研究仓库，以展示专业深度

不要置顶空的占位仓库，除非明确标注为“即将推出”，且有内容扎实的 README 支持。