oss-bus-factor
Skill0 starsChanged 3 months agoMITView on GitHub
Estimate an open-source project's bus factor and maintenance health from public GitHub data. Use when judging whether a project is maintained or comparing projects' maintainership.
In this repository11 other files it gives its agents.
- build-justfileSkill
- c4-sequenceSkill
- create-issueSkill
- create-prSkill
- create-repoSkill
- dadsSkill
- handoverSkill
- mouse-doctorSkill
- ponytail-reviewSkill
- tmuxSkill
- writing-documentsSkill
The file
Files
OSS Bus Factor
Goal
GitHub に公開されている情報だけを使って、OSS の継続性リスクを 3 軸で verifiable に評価する。主観的な「コードの質」や「community 文化」は扱わない。
なぜ 3 軸か
| 軸 | 測るもの | 役割 |
| 1. org meta | structural potential (人を回せる素地) | 静的 snapshot |
| 2. commit / release cadence | actual liveness (今動いてるか) | dynamic 直近 |
| 3. PR merger 分布 | merge 権限の bus factor (誰が抜けたら詰むか) | 人間集約構造 |
軸 3 が bus factor の本体。contributor 分布は外部 PR が混ざって signal が弱
いので採用しない。merger は GitHub 権限モデル上 write 権限以上の人しか出ない
ので signal が強い。bot は .merged_by.type != "User" で除外する。
Workflow
1) 入力を確定する
<owner>/<repo>形式で 1 件以上受け取る。複数なら比較ブロックを縦に並べる。- option:
--commentが指定されたら、PR comment 用 Markdown を出力する。
2) scripts/measure.sh を走らせる
3 軸の生データはすべてここで取る。LLM は JSON を解釈するだけで、API 呼び出しや 集計を自前でやり直さない。
scripts/measure.sh <owner>/<repo>出力 JSON の構造:
org_meta.{owner_type, owner_created_at, public_members, description, public_repos, blog}owner_created_atは User / Org いずれも入る (account の age)description / public_repos / blogは Org のときだけ入る
cadence.{repo_created_at, pushed_at, commits_30d, commits_90d, releases[], archived}repo_created_atは project 自体の age (主要 signal)owner_created_atは org 分類の補助情報
merger.{distribution[], total, top_share_pct}
3) org 型を分類する
org_meta を見て次のいずれかに振る:
owner_type == "User"→ personalOrganization∧descriptionに foundation 語 (Apache, CNCF, Eclipse, Linux Foundation 等) → foundationOrganization∧public_repos >= 100∧public_members >= 50→ corporate umbrella- その他
Organization→ single-product vehicle
4) 各軸を rating する
| 軸 | 健全 | 注意 | 危険 |
| 軸 1 | foundation / corporate umbrella | single-product ∧ members ≥ 10 | personal もしくは members < 10 |
| 軸 2 | pushed_at < 90 日 ∧ commits_30d > 0 | pushed_at < 365 日 | それ以上、または archived == true |
| 軸 3 | top_share_pct < 50 | 50 〜 80 | > 80 |
軸 3 の例外: merger.total < 10 のときは sample が小さすぎて分布から bus
factor を推定できないので、判定不能 (n=<N>) として明示する。personal repo
で owner が直接 push してて PR を経由しない pattern では普通に起きる
(これ自体が「bus factor が極端に小さい」signal なので、総合 take でその点を補
う)。
5) 総合 take を 2-3 行で書く
各軸の rating を踏まえた所見。例えば「活発だが merge 権限が 1 人寡占。fork 維 持の覚悟がない採用は避けたい」のような、採用判断に直結する一言を添える。数字 を盛らない — JSON にない事実は書かない。
6) --comment mode のときの整形
PR comment 用の Markdown skeleton:
## OSS governance / 活発度の調査メモ
PR 比較表に載せきれない governance 観点を、GitHub 公開情報だけから verifiable
な範囲で記録。
### 1. org meta
(表)
### 2. contributor / maintenance
(merger 分布)
### 3. actual liveness
(commits / releases)複数 repo なら、上記の各セクションに repo 列を並べた表で出す。
Output format (default mode)
単一 repo:
### usebruno/bruno
- 軸 1 (org meta): single-product / members 3 / repo age 3.5 年 → 注意
- 軸 2 (cadence): pushed 今日 / 30d 83 commits / 週次 release → 健全
- 軸 3 (merger 分布): top 1 人で 87% (n=100) → 危険
総合: 活発だが merge 権限が 1 人寡占。fork 維持の覚悟がない採用は避けたい。軸 1 の age 表示は repo_created_at を基準にする。owner_created_at は分類
判定の補助で、output には基本出さない (account 年齢と project 年齢が大きく乖
離してて言及する価値があるときだけ書く)。
複数 repo: 上記ブロックを順に並べる。1 枚 table に詰めると軸の rating が読み にくくなるので、ブロック並列にする。
Scope 外
- private repo
- GitHub 以外の forge (GitLab / Codeberg / sourcehut) — 将来拡張
- 主観評価 (コードの質、community 文化)
依存
ghCLI (auth 済み)jqdate(BSD / GNU いずれでも動く。script 側で-v-30d‖-d '30 days ago'を fallback している)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

