greenlight

Greenlight

Greenlight は、オープンソースへのコントリビューションにおける事前確認と調整を担うレイヤーです。外部コントリビューター（その多くは AI エージェントになりつつあります）と公開リポジトリのメンテナーの間に立ち、ほかのツールでは答えられない疑問に答えます。ここにコントリビューションできるのでしょうか。この Issue は実は誰かに取られていないでしょうか。このリポジトリのルールは何でしょうか。ほかに競争相手はいるでしょうか。そしてメンテナーにとっては、誰がキューに大量の投稿をしているのか、何を安心してマージできるのか。

このレイヤーが必要な理由

ベンチャー資金の流れを追えば、資金が向かっていない分野が見えてきます。Cognition（Devin）は自律型コーディングエージェントを企業の独自リポジトリ内で動かすために、評価額480億ドルで約20億ドルを調達しました。Factory も評価額50億ドルで2億ドルを調達しました。CodeRabbit は8,800万ドルを調達（評価額は約5億5,000万ドル）、Graphite は Cursor に買収される前にシリーズBで5,200万ドルを調達し、Greptile はシリーズAで2,500万ドルを調達しました。いずれもチームの独自のプルリクエストをレビューするサービスです。OpenHands はエージェントのランタイムです。資金を得たプレイヤーはどれも、あなたが組織の内部にいることを前提としています。

この境界を担うものは存在しません。VC の支援を受けたツールで、外部コントリビューターの疑問に答えるものはありません。ここにコントリビューションできるのか、この Issue は実は誰かに取られていないか、このリポジトリのゲートや AI ポリシーは何か、ほかに競争相手はいるのか。VC の支援を受けたツールで、メンテナーの疑問に答えるものもありません。オープンな PR 30件のうち、どれが重複しているのか、誰が何を担当しているのか、どの担当表明が古くなっているのか、エージェントが作成した PR のうち何を安心してマージできるのか。Greenlight はそのレイヤーであり、毎週実際のコントリビューションキャンペーンを運用して構築されています。

課題

AI によってコードを作るコストは下がりました。今ではコントリビューションの調整がボトルネックとなり、具体的で繰り返し発生する形で問題を引き起こしています。

• 見えない競争。 Issue の一覧表示は実態を映しません。usebruno/bruno で厳選した注力セッションを行ったところ、有望な Issue 7件のうち6件は、一覧表示や検索結果には出ず、Issue のタイムラインにしか表示されない PR によって、実はすでに対応されていました。すでに完了している作業に、週末を費やしてしまうことがあります。
• ゲートと禁止事項。 Greenlight 独自の Agent Policy Index は現在505のリポジトリを追跡しており、そのうち127件（25％）にコントリビューションのゲートがあり、19件はエージェントによるコントリビューションを全面的に禁止しています。リポジトリ全体（nuxt、uv、Gradio、Activepieces）が外部からの PR を完全に受け付けなくなっています。誰も教えてくれませんでした。AGENTS.md に書かれていたのです。
• AI による PR の重複。 複数のコントリビューター（人間またはエージェント）が同じ Issue を競うと、メンテナーには内容の重複する PR が3件届き、調整する手段がありません。GitHub にはコメント機能しかなく、担当の申請システムはありません。
• あちこちに散らばるルール。 CLA、DCO の署名、変更セット、コミット形式、担当の申請。リポジトリごとに独自のルールを設け、それぞれ異なるファイルに隠し、技術的な理由を付けて PR を却下します。

これはコーディングの問題ではなく、調整の問題です。コードエージェントはますます賢くなる一方で、境界はますます複雑になっています。Greenlight はその境界で機能します。

Greenlight が行うこと

判断から解決、調整までの3つのレイヤー：

レイヤー	答える質問	主なコマンド
判断	この課題は自分が引き受けるべきか？このリポジトリに時間をかける価値はあるか？	check、scan、friction、xray、racecheck、wave、preflight
解決	自分の PR は通るか？何が壊れたのか？次に何をすべきか？	ci-prep、ci、review、brief、verify、autopilot、babysit、evidence
調整	誰が何に取り組んでいて、誰が競合を解決するのか？	claim（＋ Claim Protocol）、guard、radar、digest、passport

• 判断。 check は課題、そのコメント、リンクや言及のある PR（タイムライン、検索、コメント内の参照）、リポジトリのルールを読み取り、GO、RISKY、TAKEN、GATED、STALE のいずれかを平易な言葉で回答します。scan はリポジトリのオープンな課題に優先順位を付け、まず解決可能性の高いものを選べるようにします。friction は、PR のマージが実際にどれほど難しいかをリポジトリごとに0〜100で評価し、各ゲートでは根拠の出典となったファイルを引用します。xray（Timeline X-Ray）は、作業を始める前に課題のタイムラインを詳しく検証して候補を確認し、報告者自身が作成した修正 PR を含む、進行中の隠れた PR を検出します。scan --deep は一覧を表示する前に、すでに対応中の課題の順位を下げます。racecheck（Keyword Race Check）は、X-Ray では見つけられない競合を検出します。つまり、課題にリンクされていないものの同じ問題を修正しているオープン PR を、リンクではなく課題の問題キーワード（ファイル名、識別子、特徴的な用語）から見つけ、RACE／SUSPECT／CLEAR の判定と、引用したキーワードの根拠を提示します。scan --deep と xray は自動的にこれを参照します。v0.20.1 の精度向上により、実際のリポジトリでも信頼性を保てるようになりました。GitHub のラベル名、URL のパス要素、リポジトリのテンプレート定型文（スキャン対象の PR キューに対する文書頻度の抑制による）は根拠として数えず、用語による RACE 判定にはタイトル由来の用語を必須とし、変更ファイルが共通する場合も特徴的な一致が必要です。そのため、単に近接しているだけなら RACE ではなく SUSPECT と判定します。wave は、Agent Policy Index を1つのコマンドでビルドキューに変換します。解決可能性の高いオープンリポジトリと X-Ray で確認済みの着手向け課題を並べ、動作上のゲートは除外します。
• 解決。 ci-prep はプッシュ前にリポジトリ独自のプルリクエストチェック（テスト、lint、型チェックのほか、changesets、コミット形式、DCO などの規約）をローカルで実行し、回避可能な CI 失敗がメンテナーの目に触れないようにします。ci はベースブランチの履歴と照合して、赤くなっている PR を既存の問題、自分の変更が原因と思われる問題、外部のブロッカーに分類します。review はすべてのレビューのスレッドを、実際の指摘と思われるもの、ノイズと思われるもの、判断が必要なものに分類し、返信案を作成します。verify は変更によるテスト結果の正直な差分を報告します。autopilot はボットの指摘をブランチ先端のコードで検証し、機械的に処理できる項目（DCO の修正、競合解消後の再マージ、フォーマット）を自動で修正します。brief はあらゆる PR について、検証済みの1画面の概要をまとめます。変更箇所とリスク、ベースブランチの履歴に照らして分類した CI、根拠付きで実際の指摘と誤検知に分類した検出事項、テストの根拠（ある場合は提示し、ない場合は明記）、マージを妨げる要因、最初に確認すべき点を一行で提示します。babysit はオープン中の PR を監視し、優先順位を付けたアクションリストを1つ報告します。
• 調整。 claim はプロトコルに基づく claim（有効期限付きリース、公開キュー、ハートビート。仕様全文は protocol/SPEC.md）を投稿します。--via-api を指定すると、ホスト型アプリのクライアントも利用できます。guard はメンテナー向けに、受信した PR を分析し、競合する修正、過去の claim、欠けている成果物、初回のコントリビューターかどうかを確認します。digest は、リポジトリ内の PR の競合、他者による claim との衝突、古くなった claim、割り当てゲートとの競合を報告します。radar はオープン PR のキュー全体をスキャンし、競合する PR や重複 PR をクラスター化します。クラスターごとに根拠と推奨する採用案を示しますが、これはヒューリスティックであり、判定ではないと明記します。passport は、コントリビューターのマージ済み作業と claim の記録を表示します。

すべての判定とレポートには、その根拠が記載されています。引用したポリシーの行、claim コメントの URL、PR 番号、失敗したチェックなどです。出典なしに断定することはありません。

対象ユーザー

• コントリビューター（人間）。issue に夜を費やす前に check を実行してください。取り組む内容を選ぶときは scan を実行してください。プッシュする前に ci-prep を実行してください。
• AI エージェントとコーディングツール。1 つのコマンド（init --agent claude-code。cursor、copilot、windsurf、cline も指定できます）で、MCP 設定と「PR を開く前に Greenlight でチェックする」という唯一の行動ルールをインストールします。エージェントは、すでに他の人が取り組んでいる issue の解決に最も多くのトークンを浪費します。33 個の MCP ツールで、実行中にエンジン全体を利用できます。
• メンテナー。新着 PR ごとに guard、未解決 issue のキュー全体に radar、週次トリアージに digest を使い、コントロールルームには以下のロードマップを活用してください。古い claim の一斉チェック、ポリシーの適用、AI による PR のフィルタリングに対応します。

実績をありのままに

• テストは 1194 件で、すべて合格しています。実際のキャンペーン事例（他の人がすでに取り組んでいる issue、弱い PR への言及、claim 優先のゲート、範囲を限定した claim、半分だけ出荷された issue、古い claim、一時停止中の PR ワークフロー）を固定したフィクスチャコーパスも含まれています。
• 実際のキャンペーンで自ら使い、実証しています。このツールキットは、数十の公開オープンソースリポジトリで 80 件以上のプルリクエストを作成してきました。すべての機能は、実際のコントリビューションがその機能なしでは頓挫した経験から生まれています。
• 対象ユーザーがすでに利用しているあらゆる場所で配布しています。npm（@reneturcios/greenlight）、MCP Registry、GHCR（ghcr.io/cloudcorprecords/greenlight）に加え、Docker と MCP stdio から直接利用できます。
• 継続的に更新される 2 つのデータセットが付属します。Contribution Friction Index（data/friction-index.json）と Agent Policy Index（505 個のリポジトリ、ゲート適用対象 127 件、エージェント禁止 19 件、docs/policy.html で公開）です。どちらも推測をスクレイピングしたものではなく、実際のキャンペーン現場での作業に基づいています。

動作を見る

59 秒のデモです。実際のリポジトリでの issue チェック、AI が発見した隠れた claim、GATED となるエージェント禁止、キャンペーンの調査、claim の見守り機能を紹介します。ナレーション付き動画。

インストール

npx @reneturcios/greenlight check <issue-url>

AI コーディングツールをセットアップし、設定を確認します。

npx @reneturcios/greenlight init --agent claude-code   # one-command MCP setup (cursor, copilot, windsurf, cline work too)
npx @reneturcios/greenlight doctor                     # checks Node version, token, GitHub quota, cache

ソースから実行する場合：

npm install
npm run build

GITHUB_TOKEN（公開リポジトリではスコープ不要のクラシック個人アクセストークン）を設定すると、GitHub API のレート制限が 1 時間あたり 60 リクエストから 5000 リクエストに引き上げられます。Greenlight は API レスポンスを ~/.cache/greenlight にキャッシュします。

npx @reneturcios/greenlight mcp（stdio）で MCP サーバーを実行するか、引数 mcp だけを指定して、エージェントに greenlight コマンドを実行させてください。

Docker で実行する

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

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

docker run -i ghcr.io/cloudcorprecords/greenlight

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

docker run ghcr.io/cloudcorprecords/greenlight check <issue-url>
docker run ghcr.io/cloudcorprecords/greenlight --version

AI コーディングツール内で使う

1 つのコマンドでセットアップできます。

npx @reneturcios/greenlight init --agent claude-code

（cursor、copilot、windsurf、cline も指定できます。複数のエージェントを指定する場合は --agent を繰り返してください）。Init は MCP 設定をプロジェクトにコピーし、「PR を開く前に Greenlight でチェックする」という唯一の行動ルールをエージェントに教えるワークフロー指示のスニペットをインストールします。手動で設定したい場合は、integrations/ のドロップインパックに、すぐにコピーして使える MCP 設定と同じスニペットが用意されています。その後、「MCP ツールの一覧を表示して」というプロンプトで確認してください。greenlight サーバーには 33 個のツールがあります（以下の一覧を参照）。

CLI

# One-command setup for your AI coding tool (cursor, copilot, windsurf, cline work too)
npx @reneturcios/greenlight init --agent claude-code

# Verify the setup: Node version, token, GitHub quota, cache (exit 1 when anything fails)
npx @reneturcios/greenlight doctor

# Help: overview, one command's flags, or the version
npx @reneturcios/greenlight help check
npx @reneturcios/greenlight --version

# Verdict for one issue
npx @reneturcios/greenlight check https://github.com/batrapulkit/squidbrake/issues/74

# [GO] batrapulkit/squidbrake#74
#   Taint: tell the approver when an agent edits its own setup right after reading outside content
#   - open, unassigned, no linked PRs, no claim signals, no blocking gates

# Rank a repo's starter issues, GO first (falls back to recent open
# unassigned issues when the repo does not use those labels; --no-fallback to opt out)
npx @reneturcios/greenlight scan PrefectHQ/fastmcp

# Deep-verify candidates against their timelines first (catches hidden in-flight PRs)
npx @reneturcios/greenlight xray usebruno/bruno --issues 8149,9319
npx @reneturcios/greenlight scan usebruno/bruno --deep

# Keyword race check: is an open PR already fixing this issue without
# ever linking it? (link-based checks cannot see it; exit 1 on RACE)
npx @reneturcios/greenlight racecheck sveltejs/kit 17465

# Scans stop on a wall-time budget (default 600s; override with --max-time <seconds>).
# A scan that hits the budget returns the results gathered so far, labeled partial:
# --json gains partial: true, partial_reason ("scan time budget 600s reached; evaluated
# K of M candidates"), evaluated, and candidates; the human output prints the results
# plus a "Partial scan:" line naming the budget. Partial scans still exit 0.
npx @reneturcios/greenlight scan PrefectHQ/prefect --max-time 300

# Friction score for a repo
npx @reneturcios/greenlight friction triggerdotdev/trigger.dev

# CI triage for a red PR: is each failing check yours or pre-existing?
npx @reneturcios/greenlight ci https://github.com/reticlehq/reticle/pull/1620

# [pre-existing] install-gate (windows-latest)
#   same check failing on base: 2 of 3 recent base runs, last at 2026-10-14T10:00:00Z

# [external-blocker] Vercel - Authorization required
#   check name matches the Vercel deploy/auth pattern; this failure is infrastructure, not the PR

# JSON output for scripting
npx @reneturcios/greenlight ci <pr-url> --json

# CI pre-flight: run a repo's own PR checks locally before pushing (exit 1 on NO-GO)
npx @reneturcios/greenlight ci-prep ~/work/bruno

# [PASS] tests (workflow ci, job build)
# [SKIPPED] publish (workflow release, job release) - publishes a package
# [PASS] convention: DCO sign-off
# Verdict: GO

# Review triage for a PR with review feedback: which comments need you?
npx @reneturcios/greenlight review https://github.com/n8n-io/n8n/pull/41235

# Verified review brief for any PR: change shape by area and risk, CI
# triaged against base-branch history, findings classified with evidence,
# test evidence present or explicitly marked absent, merge blockers, and
# a one-line look-at-this-first
npx @reneturcios/greenlight brief https://github.com/usebruno/bruno/pull/9569

# Brief: 4 files (+335/-11), 2 source + 2 tests
# CI: code checks green; external blockers named (fork workflows require maintainer approval)
# review: NO FINDINGS
# blockers: none
# lookFirst: No blockers or real findings. Start here: 2 source files carry the change.

# Campaign scout: rank repo targets, dedupe against the campaign file, append as SCOUTED
npx @reneturcios/greenlight scout --repos acme/widgets,acme/gadgets --campaign campaign.json --write

# Babysit your registered claims: linked, linked-dead, healthy-active, heartbeat-due, expiring, unlinked-stale, queue-lost
npx @reneturcios/greenlight babysit --claims-only
# A claim whose linked PR closed unmerged reads linked-dead, with a release
# prompt: the issue is free, but the stale marker needs an explicit release.

# Pacing: claim posts never trip GitHub's anti-spam flag
# Every post attempt is ledgered at ~/.greenlight/posting-ledger.json
# (timestamp, kind, target, outcome). Claim posts enforce a minimum
# interval (default 90s, jittered; GREENLIGHT_CLAIM_MIN_INTERVAL_S, or
# --min-interval) and a daily soft cap (default 25 per rolling day;
# GREENLIGHT_CLAIM_DAILY_CAP, 0 disables). A post that fails with a block
# or an uncertain network error is marked UNCONFIRMED; the tool re-reads
# the target against the API before ever posting to it again, so a
# "failed" post that actually landed is marked confirmed and never
# reposted. --force overrides any pacing refusal, and the override is
# ledgered. greenlight status shows your pacing posture.
npx @reneturcios/greenlight status https://github.com/owner/repo/issues/123

# Maintainer guard for an incoming PR: competing fix, prior claims, missing
# artifacts (changeset / DCO / CLA), first-time contributor. Renders markdown
# ready to post as one comment; Greenlight itself never posts.
npx @reneturcios/greenlight guard https://github.com/owner/repo/pull/123

# Greenlight guard: 1 thing to check
#   - Missing release-note file (repo uses .changes/): expected .changes/123-slug.md
npx @reneturcios/greenlight guard <pr-url> --quiet   # exit 3 when flagged, silent otherwise

# Duplicate/competing PR radar for the whole queue: clusters PRs fixing the
# same issue or touching the same files, with evidence and a suggested keep
# per cluster (always labeled a heuristic, never a verdict)
npx @reneturcios/greenlight radar usebruno/bruno --limit 100

# 100 open PRs scanned in 6 API calls: 3 competing clusters, 94 unclustered
# cluster (same issue #5011): #5016 "Fix: Param table UI breaks bug" ~ #5074 "fix: Param Table UI Breaks on resize" - suggested keep #5016 (heuristic)
# cluster (file overlap, 100% Jaccard in packages/): #3484 ~ #5747 - suggested keep #3484 (heuristic)

# Verified comment for a maintainer-only repo: the issue takes no outside
# PRs (inspector, servers), so the contribution is a detailed, verified
# comment. Assembles from your notes or a markdown file; sections you
# leave empty render as explicit gaps, never filler. Never posts.
npx @reneturcios/greenlight verify-comment https://github.com/modelcontextprotocol/inspector/issues/2723 \
  --claim "TUI tests append to the developer's real ~/.mcp-inspector/auth.log" \
  --env "modelcontextprotocol/inspector @ 3a4b5c6, 2026-10-15" \
  --repro $'point HOME at a scratch dir\nrun: vitest run __tests__/App.test.tsx' \
  --observed "155 lines appear in the scratch HOME's auth.log" \
  --expected "test runs leave the developer's home directory untouched" \
  --root-cause "clients/tui/__tests__/setup.ts does not isolate the log dir" \
  --fix "per-test-file temp dir via fs.mkdtempSync, set MCP_INSPECTOR_LOG_DIR, remove on exit" \
  --ran "vitest run __tests__/App.test.tsx: 130 passed" \
  --by "@CloudCorpRecords"
# or: greenlight verify-comment <issue-url> --from-file notes.md

# Honest red-green test delta, in your repo checkout: runs the detected
# test command on a base worktree and your working tree, and reports what
# your change actually did: newly passing (fixed), newly failing (yours),
# still failing (pre-existing, not yours). Says "unverifiable" with the
# reason instead of guessing when it cannot run or parse.
cd your-repo && npx @reneturcios/greenlight verify --base origin/main
# exit 3 when new failures exist, 1 when unverifiable

# PR babysitter: one prioritized action list across your open PRs --
# needs you now, waiting on them, quiet. Reruns report what changed.
npx @reneturcios/greenlight babysit --mine --repos acme/widgets,acme/gadgets
# or: greenlight babysit --prs <url1>,<url2> --fail-on-action   (exit 3 when action is needed)

# Verified PR evidence pack: guard + CI triage + review triage + protocol
# status of linked issues, in one markdown document where every claim
# cites its source. The test delta comes from a verify report you pass in.
npx @reneturcios/greenlight evidence https://github.com/acme/widgets/pull/42 --out EVIDENCE.md
# or: greenlight evidence <pr-url> --verify-json verify.json

# Contributor passport: protocol claims from the public Claim Ledger plus
# merged PRs from GitHub. No Ledger file yet? It says so plainly.
npx @reneturcios/greenlight passport CloudCorpRecords

# The proxy, for authenticated reads (60/hr anonymous -> 5000/hr token):
# reads GITHUB_TOKEN once at startup, attaches it server-side, binds
# 127.0.0.1 only, and refuses to start without a token.
export GITHUB_TOKEN=<your-classic-token> && greenlight proxy &
export GREENLIGHT_GITHUB_BASE_URL=http://127.0.0.1:8792 GITHUB_TOKEN=proxy

# Verify every link of a release chain (tag, commit, release, npm, registry)
npx @reneturcios/greenlight shipcheck <owner/repo> --version x.y.z

審査で確認した実例：

• batrapulkit/squidbrake#74 は GO と判定されます。コメントは 0 件で、help wanted ラベルが付き、claim もゲートもありません。
• shadcn-labs/pdfcn#58 は RISKY と判定されます（claimed フラグ）。審査したその日に、ボランティアが割り当てを依頼しました。
• langchain-ai/langchain#41185 は TAKEN と判定されます（claim の競合）。まだ「未割り当て」の状態で、強い claim が 3 件ありました。
• PrefectHQ/fastmcp#5718 は GATED と判定されます。FastMCP では、PR を作成する前に割り当てを受けるか、「prs welcome」ラベルが必要です。
• triggerdotdev/trigger.dev#5016 は GATED と判定されます。推薦を受けていない作者の PR は自動でクローズされ、まず推薦の依頼が必要です。

MCP サーバー

同じエンジンは、コーディングエージェント（Claude、Cursor、Cline）向けに stdio 経由でも公開されています。強みは、エージェントがすでに対応済みの課題の修正に最も多くのトークンを浪費することです。コードを書く前に、エージェントに課題の事前確認をさせましょう。

{
  "mcpServers": {
    "greenlight": {
      "command": "npx",
      "args": ["-y", "@reneturcios/greenlight", "mcp"],
      "env": { "GITHUB_TOKEN": "your-token" }
    }
  }
}

ツール（33）：

• check_issue - 1 件のイシュー URL の判定
• scan_repo - リポジトリのオープン中のイシューを優先順位付けし、GO を先頭に表示します（ラベル付きのスターターイシューを優先し、該当がない場合は最近の未割り当てイシューを対象にします。deep: true の場合は、候補を先にタイムライン X 線分析します）
• xray_issues - タイムライン X 線分析：候補イシューのタイムラインを詳細に検証します（進行中の隠れた PR、報告者自身が所有する修正 PR、コメントでの主張を確認します）。各イシューについて、PR の証拠とともに GO／RISKY／TAKEN を示します
• racecheck_issue - 1 件のイシューを対象とするキーワード競合チェック：同じ問題を修正するオープン中の PR のうち、そのイシューへのリンクが一度もないものを探します（sveltejs/kit #17465 と PR #17453 の事例）。PR ごとに一致したキーワードを引用し、RACE／SUSPECT／CLEAR を示します
• repo_friction - リポジトリの摩擦スコア
• wave_queue - 1 回の呼び出しでキューを作成します：Agent Policy Index から勝算のあるオープン中のリポジトリを絞り込み、スターターイシューを X 線分析（CLEAR／RISKY／TAKEN）し、行動上のゲートを除外し、自分がすでにオープン中の PR を持つリポジトリをスキップします
• verify - チェックアウト済みリポジトリの、ベースとヘッドを比較した正確なテスト差分（失敗優先で確認し、生の件数は使用しません）
• shipcheck - リリース準備状況：GitHub リリース、npm バージョン、レジストリレコード、GHCR タグを確認し、対象ごとに GO／NO-GO を示します
• passport - GitHub ログイン名に対するコントリビューターパスポート：台帳プロフィール、マージ済み PR 数、誠実性比率
• bounty_check - 1 件のイシューに対する報奨金の有効性分類：有効なプラットフォーム、検証不能な主張、または終了したプラットフォーム
• claim_issue - 判定を条件とするクレームコメント（execute: true でない限りドライラン）
• prep_issue - フォークとブランチを確認し、リポジトリで学習した規約を含むローカルの PREP.md チェックリストを作成します（execute: true でない限りドライラン）
• open_pr - フォークブランチから DCO に対応した PR を作成します（execute: true でない限りドライラン）
• ci_prep - プッシュ前にリポジトリ独自の PR チェックをローカルで実行します（NO-GO の場合は exit 1）
• ci_triage - ベースブランチの最近のチェック履歴と比較し、PR の失敗した各チェックを、既存の問題、自分に起因する可能性が高いもの、判定不能（根拠となる見立て付き）、外部要因によるブロッカーに分類します
• review_triage - 自分の PR に対するレビュー指摘をトリアージします。各指摘を、実際の問題である可能性が高い／ノイズである可能性が高い／判断が必要に分類し、その理由と返信案を示します（人間をノイズと判断することはありません。返信案の作成のみで、投稿はしません）
• pr_brief - あらゆる PR の検証済みレビュー概要：ファイルを領域／リスク別に分類し、ベースブランチの履歴に照らして CI をトリアージし、指摘を証拠付きで実際の問題と誤検出に分類し、テストの証拠がある場合は提示し、ない場合は明示します。マージを妨げる要因と、最初に確認すべき点を一文で示します（指摘を捏造しません）
• guard_pr - メンテナー側からの受信 PR 分析：競合する修正、投稿者以外による先行クレーム、不足している成果物（changeset／DCO／CLA）、初回コントリビューターを確認します。コメントにそのまま使える Markdown を返します（投稿はしません）
• repo_digest - リポジトリ単位のメンテナーレポート：先行クレームの優先調停を伴う PR 競合、他者によるクレームとの競合、期限切れのクレーム、割り当てゲートの競合、トリアージ保留中のイシューを報告します（投稿はしません）
• pr_radar - メンテナー側の重複／競合 PR レーダー：リポジトリのオープン中の PR を競合するグループにまとめます（同じ対象イシュー、または変更ファイルの高い重複）。グループごとに証拠と推奨する維持対象を示します（常にヒューリスティックと明記し、判定とはしません。投稿はしません）
• claim_status - 1 件のイシューに対する Claim Protocol の事前確認：担当者、担当期限、待機中の人、競合する PR、ゲート、リポジトリがプロトコルを遵守しているかを確認します
• preflight - 1 回の呼び出しで得られる回答：claim_status とリポジトリの摩擦概要
• verify_comment - メンテナー専用リポジトリ向けに、検証済み指摘のコメント案を作成します（下書きのみで、投稿はしません）
• babysit_prs - オープン中の PR を監視し、優先順位付きの対応リスト（今すぐ対応が必要、相手の対応待ち、静観）を取得します。保存済みの基準値との差分を確認し、my-claims レジストリ（リンク済み、正常にアクティブ、ハートビート期限到来、期限切れ間近、未リンクで古い、キューから脱落）も監視します
• evidence_pack - 1 件の PR に対する Verified PR 証拠パック：guard の判定、CI トリアージ、レビューのトリアージ、リンクされたイシューのプロトコル状況、各クレームとその情報源
• scout_campaign - キャンペーンモード：リポジトリ候補を優先順位付けし、キャンペーンファイルと照合して重複を除外し、API の予算切れ後に再開します
• my_claims - クレームレジストリ：リンク済み、正常にアクティブ、ハートビート期限到来、期限切れ間近、未リンクで古い、キューから脱落
• sync_campaign - ローカルの追跡情報を API の実際の状態と照合します（差分、状態の不一致、古いクレーム）
• campaign_portfolio - 1 画面で確認できるキャンペーン概要：集計数、状態別のクレーム、保留中のキュー、差分件数
• autopilot_report - PR ごとのフィードバック分類（読み取り専用。ボットの指摘を検証し、CI をトリアージし、機械的な修正を計画として提示します）
• api_status - ホスト型クレーム API の状態
• claim_via_api - ホスト型クレーム API 経由でクレームします
• heartbeat_via_api - ホスト型クレーム API 経由でハートビートを送信します ローカルで実行するには、npm run dev を実行します（MCP エントリは src/index.ts、CLI は src/cli.ts です）。

スコアリングの仕組み

判定エンジンは決定論的（LLM を使用しません）で、次の順に確認します。

1. クローズ済みのイシュー：TAKEN（着手可能にはなりません）。
2. 担当者が設定されている：TAKEN。
3. イシューをクローズするオープンな関連 PR がある：TAKEN。イシュー番号に言及しているだけの PR（pdfcn の PR #91 は #70 をクローズしていますが、本文に関連イシューも記載しています）は weak-pr-mention フラグを追加するだけで、その他の条件で GO となる判定を RISKY に引き下げます。完了としてクローズされたイシューの重複としてマークされている場合は、duplicate-of-closed フラグ付きの RISKY です（作業はすでにリリース済みです。重複先がまだオープンの場合は、その URL とともに duplicate-of-open の警告が追加されるだけです）。
4. 有力な担当希望者が 2 人以上いる：TAKEN（担当希望の競合）。
5. 45 日以内に投稿された、イシュー全体を対象とする有力な担当希望が 1 件ある：claimed フラグ付きの RISKY。イシューの一部を対象とした新しい担当希望（「残りのフォールバック部分を担当します」など）の場合は、claimed と partial-claim のフラグが付いた RISKY となり、担当希望者と対象範囲を理由に明記します。TAKEN にはなりません。
6. 終了 PR がなく、45 日より前に投稿された有力な担当希望が 1 件ある：stale_claim フラグ付きの RISKY です。担当希望者は離れてしまった可能性がありますが、確かなことはわかりません。古い部分的な担当希望も同様に扱います。終了 PR がなく、180 日より前の担当希望は代わりに 減衰 したものとして扱います。stale-signal フラグと、重みを下げる理由を添えて表示しますが、それだけでブロックすることはありません（非常に古い担当希望 2 件はもはや担当希望の競合にならず、1 件だけなら他に問題のないイシューを RISKY に引き下げません）。
7. 担当者がいない状態でのハードゲート（割り当て、推奨、コラボレーター限定、依頼されていない PR の受付停止、ワークフローによって自動クローズされる外部 PR）：GATED。最後の 2 つは CONTRIBUTING の記述（「依頼されていないプルリクエストの受付停止」）と、.github/workflows 内で外部 PR をクローズする自動化をスキャンした結果に基づきます。
8. 180 日以上、アクティビティがない：STALE。
9. ソフトな「着手前に申告」ゲート（pdfcn のように、作業を始める前にコメントするようリポジトリが求めている場合）：GATED にはなりません。その他の条件で GO となる判定を RISKY に引き下げ、弱い PR への言及と同じ形式の注記を付けます。
10. それ以外：GO。
11. タイトルまたは本文にイシュー番号が記載されているオープン PR が、作成者以外のコメントで参照されている場合：その他の条件で GO となる判定を、comment-mentioned-pr フラグ付きの RISKY に引き下げます（「このイシューの一部をすでにカバーしている可能性があります」）。これによって TAKEN になることはありません。TAKEN になるのは、イシューをクローズする PR がある場合だけです。修正の告知コメント（/attempt #N コマンドや「 で修正を提出しました」といった説明。別リポジトリの PR へのリンクが含まれることもよくあります）は、イシュー番号が PR に記載されていない場合でも、PR の URL を引用した独自の理由と attempt-linked-pr フラグを付け、同じように判定を引き下げます。/attempt コメントは有力な担当希望としても登録されます。
12. 一部対応済み：イシュー番号を参照するマージ済み PR（コメント内での言及または関連付け）や、作業の一部がすでにリリースされたことを示すメンテナーのコメント（「#905 で半分を対応済み。残りの半分 B のためにオープンのままにしています」「イシューへの参照の近くに「v3.1.0 でリリース済み」など）です。単なる GO 判定では必要なスコープの絞り込みが見過ごされるため、partially-addressed フラグが追加されます。その他の条件で GO となる判定は RISKY に引き下げられ、「このイシューの一部はすでにリリース済みです（PR #905、マージ済み）。残りの範囲に絞って作業してください」のような理由が付けられます。TAKEN にはなりません。 摩擦スコアは100から始まり、ゲートの重みを差し引きます（割り当て -25、推薦 -35、コラボレーターのみ -50、予告なしのPRを一時停止 -40、範囲を限定した一時停止 -20、外部からのPRを自動クローズ -50、議論を先行 -10、申請を先行 -5、CLA/DCOは各-5、検出された行動上のゲート -20）。算出可能な場合は、外部からのPRのマージ率とレビュー／応答時間を加味し、対応可能なgood-first-issuesには最大+10を加算します。不明なシグナルはnullのままにしてスキップし、決して推測しません。従来のスターターラベルが正確に0件の場合、摩擦レポートでは表示専用の候補推定値（より広いスターターラベルセット（例：「beginner friendly」、「easy」、「first-timers-only」）に該当する、未割り当てのオープンな課題）をラベル数の横に表示します。この推定値はスコアに反映されず、ラベル数にも加算されません。正確な計算式については、src/friction.tsを参照してください。

行動上のゲートはポリシーファイルではなく、メンテナーの行動から読み取るものです。frictionは、過去12か月以内にクローズされた未マージPRのうち、クローズ日時が新しいものから15件を取得するまで、クローズ済みPRの一覧をたどります（それより古いPRは除外され、最新のクローズ済みPR自体が期間より古い場合は「シグナルが古い」という注記が付きます）。その後、AIへの拒否を示す証拠（AIへの言及と拒否表現、「AI slop」などの明示的なフレーズ、または「AI policy」の適用）を確認するため、メンテナー側のコメントを読み取ります。ただし、「AI-assisted PRs are welcome」のような歓迎を示す表現があれば、シグナルは抑制されます。独立した2件のPRで、リポジトリに行動上のゲートがあると判断されます。1件のみの場合、弱いシグナルは警告として記録されますが、明示的な拒否表現が1件でもあれば検出されます。friction --jsonでは、トップレベルのbehavioral_gateフィールド（detected、strength、threshold、PR番号、引用、URLを含むevidence、notes）に記録されます。このフィールドが正規の格納先であり、signals.behavioralGateはインデックスパイプラインとの互換性のため、同一の値を持つミラーとして維持されます。rebaselineなどのインデックスパイプラインは、記述されたポリシーには明記されていないものの、実際の運用が敵対的なリポジトリを再分類するために、正規フィールドを読み取ります。API呼び出しは最大48回に制限されます。内訳は、クローズ済み未マージPRを15件収集するための一覧呼び出しが最大3回、各PRの証拠ページ（Issueコメント、レビュー、レビューコメント）が最大3ページです。--no-behavioralを指定すると、この処理をスキップできます。

friction --liteは、ポリシーゲートのみを対象とする標準の軽量摩擦計算です。ポリシーソース（CONTRIBUTINGの各種ファイル、AGENTS.md、CLAUDE.md、ルート、.github/、docs/内のAI_POLICY.md、および組織レベルのAI_POLICY.md）を取得し、そこからゲートを解析します。また、detectRepoPolicyによるコラボレーターのみの判定を適用します（現時点ではAPI呼び出しなし）。そのうえで、文書化された正確な計算式を使ってスコアを算出します。100から始め、同じGATE_WEIGHTSを使ってゲートの重みを加算し、[0, 100]の範囲に収めます。行動上のゲートの確認、マージ速度（およびそれに伴う外部PRのマージ率の項目）、初回レビューと課題への応答時間、good-first-issueボーナスはスキップされます。すべての結果シグナルはnullのままにしてスキップし、決して推測しません。signals.noteは"lite"となり、レポートにはlite: trueが含まれます。gatesフィールドとscoreフィールドは通常の摩擦計算と同じ形式なので、Agent Policy Indexスキャナーは独自の実装を維持する代わりに、--liteを摩擦の軽量計算の単一の実装として採用できます。

軽量版と通常版のすべての摩擦レポートには、policy_provenanceも含まれます。調査したポリシーソースごとに、読み取れたか、存在しなかったか、取得に失敗したかが記録されます。これにより、「ポリシーファイルがない」状態が「ポリシーの取得に失敗した」状態と二度と混同されません（以前はどちらも同じように表示されていました）。人間向けの出力では、たとえばpolicy sources: 2 read (CONTRIBUTING.md, AGENTS.md), 3 absent, 0 fetch errorsのような要約行で表示されます。 wave は 1 つのコマンドで Agent Policy Index をビルドキューに変換します。外部コントリビューターによるマージ率、スター数の範囲、スターター向けの issue がある純粋なオープンソースのリポジトリを、既存の xray エンジンで X 線解析します（CLEAR／RISKY／TAKEN。競合する PR があれば名前を表示）。動作上のゲートが検出されたリポジトリは除外し、すでに自分のオープン PR があるリポジトリはスキップします。また、コア API の予算が下限（デフォルトでは 800）を下回るか、検索のスロットリングが発生すると、部分結果を明示して実行を停止します。人間向け出力と --json に対応し、各段階で使用した API 呼び出し数を報告します。候補はデフォルトで取り組みやすさ順に並びます（外部コントリビューターによるマージ率、次に摩擦、次にスター数）。--sort stars を指定すると以前の順序に戻ります。

スコープを限定した受付一時停止（「新しい書式設定オプションを追加するプルリクエストは受け付けていません」）は、独立したゲート種別（scoped_prs_paused）です。一律の受付停止の半分の摩擦として扱われ、判定をゲートすることはありません。check と scan はこれを警告し、拒否されたスコープを引用して判定を RISKY に制限します。

Autopilot は継続的なブランチ健全性ボードを維持します。PR ごとのマージ可能状態、mergeable_state、ベース SHA、遅れたコミット数は実行間で状態に保存され、レポート出力に表示されます。また、MCP ツール autopilot_report（branch_health、branch_board）にも含まれます。

さらに 4 つの CLI コマンドが、エージェントから呼び出せる MCP ツールとして利用できます。verify（ベースとヘッド間のテスト差分を正確に確認）、shipcheck（リリース、npm、レジストリ、GHCR の準備状況）、passport（申告台帳に基づくコントリビュータープロフィール）、bounty（1 つの issue のバウンティ有効性確認）です。

エージェントポリシーのゲートとトリアージ保留

ポリシーファイルは、リポジトリで実際に使われている場所から読み込みます。リポジトリルート、.github/、docs/ にある AGENTS.md、CLAUDE.md、CONTRIBUTING.md、AI_POLICY.md（ファイル名ごとに最初に見つかったものを採用）、および組織レベルの .github/AI_POLICY.md が対象です。2 種類のゲートがエージェントのルールを解析します。

• agents_banned はハードゲートです。自律型エージェントによるコントリビューションを禁止するリポジトリは、根拠となるポリシー行を引用して GATED と判定されます。また、--force を指定しない限り、claim は TAKEN と同様に拒否します。
• agents_disclosure はフラグであり、判定を変更しません。AI プレフィックスや開示を必須とするリポジトリでは、prep と check が具体的な必須対応を提示します。

ボットによるトリアージ通知（「プルリクエストを開く前に、メンテナーがトリアージラベルまたは承認ラベルを外すまでお待ちください」）またはトリアージラベルがある issue は保留中として扱われます。check は保留の内容を示し、それ以外は GO となる判定を triage-hold フラグ付きの RISKY に制限します（TAKEN にはしません）。scan は保留中の issue を、保留のない issue より下位にします。保留中の issue は将来のパイプライン候補であり、現在取り組む作業ではありません。

オプションの AI による申告検出

パターン層では、人が「これを担当します」と伝えるあらゆる表現を把握できるわけではありません（ある夜、実際の issue にあった「ここで修正へのコントリビュートを検討しています」を見逃しました）。FIREWORKS_API_KEY を設定すると、check に任意の二重チェック機能が加わります。低コストの Fireworks モデルが対象コメント（パターンと同じく、ボットと issue の投稿者は除外）を読み、パターンが見逃した意思表示を検出します。

ガバナンスは明確です。

• デフォルトでは無効です。 キーがなければ呼び出しは行われず、パターンのみのエンジンとバイト単位で同一の出力になります。
• パターンを優先し、コストも抑えます。 強い申告が見つからなかった場合に限り、AI を実行します。
• フラグのみで、判定は行いません。 AI がフラグを立てると、根拠として正確な引用を添えた llm-claim フラグが追加され、それ以外は GO となる判定が RISKY に引き下げられます。TAKEN を出すことはなく、GATED を上書きすることもありません。判定は引き続き決定論的です。
• 根拠を捏造しません。 引用はコメント本文に含まれる文字列と完全に一致する必要があります。それ以外は、判定に渡る前に破棄されます。
• 失敗は通知されません。 タイムアウト、200 以外のレスポンス、解析できない応答は、エラーとして check の処理経路に渡されず、シグナルなしとして扱われます。分類結果はコメント ID とモデル ID をキーにキャッシュされるため、再チェックでは費用がかかりません。

greenlight doctor を実行すると、このレイヤーが設定済みかどうかを確認できます（キーが表示されることはありません）。

自動化

Greenlight は、作成者が実際の 4 件の PR（shadcn-labs/pdfcn #92-#95）で手作業で行ったコントリビューションの一連の流れを自動化します。 判定、クレームコメント、フォークブランチの作成、PR の作成まで、全工程で DCO を考慮します。

# 1. Claim the issue: verdict first, comment shaped by the repo's gates
greenlight claim https://github.com/shadcn-labs/pdfcn/issues/65

# 2. Prepare: fork/branch check (learning the repo's branch convention) plus a PREP.md checklist
greenlight prep https://github.com/shadcn-labs/pdfcn/issues/65 --dir /tmp/prep65

# 3. Open the PR from your fork branch (verifies DCO sign-off on DCO repos)
greenlight pr https://github.com/shadcn-labs/pdfcn/issues/65 --branch feat/quarterly-report-block

安全性を重視したデフォルト設定です。これは機能の一部です。

• デフォルトではドライランです。 3 つのコマンドは、投稿または作成する内容をそのまま表示して終了します。--yes（CLI）または execute: true（MCP）を指定しない限り、何も投稿・作成されません。
• 書き込みにはトークンが必要です。 読み取り操作はトークンなしで実行できます。書き込み操作には GITHUB_TOKEN（または GH_TOKEN）が必要です。指定されていない場合は、環境変数名を明記したわかりやすいエラーを表示し、ゼロ以外の終了コードで終了します。
• 判定結果に基づいて動作します。 claim は --force を指定しない限り、TAKEN または STALE の判定結果を拒否し、さらに vouch が必須のリポジトリでは必ず拒否します（vouch は自動化できません）。割り当てが必須のリポジトリでは、意図を示すコメントの代わりに割り当てリクエストを送ります。作業開始前にクレームするリポジトリでは、標準の意図を示すコメントを投稿し、必要な手順を満たします。
• リポジトリに応じたブランチ名を使用します。 prep は最近クローズされた PR のヘッドブランチを読み取り、主流の命名規則（pdfcn の feat/<slug>-block）に従いつつ、デフォルトの feat/<slug>-<number> も表示します。
• DCO を考慮します。 DCO が適用されるリポジトリでは、pr はブランチ上のすべてのコミットに Signed-off-by: 行が含まれていることを検証します。欠けている場合は、該当するコミットを列挙して処理を拒否します。
• リポジトリに応じた prep を行います。 prep は PREP.md のチェックリストを作成するため、リポジトリのコントリビューション手順も読み取ります。具体的には、どのリポジトリ固有のルールファイルがあるか、どの検証コマンドが指定されているか（pnpm verify など）、変更履歴を .changes/ ディレクトリから組み立てるか、ルートの package.json にどのスクリプトがあるか、最近のコミットが Conventional Commits に従っているかを確認します。必須のルールは CONTRIBUTING ではなく AGENTS.md に記載されることが増えているため、prep はそれらも読み取ります。

ツールキット

Greenlight は、オープンソースへのコントリビューション作業を支援する 4 つのツールからなるライフサイクルの入口です。すべて同じ npm スコープで公開され、連携しています。

1. gatefile（npx @reneturcios/gatefile extract owner/repo）は、リポジトリのコントリビューションに関する必須条件を抽出し、コミット可能な contribution-gates.json を作成します。Greenlight はこのファイルを直接利用できます。greenlight check <issue-url> --gates-file contribution-gates.json のように指定するか、ファイルが作業ディレクトリにあれば自動的に読み込みます。これにより、必須条件への回答は一度で済み、説明文から再度導き出すことなく再利用できます。
2. greenlight は判定、スキャン、クレーム、prep、PR の作成を行います（このツール）。
3. claimcheck（npx @reneturcios/claimcheck claims owner/repo）は、クレーム済みの Issue を監視し、クレームが古くなっていないか、フォーク上に完了済みの修正が放置されていないかを確認します。どちらも、クレームされた作業が気づかれないまま立ち消えになる原因です。
4. prwatch（npx @reneturcios/prwatch attention --user you）は、今すぐ対応が必要な内容に基づいて、あなたのオープン中の PR をトリアージします。対象は、レビューのスレッド、失敗したチェック、競合、レビュー担当者からの応答がない状態です。

各ツールは CLI と MCP サーバー（<tool> mcp）として利用できます。

摩擦指数

data/friction-index.json は、スコア付きリポジトリの拡充されていくデータセットで、リポジトリにチェックインされています。2026-10-13 に手作業で確認した MCP／AI エコシステム（FastMCP、trigger.dev、langchain、deepagents、openclaw、squidbrake、reticle、pdfcn、chatflow-agent、3 つの MCP SDK リポジトリ）から始まります。npm run index で再生成できます。

hand-verified 2026-10-13 とラベル付けされたエントリーは、リポジトリの実際のポリシーと Issue トラッカーを手作業で確認したものです。live とラベル付けされたエントリーは、公開中のリポジトリ固有ルールファイル（CONTRIBUTING の各種形式、AGENTS.md、CLAUDE.md）を解析したものです。各必須条件には、その根拠となる情報を取得したファイルが記録されています。計算に基づく結果フィールド（マージ率、レビュー時間）は、誠実に算出できるようになるまで null のままにし、決して捏造しません。

公開ページ（cloudcorprecords.github.io/greenlight）には、Agent Policy Index が追加されています。コントリビューションの必須条件と AI ポリシーを 505 件のリポジトリについて評価し、各エントリーに根拠となる引用を掲載しています。このマップを公開しているのは、ほかに誰もいません。

開発

npm test    # tsx --test, includes fixture tests that reproduce our real verdicts
npm run build

リリースチェックリスト

バージョンを更新するたびに、以下すべてを変更してください。変更しないと、古い情報のままリリースされます。

• package.json のバージョン
• package-lock.json のバージョン
• server.json：トップレベルの version、npm パッケージの version、および OCI の identifier タグ。タグはパッケージのバージョンと一致している必要があります （ghcr.io/cloudcorprecords/greenlight:<version>）。タグが一致しないと、test/packaging.test.ts がビルドを失敗させます
• src/index.ts のバージョン
• examples/guard-workflow.yml の固定バージョン
• テストスイートが成功した後に npm run readme:count を実行し、README のテスト件数を実際の実行結果から再生成してください。手書きは禁止です （この手順が文書化されていないと、test/packaging.test.ts がビルドを失敗させます）

ロードマップ

以下は明確に示されているとおり、まだリリースされていません。（v0.15.0 では、ロードマップの項目が2つ製品に追加されました。radar は重複・競合する PR のクラスタリング機能で、brief はあらゆる PR に対応する検証済みレビュー概要です。）

• メンテナー向けコントロールルーム。 guard は PR ごとに動作し、radar はキューをクラスタリングします（どちらもリリース済み）。コントロールルームは、その上に構築されるリポジトリごとのホスト型画面です。古い claim の一括確認、ワンクリックの解除リクエスト、初めて貢献する人のリスクメモ、週次メンテナー向けダイジェストを提供します。エンジン部分はすでにあります。製品化に必要なのは、組み合わせとホスティングです。
• ポリシー適用パック。 リポジトリでは、変更セットの必須化、リリースノートの必須化、DCO、AI 開示など、同じルールが繰り返し作られています。メンテナーが1つのファイルで採用でき、Action が同じ引用付きエビデンスの形式で適用するポリシーパック形式（gatefile の出力から構築）。
• AI PR の大量投稿への対策。 禁止ではなくフィルターです。guard が、claim の正当性、再現手順のエビデンス、テスト差分に基づいて投稿された PR をスコアリングすることで、メンテナーは優れたエージェントの作業を歓迎しながら、スパムを除外できます。キャンペーンデータ（拒否された claim、誠実な検証、エビデンスパック）がその証拠セットです。
• サービスとしての claim 調停。 2つの claim、1つのキュー、公開された順序、メンテナーによる上書き：競合する claim をリアルタイムで調停します。これはメンテナーが自力で構築できない機能です。
• github.com 上で issue をインラインでスコアリングするブラウザー拡張機能。
• 保留中の修正の検出と自動通知：オープン issue を参照するブランチがないかフォークをスキャンし、ゲートの条件が満たされたら通知します。

リリース履歴の全容は CHANGELOG.md をご覧ください。

ライセンス

MIT。LICENSE をご覧ください。

---

Rene Turcios が開発。SF で、バイブコーディングとエージェントネイティブな開発を公開しながら進めています。Greenlight によって週末をひとつ有効に使えたなら、このリポジトリにスターを付けて、次のツールについて @CloudCorpRecords をフォローしてください。 ファミリー製品：prwatch · claimcheck · gatefile · hookcheck · injectcheck · actionpin — すべて npm の @reneturcios/ 配下、および公式 MCP Registry で公開されています。