github-project-radar

GitHub 项目雷达

当 GitHub 仓库源源不断进来、而你又不想把它们堆成另一摞书签时，就用这个技能。

目标不是逐个总结 README，而是避免重复收集，把"自己能用的"和"值得公开输出的"分开，并留下可持续维护的本地记录。

输入

• 一个或多个 GitHub 仓库链接。
• 可选：来源备注。
• 可选：目标受众或使用场景。
• 可选：已有的本地候选表。

工作流

1. 统一仓库主键。

   • 用 owner/repo 作为主键。
   • .git、/tree/...、/blob/...、查询参数、README 子路径都视为同一个仓库。

2. 检查重复。

   • 如果仓库已经存在，就更新 last_seen。
   • 不要新增第二行候选记录。
   • 只有真的出现新角度时才补 revisit_note。

3. 选择分级。

   • use：值得放进自己的工作流里试。
   • publish：值得做成内容、演示或教学材料。
   • test：有潜力，但必须先安装或验证。
   • archive：价值低、重复、过时、过窄或不相关。

4. 决定下一步动作。

   • record-only
   • install-test
   • content-brief
   • revisit-later
   • archive

5. 把结果写回候选表。

输出

每个仓库都输出：

• repo
• canonical_url
• duplicate?
• one_line_summary
• why_it_matters
• tier
• next_action
• review_notes

如果还没有表，就用 assets/candidate-table-template.md。

评估规则

• 不要把 star 当成有用性的证明。
• 不要因为"看起来有意思"就安装。
• 不要把每个仓库都硬做成内容。
• 不要让重复链接占用新的候选位。
• 需要安装验证时，一次只测一个仓库。
• 如果同一种失败连续出现两次，先停下来诊断，不要硬重试。

证据门槛

在把仓库标成 use 或 publish 之前，至少检查下面 6 项里的 3 项：

• README 能清楚说明它做什么。
• 最近提交或发布还能看出活跃维护。
• 安装路径看起来是合理的。
• 能用短演示或可视化结果说明价值。
• 它对应真实用户痛点。
• 它和你现有工具栈里的东西有明显差异。

安全

没有明确确认前，不要跑安装脚本、远程命令、凭据配置或破坏性操作。