claimcheck

claimcheck

オープンソースプロジェクトがひっそりと終わりを迎える、2つのケースを何週間もの損失が出る前に追跡します。

1. 古い着手表明。 誰かがイシューに「担当します」とコメントした後、姿を消します。イシューは「未割り当て」のままなので、次のボランティアが幽霊と競合するコードを書いてしまいます。
2. 放置された修正。 完成した作業がフォークのブランチに残り、PR にならないままです。実際のコミット、実際の差分があるのに、誰の目にも触れません。

claimcheck はこの両方をスキャンします。greenlight の後継で、greenlight が「このイシューはマージできる状態か？」と尋ねるのに対し、claimcheck は「やると言った人は実際に作業に着手したか、その作業はリリースされたか？」と尋ねます。

インストール

npm install -g @reneturcios/claimcheck
# or
npx @reneturcios/claimcheck claims owner/repo

Node 20 以上が必要です。認証済みのレート制限（1 時間あたり 5000 件）を利用するには、GITHUB_TOKEN（または GH_TOKEN）を設定してください。設定しない場合、1 時間あたり 60 件になります。レスポンスは ~/.cache/claimcheck にキャッシュされます。

CLI

リポジトリ内の古い着手表明を見つける

claimcheck claims modelcontextprotocol/python-sdk

オープン中で未割り当てのイシューをスキャンし、着手表明のコメント（明示的な着手表明、作業の意思表明、割り当ての依頼。ボット、メンテナー、イシューの作成者は除外）を検出します。関連する PR が作成されたことがあるかを確認し、古い着手表明から順に結果をランク付けします。

Stale claims in modelcontextprotocol/python-sdk: 2 stale of 5 claimed issues (threshold 45d)

[STALE] modelcontextprotocol/python-sdk#3287
  Fix: handle empty result sets
  https://github.com/modelcontextprotocol/python-sdk/issues/3287
  claimant: helpfuldev, 63d ago (want-to-work)

[IN FLIGHT] modelcontextprotocol/python-sdk#3290
  ...
  claimant: shipitdev, 5d ago (explicit-claim)

フラグ：--days 45 で古いと判定するまでの日数を変更し、--json で機械可読形式の出力を表示します。

着手表明の経過期間の区分

区分	経過期間	意味
FRESH	<14 日	着手表明者はおそらくまだ活動中です
WATCH	14～44 日	作業を重複させる前に確認してください
STALE	45～89 日	異議を唱えられる状態で、おそらく放棄されています
DEAD	90 日以上	ほぼ確実に放棄されています
WORK_IN_FLIGHT	任意	関連する PR があり、作業は実際に進行中です

フォーク上で放置された修正を見つける

claimcheck parked CloudCorpRecords/pdfcn

フォークのブランチ（デフォルトブランチを除く）を一覧表示し、それぞれをアップストリームのデフォルトブランチと比較して、そのフォークからのオープン中の PR があるかを確認します。1 件以上のコミットが先行し、オープン中の PR がないブランチは PARKED です。

Parked branches on CloudCorpRecords/pdfcn (upstream shadcn-labs/pdfcn): 1 parked of 4 branches

[PARKED_STALE] fix-typos
  ahead by 5 commit(s), last commit 20d ago
  no open PR on upstream

放置期間の区分（ブランチ先端のコミット日時を基準）

判定	経過期間	意味
PARKED_RECENT	<7 日	まだ作業を仕上げている可能性が高いです
PARKED_STALE	7～30 日	おそらく忘れられていますが、簡単に再開できます
PARKED_DEAD	30 日以上	アップストリームへのリベースが必要な場合があります

オープン中の PR があるブランチは IN_PR、アップストリームと同じ状態のブランチは EVEN と表示されます。どちらも放置された状態ではありません。

1 つのイシューの着手状況を確認する

claimcheck issue https://github.com/modelcontextprotocol/python-sdk/issues/3287

コメントから見つかったすべての着手表明者、その経過期間の区分、関連する PR の有無を表示します。

Docker で実行する

claimcheck は GHCR 上のコンテナーイメージとしても提供されています：ghcr.io/cloudcorprecords/claimcheck。

stdio MCP サーバーとして使用します。

docker run -i ghcr.io/cloudcorprecords/claimcheck

デフォルトの mcp 引数の代わりに、イメージ名の後ろに任意の CLI コマンドを指定できます。

docker run ghcr.io/cloudcorprecords/claimcheck <command> [args]

MCP サーバー

コメントやコーディングの前に確認するエージェント向けに、同じエンジンをツールとして提供します。

{
  "mcpServers": {
    "claimcheck": {
      "command": "npx",
      "args": ["-y", "claimcheck", "mcp"],
      "env": { "GITHUB_TOKEN": "ghp_your_token_here" }
    }
  }
}

ツール	入力	戻り値
stale_claims	repo（owner/repo）、任意の stale_days	古い着手表明を古い順にランク付けした一覧
parked_branches	fork（owner/repo）	比較データ付きの放置ブランチと、すべてのブランチ
issue_claim_status	url（イシューの URL）	着手表明者、経過期間の区分、関連する PR、概要

サーバーを直接実行することもできます：npx @reneturcios/claimcheck mcp（stdio）。

検出の仕組み

着手表明のヒューリスティック（greenlight の実運用で有効性が確認されたパターンをクリーンに再実装しています）：

• 強い着手表明： 「これを担当したいです」「私に割り当ててください」「この作業に取り組んでいます」「この作業を始めました」「PR を出します」など。
• 弱い関心表明： 「喜んで手伝います」「関心があります」「調べています」など。記録はされますが、着手表明として扱われることはありません。
• 除外対象： ボットアカウント、リポジトリのメンテナー（「担当します」は異議を唱えられる着手表明ではなく、トリアージの一環です）、実際の PR を予告した場合を除くイシューの作成者。

関連する PR がある着手表明は、経過期間にかかわらず WORK_IN_FLIGHT です。着手表明者は作業を完了しており、まだマージされていないだけです。PR のない着手表明だけが、時間の経過とともに STALE や DEAD になります。

開発

npm install
npm test        # 23 offline tests, node:test via tsx
npm run build   # tsc to dist/

エンジン（src/claims.ts、src/parked.ts）は、取得したデータを処理する純粋関数であり、test/fixtures/ 内のフィクスチャを使ってオフラインで完全にテストできます。src/github.ts には、ファイルキャッシュ機能を備えた REST クライアント（イシュー、コメント、PR 検索、ブランチ、比較、フォーク情報）が含まれています。

ライセンス

MIT、Rene Turcios 2026。

ツールキット

このツールは、オープンソースへの貢献作業のライフサイクルを構成する4つのツールのうちの1つです。すべて @reneturcios npm スコープで公開されており、CLI と MCP サーバー（<tool> mcp）の両方で利用できます。

1. gatefile（npx @reneturcios/gatefile）は、リポジトリの貢献要件を抽出し、コミット済みの contribution-gates.json にまとめます。
2. greenlight（npx @reneturcios/greenlight）は、イシューの事前チェック（GO / RISKY / TAKEN / GATED / STALE）を行います。check と scan では gatefile の出力を使用し、その後、イシューの確保、準備、PR の作成を行います。
3. claimcheck（npx @reneturcios/claimcheck）は、古くなった確保済みイシューや、フォーク上で保留中の修正を監視します。
4. prwatch（npx @reneturcios/prwatch）は、今すぐ対応が必要な内容に基づいて、オープン中の PR をトリアージします。