GitHub Stars 分类整理

问题背景

GitHub 的 Star 列表会随时间变成「只收藏、不检索」的堆：仓库多了以后，默认只有一个未分类流，而官方列表上限只有 32 个。手工建列表、逐个分配既慢，又容易和已有命名体系冲突，误删或覆盖旧分类更是常见顾虑。

技能如何工作

本技能在用户说「整理我的 Star」「分类我的收藏」或「把某个仓库加到某列表」时，走固定流程：先用 gh 只读拉取 Star 与现有列表（记录 id、name、slug），再对每个尚未归类的仓库结合 topics、description 和项目形态做匹配。

分类策略强调 复用优先：能归入已有列表就不新建；多个候选时取更具体的一类；仅凭推测的低置信度仓库会搁置，避免乱贴标签。若已有列表已达 32 个，则跳过创建，只在现有列表里分配。需要新列表时，对搁置仓库做主题聚类，通常同一主题 ≥3 个仓库才考虑新建，并遵循单一职责、避免「前端与 UX」这类复合名。

写入阶段带节流：创建列表间隔约 300ms，分配约 200ms，批量时还会暂停；遇到 HTTP 429/403 会停 60s 并建议查 gh api rate_limit。定向添加模式则按用户指定的仓库与目标列表执行，前提仍是 gh auth status 通过且 token 含 user scope。

适用边界

• 不会删除或修改你已有的列表结构以外的「误操作式」改写；原则是 只读不删、保守写入。
• 不按编程语言一刀切分类（例如 Python 不等于 AI），也不会把所有带 UI 的仓库都塞进「前端」。
• 依赖 gh CLI 与网络；限流、权限不足或超时时需按技能表中的错误处理方式重试或刷新 scope。