用途
scan-github-stars 用于把维护者的 GitHub 星标仓库转化为可提议加入 README.md 的候选条目。该技能本身不决定某个项目是否应该收录，只负责收集候选并记录处理结果；收录判断属于 audit-the-list，收录规则写在 CONTRIBUTING.md 中。
主要流程
1. 扫描
运行 uv run python .claude/skills/scan-github-stars/scripts/scan_github_stars.py。当参数为 full 时，额外加上 --full。如果还没有 ledger（记录文件），普通运行本身就会覆盖全部星标。运行后从 stderr 读取丢弃计数；拿到候选 TSV 文件即完成此步。
2. 筛选 依据候选的名称、描述、话题和语言，对照 CONTRIBUTING 的质量要求第 1 条（Serves Python Developers，即服务 Python 开发者）进行判断，并指出它可能竞争的当前用例。筛选标准较宽松：只剔除明显不符合要求的，不确定的一律放行，因为真正的裁决者是 audit-the-list。在 full 扫描中，读取 prior 列作为上下文，只有出现新证据时才推翻先前的拒绝。
每完成一次筛除，就立即追加到 local/starred-scan.tsv，格式为每行 repo<TAB>yyyy-mm-dd<TAB>reason（文件需先创建表头 repo date reason），这样即使运行中断也能保留进度。该文件只追加，脚本读取每个仓库的最后一行。若某个幸存候选无法对应当前任何用例，则属于结构问题，需连同证据一并提交评审。
3. 评判 按目标用例对幸存候选分组。每组调用 audit-the-list，传入提示语："Judge proposed entries <names, each with its GitHub repo> for the <section — subcategory> use case. Evidence and Verdicts steps only; report the verdicts back. No preview page, no README changes, no commits." 如果某条拒绝理由指出了一个未收录的更好项目，该项目也应成为候选，在同一组中评判，并把来源标为在审计中发现而非星标。
4. 评审 对所有分组运行 preview-verdicts：幸存候选的 kind 为 candidate、verdict 为 add 或 reject；被替换条目的 kind 为 listed、verdict 为 remove；结构问题的 kind 为 structure、verdict 为 park 或 restructure。在理由中引用任何先前的裁决。对依赖主观判断的行，除非只是 add 但层级存疑，否则标记为 park。
5. 记录
- 已收录：按照 audit-the-list 第 5 步修改 README，每条条目单独一次提交。如果条目链接的仓库与星标不同（例如星标引擎的 Python 绑定或客户端），还需为该星标追加一行 ledger，注明为已收录
<entry> (<owner/repo>)。 - 被拒绝：在 "Rejected Additions" 下写一行：
- owner/repo -- yyyy-mm-dd, <downloads>/month (<source>): <reason>.，替换其先前的那一行。 - 已搁置：已收录条目留在 README.md 中；没有先前决定的未收录仓库无需记录。要重新开启之前被筛除或拒绝的仓库，删除其确切的 "Rejected Additions" 行，并向 ledger 追加
owner/repo<TAB>yyyy-mm-dd<TAB>parked。
适用场景与限制
适用于维护带质量门槛的 Python 资源清单类仓库，需要把维护者星标系统性转化为 README 候选。依赖 audit-the-list 技能、CONTRIBUTING.md 规则和 ledger 文件；具体安装方式、运行环境要求、收费或平台信息资料暂未提供。