mcpField
R
repo-eval

repo-eval

github.com/wilbeibi开发272 次安装4 天前更新
代码仓库

关于 repo-eval

repo-eval 是用于评估 GitHub 仓库发展势头和维护状况的 Python 脚本，并将结果放入象限图。它按月分析趋势并并列输出原始指标，便于核查评分。

主要功能

  1. 01分别评估发展势头与维护状况
  2. 02按月计算指标并拟合趋势
  3. 03输出可核查的原始指标
  4. 04支持单项评估与机器可读输出
  5. 05过滤机器人账户数据

适用场景

  1. 01比较候选开源仓库的活跃趋势
  2. 02识别人气高但维护减弱的项目
  3. 03区分成熟仓库与衰退仓库
  4. 04检查维护指标及其月度变化

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wilbeibi/wilbeibi-skills --skill repo-eval

安装后在 Claude Code 中输入/repo-eval确认已加载。

附带文件REFERENCE.mdscripts/repo_eval.py

详细介绍

repo-eval

为 GitHub 仓库的发展势头（人气变化趋势）和维护状况 （运营得有多好）打 0–100 分，然后将其放到象限图中。这两个维度彼此独立：仓库可能人气很高却无人维护，也可能小众但维护得无可挑剔。应结合起来看，切勿孤立地看待。

  • 发展势头来自 OSS Insight API（无需认证）： Star 历史记录、Issue/PR 创建者历史记录、组织分布。
  • 维护状况来自 gh（使用你现有的认证信息）：首次响应时间、合并时间、PR 接受率、Issue 半衰期、未关闭 PR 积压时长、发布节奏、自行合并率、贡献者集中度、CI。这些指标按月计算，覆盖 ≥12 个月的时间窗口（--months，默认值为 18 个月），并拟合斜率，因此评估依据是趋势，而不仅仅是当前水平（例如，响应时间逐渐变长意味着项目正在衰退，保持平稳则说明项目已成熟）。

脚本始终会在分数旁输出原始指标——评估结果可审计，而非黑箱。每项指标的定义、评分阈值和注意事项（压缩合并、机器人噪声、成熟与衰退的区别）请参阅 REFERENCE.md。

快速开始

# Full evaluation (needs network for OSS Insight + an authenticated gh)
python3 scripts/repo_eval.py vercel/next.js

# One axis at a time
python3 scripts/repo_eval.py vercel/next.js --momentum-only
python3 scripts/repo_eval.py vercel/next.js --maintenance-only

# Machine-readable (includes the per-month trend series under maintenance.monthly)
python3 scripts/repo_eval.py vercel/next.js --json

# Widen the maintenance trend window, or use weekly star granularity for young repos
python3 scripts/repo_eval.py vercel/next.js --months 24
python3 scripts/repo_eval.py vercel/next.js --period week

# Verify the metric math offline (no network)
python3 scripts/repo_eval.py --selftest

步骤

  1. 确认 gh auth status 显示已登录（维护状况维度需要认证）。OSS Insight 无需认证，但必须能够访问（有些沙盒会阻止访问 api.ossinsight.io）。
  2. 运行 repo_eval.py OWNER/REPO。如果某个维度无法访问，脚本会优雅降级，评估结果会显示“Incomplete”（不完整）——按需使用 --maintenance-only / --momentum-only 重新运行。
  3. 先看评估结果（象限），再对照原始指标进行核验。分数是透明的加权平均值；相比数字本身，更应相信指标。
  4. 解读时请遵循 REFERENCE.md 中的规则：发展势头低 + 维护稳定 + 积压持平 = 成熟，而非衰退；CI 通过 + 最近的提交全是机器人版本更新 = 疏于维护，而非健康。

注意事项

  • 零第三方依赖——仅使用标准库和 gh CLI。
  • 在计算贡献者、响应时间和合并统计数据前，会过滤机器人账号（*[bot]、dependabot、renovate、github-actions 等）。
  • Star 数和贡献者总数只会不断增加；此工具关注的是变化率和趋势，而非总数，因此即便项目已过巅峰，也仍会显示为走下坡路。
  • 对于活动极其频繁的仓库，Issue/PR 页面数量上限可能导致实际趋势窗口短于 --months；报告会输出 *_span_months，并在发生这种情况时添加 ! 提示，而受影响的趋势会返回 null，避免产生误导性的短窗口斜率。
  • 对于 SaaS-OSS 项目，贡献者集中度高是预期现象（公司就是维护者）——报告会将其列为风险，但不会给予过重惩罚。许可维度不在评估范围内；请另行核查（OSI 与 BSL/SSPL/仅提供源代码的许可之间的区别，以及许可是否发生过变化）。

评论

支持 Markdown