# Github Repo Osint

> 对任意一个或一组 GitHub 仓库做情报研究时使用：产出分层简报——身份机制、硬指标、社区口碑、star 真实性档位、选型含义，每条结论带证据分级。触发于「调研这个仓库」「这个 repo 靠谱吗」「对比这几个仓库」「repo 口碑」「star 真不真」「开源选型尽调」等。

- Skill: `cuipengfei/github-repo-osint` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cuipengfei/github-repo-osint`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cuipengfei/github-repo-osint/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cuipengfei (https://skillmd.com/u/cuipengfei)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/cuipengfei/github-repo-osint

---


# GitHub 仓库情报研究

给定一个或一组 GitHub 仓库，产出带证据分级的情报简报。单个仓库出完整档案，多个仓库加横向对比。证据撑到哪，话说到哪。

## 核心原则（先于一切步骤）

1. **结论强度匹配证据层级**。筛查不是判决；「未发现异常」不等于「star 是真的」；实测强于 README 声明强于自评论文。
2. **仓库与工具用全名**。不造缩写，不造新词——领域已有名字就用既有名。
3. **引用 issue 必核当前状态**：open、closed、已标修复版本、复现失败后关闭——状态随引用写出。复现失败后关闭的 issue 不得当作现存问题。
4. **「已核实」只能在读完正文后说**。搜索摘要、目录页、README 前几行，都不算核实。
5. **对他人仓库下判断的三条边界**：只读公开数据，不要授权，能少要权限就少要；打星者的账号名等个人信息不写进报告，报告里只放统计数；仓库维护者给出的解释（比如「那波 star 是发布会带来的」），核实后跟原信号**并排放着**，不删原信号，也不静默吞掉解释。

## 五步流程

### 第一步：身份与机制

- 读目标仓库 README 正文，取能力边界和核心架构。照 README 的措辞写，不替作者拔高。
- 查同名撞车：引用 npm / PyPI 包数据前，先看包的 repository 字段是不是指向目标仓库。不是就弃用那个包的数据。

### 第二步：硬指标快照

- 有 gh CLI 就用 gh（已登录、配额高）；没有再退回 curl + token。动手前先查实际剩多少配额，翻页的活每页存进度，配额不够就停下，报告查到哪了。
- GraphQL 查：stars、pushedAt、watchers、issues（open 和 closed 分开数）、discussions、forks、贡献者分布（近年 commit 主要落在几个人手里——看清是几个人在扛，不要求算出精确数字）。单点快照，写明日期。
- 数字只摆出来，不解释。解释留到第四步和选型段。

### 第三步：社区口碑

- **来源执行时再定，不提前列清单**。先搜一圈看这个仓库的讨论实际集中在哪几个平台，哪里有讨论去哪里，没有的不要硬凑。
- 正面负面分开记。每条带：观点 + 完整 URL + 日期 + 来源类型。
- 官方自述不算口碑：README、官网、厂商博客都不算；作者自己发的帖和普通用户的评价分开列，不混在一起。
- **必须搜反方**：要写下一条正面结论，就搜它的具体反命题（比如「X 比 Y 慢的实测」），把搜索词和结果记进报告。搜不到反证就写「未发现反证」，不给结论加分。
- 多个仓库时按仓库拆给并行的调研子任务，每个仓库一份，交压缩简报，不倒原文。

### 第四步：证据分级核验

每条关键结论标一档：

| 标记 | 条件 |
|---|---|
| `[verified]` | 3 个以上独立来源且含高可信源；必须能给完整 URL |
| `[likely]` | 2 个来源，不够上一档 |
| `[single-source]` | 只有 1 个来源 |
| `[conflicting]` | 来源实质矛盾，把各方都列出来，不硬消解 |
| `[unknown]` | 没找到证据 |

三种证据形态分开写：实测 / 文档声明 / 推断。作者测自己系统的论文不算独立验证。同一内容多处转载按 1 个来源算。

**置信度和分数分开写**，三条规则（数字是参考例子，用的时候按场景自己校准，不是硬规则）：

- 样本太小提示置信度低：样本量三十上下的，降一档并写明告诫；一百上下的，降半档
- 多个信号合成一个结论时，整体置信度取所有参与信号里最低的那个，不做平均——薄数据不许被平均掉
- 某个信号数据不够就标 `[unknown]` 并写清缺什么，不许静默跳过后照常给精确结论

### 第五步：三块轻量筛查

**第一块：star 真实性**

1. 用 GitHub 官方周级 star 序列端点 `/repos/{owner}/{repo}/stargazers/history` 拉增长曲线。端点的返回形状、分页、权限都是执行时现场验证，不靠记忆。需要时可以只看历史某段（比如发布初期），不必总看最近。
2. 算：峰值周增量、突发比（峰值周 ÷ 中位数周）、前三周占比；有条件时用带滞后的滚动基线代替全期中位数——防老仓库自然衰减期拉低全期基线造成假峰值。
3. 事件对照：峰值和已知公开事件对时间——大 V 推文、Trending、Show HN、发布会、目录站收录，类型不限于这些。对得上 → 信号降级；对不上 → 别下结论，记「已查的来源里没找到解释」。
4. registry 下载量当参考（周下载 ÷ star），只作辅助——下载里有 CI、镜像、重复安装，不是真实用户数。

**第二块：活跃健康**

push / release 节奏、issue 首次响应的中位时长。判断「还活着吗」要按生态校准——一个稳定多年的小工具库安静下来是正常的，别按「最近没 commit」一刀切判死。

**第三块：维护者集中度**

看清是几个人在扛这个项目。集中度低是选型风险，但不参与 star 档位判定，写进选型段。

**star 档位**（只这四档，不发明新档）：

- **基准**：没有异常信号
- **观察**：只有一个异常信号，或者 star 数太小导致比值不可信——不够升级
- **数据不足**：关键数据拿不到或样本太小——连观察都给不了，写清缺什么
- **升级取证**：**两个互相独立的异常信号同时出现**才给这档——只有一个信号再扎眼也停在观察，因为单一极端指标区分不了病毒传播和购买。

「两个独立信号同时命中才升级」和样本量数字都是参考框架，用的时候按实际校准，别输出成硬规则。

逐个 star 账号的取证受 GitHub 端点权限限制；没权限就写「本轮拿不到」，不绕，也不拿别的数据冒充。

## 反模式清单

- 不用**没有明确权重或依据的单一分数**代替分项证据——watchers、issues、discussions 含义不同，等权加成一个「讨论度」是假的。真要合成，权重要写明、置信度要分开、每个成分能单独复查；本流程不产出综合总分。
- 不把筛查写成真伪判决。「掺水」「star 是假的」这类话超出筛查证据，禁写。
- 不引用没核过状态的 issue。
- 不把下载量叫真实采用。
- 不预设口碑来源。
- 不把一次性会话事实（失效日期、限速数字、撞包实例）写进结论——现场验证，现场记录在报告里。
- 不假设装了别的 skill。本 skill 自成一体。

## 输出契约

每个仓库七节，缺一不可：

1. **身份与机制**——它是什么、核心架构、能力边界。写成段落，别一句话打发。
2. **硬指标表**——stars / watchers / issues / discussions / forks / 最近 push，标快照日期。
3. **口碑正面清单**——观点 + URL + 日期 + 来源类型。
4. **口碑负面清单**——同格式；issue 类附当前状态。
5. **star 真实性档位**——四档之一 + 依据 + 拿不到的信号标注 + 每个信号的置信度。
6. **活跃与维护者健康**——节奏、响应、集中度，按生态校准后的判断。
7. **选型含义**——值不值得用、什么场景用、已知风险。

多个仓库时加横向对比表 + 全局边界声明：哪些验证过、哪些是推断、哪些 unknown。

报告开头放图例（五个分级标记 + 四个档位各一句白话）；结尾放验证边界（一手直读 / 文档声明 / 推断各占多少）、整体置信度（取参与信号里最低的）和判停依据。

## 升级取证路径

出了「升级取证」档才考虑这些，而且先向用户报成本：

- 逐个 star 账号的质量分析——要管理员权限或历史事件数据，可能拿不到，也可能要花钱
- 深挖传播事件——峰值周前后的全平台历史检索、目录站收录时间
- 放弃并标注——老实写「本轮定不了」比硬凑一个结论强