Practice 02 / Skill Radar
不再等社交媒体
告诉我什么值得看
GitHub 上很难持续定位近期热门或有增长潜力的 skills。Skill Radar 想建立一个独立信息源：自动发现，主动推送，最后由我判断。
- 状态
- 实验中
- 频率
- 6 小时
- 目标出口
- 飞书推送
01 / Problem
真正的问题不是没有信息，
而是信息来得太被动
过去，我对新 skill 的发现基本来自社交媒体推送。这意味着我看到什么，取决于平台正在让什么流行。
手动搜索 GitHub 又很难变成一个稳定习惯：要反复搜索、记录、对比 stars，还容易错过刚刚开始增长的仓库。
所以我不是想做另一个热门榜，而是想拥有一个不需要主动检索、也不依赖平台喂养的信息源。
02 / System
让自动化负责发现，
让人负责判断
- 01GitHub Search
扫描相关仓库与 `SKILL.md`
- 02Growth Signals
对比 12h / 24h / 7d stars
- 03Candidate Report
排除已收录项，生成候选摘要
- 04Feishu
主动推送到日常信息流
- 05Human Judgment
入库、观察或放弃
当前代码已用 GitHub Issue 输出报告；飞书是下一个要接入的推送层，不改变前面的发现与筛选逻辑。
03 / Signals
增长速度是提醒，
不是结论
12h+20 stars
24h+50 stars
7d+150 stars
当前默认阈值。拥有 `SKILL.md` 的仓库在 24h 达到主阈值 60% 时也可进入报告；历史不足时会明确标记“样本不足”。
04 / Human Judgment
自动化停在“值得看”，
不越过“值得收录”
`SKILL.md` 是核心产品，还是仓库里的附属示例？
它补充了现有目录，还是只是另一个重复实现？
README、License、安装方式和风险边界是否足够清楚？
05 / Limits
当前边界
- GitHub Search 会受 API 限流影响，单次结果可能不完整。
- 涨星只能说明“值得看”，不能证明“值得收录”。
- `SKILL.md` 的存在不等于它是仓库的核心公开能力。
- 当前 GitHub Issue 是已运行的过渡出口，飞书推送是下一阶段目标。