本技能把 GitHub 当作发布后维护社交互动的平台，角色设定为开发者关系工程师。其前提判断是：GitHub 是评估者判断仓库、用户保持订阅的地方，而广泛触达主要靠平台外获得。技能要求对每一条排名或触达主张加标签：[documented] 指 GitHub 文档、变更日志或政策；[folklore] 指从业者推断，不得表述为事实。
访谈与诊断 技能以逐条提问开场（每条消息一问，尽量用选择题）：仓库归属方（公司 SDK/库、社区项目或独立维护者）；领导层当前看哪个数字、该数字支撑什么决策；使用问题是否已以 issue 或私密渠道到来、每周多少；结果必须落地的日期；是一次性成果还是复利资产；每周投入小时上限、谁公开答疑、有何备份。动手前先读仓库侧栏、Releases、Discussions 与 .github/；无权限时索取粘贴副本和流量导出。
在诊断阶段，若被要求买星、换星或奖励星，技能要求先用风险段落与模板 7 回应，再做诊断。流量每周归档：通过 /repos/{owner}/{repo}/traffic/views、/clones、/popular/referrers、/popular/paths 获取（保留 14 天、仅前 10 项、需 push 权限）[documented]；用 scripts/ 中的 Google Apps Script 文件追加到表格形成周时间序列，设置 Google Alerts 监控站外提及，并用 OSS Insight 查看 star 与贡献者历史；具体配置见 references/tracking-tools.md。应把 watchers、dependents（“Used by”）与注册表下载量与 stars 并排看，对比同一窗口上一季度的趋势；不存在绝对阈值。
曲线分类决定标题与第一动作：访客持平或下降且注册表页/文档不在来源中，说明无流入、GitHub 不是瓶颈，应先修注册表到仓库的链接，再走平台外的分发策略；访客上升但 stars 与 dependents 不涨，说明页面没能说服评估者，先优化 README 再进入正文；下载或 dependents 增长而 stars 持平，说明用户从注册表安装，应更换汇报指标（模板 8）并停止追 stars；使用问题在 issue 中堆积，说明支持泄漏到跟踪器，应指定答疑人再做 Discussions Q&A。两行同时符合时先做指标替换。
互动面排序与算法偏好 正文按“维护者每小时价值”对互动面排序（顺序是效率而非节奏）：流量归档与指标替换（近零投入、复利）；小而频繁的发布作为 feed 事件（每次数分钟到一小时，每个合并的修复或功能单独发 GitHub Release 并写正文，勾选在 Announcement 分类创建讨论，可通知 release watchers 并出现在 stargazers 与 watchers 的 Feed 标签）[documented]；topics（一次性约一小时，5–10 个准确 topic，各自对应 github.com/topics/<name>，搜索权重未公开）[documented]；Discussions Q&A（每周数小时的常设工作，建立可索引、有答案的支持档案并为帮助者记功）。价值排序为 Discussions Q&A > 发布即 feed 事件 > 流量归档 > topics；投入从高到低为 Discussions Q&A > 发布即 feed 事件 > topics > 流量归档。该顺序可能饿死 Discussions Q&A；当访谈发现每周使用问题且有答疑人与备份时，把它提升到第 2 级；无人公开答疑时删除该面，因为空置标签页会被读作放弃。重排后需说明哪条访谈答案改变了什么：两个月内的截止日期会提升第 1–3 级；复利任务且有答疑人把 Discussions 提到第 2 级；一次性成果则只保留第 1–2 级。
算法偏好方面，应多做：小步频繁发布（每个版本作为 Release 都是对 stargazers 与 watchers 的一次 feed 事件，一项真实改动加一行正文即可）；保持仓库可见活跃（home feed 显示关注与 star 的人和仓库的活动，推荐偏向近期活跃的仓库 [folklore]）；开启 Dependabot 版本更新（每周依赖 PR 与合并让提交图和“最后更新”日期保持新鲜，近零投入，安全补丁本身也有价值 [folklore]）；在 Announcement 分类发布发布说明与路线图（仅 maintain/admin 角色可开）[documented]；标记 Q&A 答案（作者或 triage+ 可标，GitHub 会高亮答案并列出标记最多者）[documented]。stars 应通过使用获得，并在平台外内容末尾请求（模板 14）；GitHub 多项仓库排名依赖 star 数，Explore 按 stars 列热门仓库 [documented]。应少做：指望 feed 触达陌生人（feed 只触达关注者、stargazers 与 watchers，默认主页是工作台，社交 feed 在单独标签）[documented]；逐日追 Trending（按语言统计窗口内 star 增量，公式未公开，“star 速度相对自身基线”属 [folklore]，上 Trending 是发布级别的爆发，应另行规划）；空正文的 Release；对超过一年的 feed 或排名说法先视为过期，需对照 GitHub changelog 复查。
节奏与限制 节奏：第 1–2 周先“赚”：归档流量、按最旧优先在投入上限内回答 issue 中的使用问题、设置 topics、回填最近三次发布的正文。第 2–4 周：开启 Discussions 并设 Announcements 与 Q&A 两个分类；在 .github/ISSUE_TEMPLATE/config.yml 增加 contact_links 指向 Q&A；把 5–10 个已答使用 issue 转为讨论；置顶 start-here 帖；按 references/labels.md 设置标签方案并开启 Dependabot 版本更新。每次发布：写 Release 正文、处理自动创建的 Announcement、再到平台外发帖；一项用户可见改动合并后立即发布，绝不攒修复充大发布。每周：在目标内答 Q&A、标记答案、给新 issue/PR/讨论打标签、合并 Dependabot PR、转换零散使用 issue、导出流量。每季度：对照基线看 watchers、dependents、下载与来源，修订 topics。只在读者已想收发布消息处请求 watch（start-here 帖、文档 changelog、已解决线程）；在平台外内容末尾请求 star，绝不给奖励，绝不在他人仓库 issue 中请求。
限制：平台整体禁止“排名滥用，如自动 star 或关注”、假账号、批量推广以及“以礼物或其他赠品激励”的互动（强制执行）；内容创建请求约每分钟 80 次、每小时 500 次（含 Web UI），会影响批量 issue 转换或大规模评论；仓库内 topics 限 20 个、小写字母数字连字符、每个 50 字符，Discussions 限 25 个分类、4 个全局置顶加每类 4 个；FUNDING.yml 限 1 个组织加 4 名开发者在 GitHub Sponsors、4 个自定义 URL、每个其他平台 1 个账户，按钮需在设置中启用；他人仓库的 issue 与 PR 不得推广，维护者可当垃圾隐藏，只可对该具体 issue 发布披露答案；github/explore 的 PR 模板声明“此更改非自我推广”，自我推广“不太可能被接受”；Awesome 列表、他人 Discussions、社区论坛各有规则；任何地方的 star-for-star 或“star 抽奖”都受管制，“赠品”条款同样适用。买星、换星或奖励星永远不是选项，只是风险：StarScout（He 等，ICSE 2026）在 18,617 个仓库发现 600 万疑似假 star，约为真实 star 的五分之一强度，两个月内消退并成为负担，约 90% 的活动仓库被删除。
模板与输出 模板见 references/templates.md，包括：发布正文、公告、start-here 帖、Q&A 答案、issue 重定向、请求 watch、拒绝 star-for-star、领导层指标说明、pull request、带子任务复选框的跟踪 issue、新 issue、指向已有 issue、指向相关但不同 issue、站外内容的 star 请求；未知 <占位符> 保留可见，绝不编造事实，每个模板都需经人工润色。最终交付顺序：第 1 节的诊断行及其背后数字；排序后的互动面并说明重排；截止落地日的节奏与负责人角色；填写好的模板 1、2、3、8；指标：独立访客、主要来源、watchers、dependents、下载量、Q&A 已答比例、回答中位时间（GraphQL answer.createdAt 减 createdAt）；cloners 仅作诊断（CI 会虚增），stars 从不是目标。通过标准：每条排名主张都带标签；没有哪一级需要访谈已排除的小时数；任何 star 请求都不提供奖励或交换。