プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。Google でログインするとレビューを書けます。プロトタイプ · 30分ごとに更新
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

Sighttrue

作者:kaitzyy-devバージョン 1.0.0i★ 1iクラウドで動く
レジストリ名io.github.kaitzyy-dev/sighttrue

インストール方法

What it does

Measured readings on open-source dependencies: health, end-of-life, model prices, incidents.

  • Connects クラウドで動く
  • Account or key No key needed
  • Category クリニック・健康

インストール

使っているAIアプリを選んで、設定をコピーしてください。

チェック 5/5 合格 · 質問内容は提供元のサーバー(sighttrue.com)を通ります · ✓ コマンド確認済み 2026年11月13日

まず:どの AI を使っていますか?

使っているアプリを選ぶと、下に手順が表示されます。

Claude につなげます · 約 2 分

キー不要、インストール不要 · claude.ai かデスクトップアプリで一度設定すれば、チャットで使えます · 無料アカウントは 1 つまで · Team/Enterprise はオーナー(Owner)が追加

  1. Claude の Connectors ページを開く

    CustomizeConnectors

    CustomizeConnectors1Add2https://…3Add4
  2. 「Add」→「Custom」→「Web」を押し、この 2 つを入力

    ここからコピーして Claude の同じ名前の欄に貼り付け、Continue を押します

    Name · 名前Sighttrue
    Remote MCP server URL · アドレスhttps://sighttrue.com/api/mcp

    Claude が検出したサインイン設定の画面で Continue を押す · Authentication は作者の説明どおり(Sign in now・Sign in when needed・No sign in)を選び Add を押します

  3. チャットで有効にする

    +ConnectorsSighttrue

  4. 試してみる

    Sighttrue を使って、私に何ができるか教えて、1 つやってみせて

    ✓ Claude が Sighttrue を使っていると言うか、回答に Sighttrue のツール名が出れば接続成功です

メニュー名は 2026年11月11日 に Anthropic のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります

ChatGPT との接続はプランしだい

フル MCP:Web 版 ChatGPT の Business・Enterprise・Edu · Pro:読み取り/取得の権限で接続、データを変えるツールは使えないことがあります · Plus:公式ドキュメントで未確認。プラグイン画面にカスタム MCP を追加する項目があれば試せます · Web のみ

  1. Web 版 ChatGPT で MCP の追加ページを開く

    Plugins+Add custom MCP server

    ChatGPTPlugins1+2https://…3Create4
  2. 名前とアドレスを入力

    名前を入れ、Connection にアドレスを貼り付け、注意事項にチェックして Create as a plugin を押します

    Name · 名前Sighttrue
    Connection · アドレスhttps://sighttrue.com/api/mcp
  3. チャットで Sighttrue を選ぶ

    新しいチャットを開き、入力前にプラグインの一覧から Sighttrue を選びます

  4. 試してみる

    Sighttrue を使って、私に何ができるか教えて、1 つやってみせて

    ✓ ChatGPT が Sighttrue を使っていると言うか、回答に Sighttrue のツール名が出れば接続成功です

メニュー名は 2026年11月11日 に OpenAI のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります

Claude Code につなげます · 約 2 分

キー不要、インストール不要

  1. ターミナルを開く

    Mac:Command+スペースで Terminal と入力 · Windows:PowerShell を開く

  2. このコマンドを貼り付けて Enter

    claude mcp add --transport http --scope user sighttrue https://sighttrue.com/api/mcp
  3. Claude Code で /mcp と入力

    Sighttrue が一覧にあり、接続済みと表示されれば OK です

  4. 試してみる

    Sighttrue を使って、私に何ができるか教えて、1 つやってみせて

    ✓ Claude Code が Sighttrue を使っていると言うか、回答に Sighttrue のツール名が出れば接続成功です

メニュー名は 2026年11月11日 に Anthropic のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります

Cursor につなげます · 約 2 分

キー不要、インストール不要

  1. このボタンで Cursor を開く

    Cursor で開く

    Cursor がインストールの確認をするので Install を押します

  2. Cursor の AI チャットを Agent モードで開く

  3. 試してみる

    Sighttrue を使って、私に何ができるか教えて、1 つやってみせて

    ✓ Cursor が Sighttrue を使っていると言うか、回答に Sighttrue のツール名が出れば接続成功です

メニュー名は 2026年11月11日 に Cursor のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります

VS Code につなげます · 約 2 分

キー不要、インストール不要

  1. このボタンで VS Code を開く

    VS Code で開く

    VS Code がインストールの確認をするので Install を押します

  2. VS Code の AI チャットを Agent モードで開く

  3. 試してみる

    Sighttrue を使って、私に何ができるか教えて、1 つやってみせて

    ✓ VS Code が Sighttrue を使っていると言うか、回答に Sighttrue のツール名が出れば接続成功です

メニュー名は 2026年11月11日 に VS Code のヘルプページで確認 · アプリのバージョンにより画面が少し違うことがあります

Windsurf、Zed、Gemini CLI など MCP を使える他のアプリは追加方法がそれぞれ違います。アプリ一覧で確認してください

MCP を使えるアプリをすべて見る →

Web 経由でつなぐアプリ用のアドレス

アドレスhttps://sighttrue.com/api/mcp

JSON 設定は下の「開発者向け」にあります

つまずいたら?Sighttrue を使っている人に聞いてみましょう💬 ディスカッション →
開発者向け:ターミナルのコマンドと JSON 設定

Web 経由

Claude Code

claude mcp add --transport http --scope user sighttrue https://sighttrue.com/api/mcp

Cursor (~/.cursor/mcp.json)

{
  "mcpServers": {
    "sighttrue": {
      "url": "https://sighttrue.com/api/mcp"
    }
  }
}

VS Code (mcp.json)

{
  "servers": {
    "sighttrue": {
      "type": "http",
      "url": "https://sighttrue.com/api/mcp"
    }
  }
}

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

ひと目でわかる

週あたりのダウンロードi
npm/PyPIにない
接続方法
クラウドで動く
トランスポート
streamable-http
最新バージョンi
1.0.0
レジストリ公開日i
2026年8月7日
コードの最終更新i
2026年11月13日
作者
kaitzyy-dev
ウェブサイト
sighttrue.com
レジストリでの状態
有効

使えるアプリ

このサーバーのつなぎ方と、各アプリの公式ドキュメントに基づきます。2026年11月10日に確認。

インターネット経由でつなげるアプリ

ClaudeChatGPTGooseLM StudioMsty StudioCherry StudioCursorVS Code + GitHub CopilotVisual StudioWindsurf (Devin Desktop)ZedKiroClineContinueJetBrains AI AssistantClaude CodeCodex CLIGemini CLIOpenCodenodecodeWarpLibreChatOpen WebUIRaycast

すべてのアプリと長所・短所 →

できること

ツールの名前と説明は、サーバーが2026年11月11日に返したそのままの内容です。書いたのは作者で、私たちではありません。プレーンテキストとして表示しています。

  • check_before_install

    Call this before adding a dependency. Returns only the facts a reviewer would be annoyed to discover afterwards: whether the publisher has withdrawn the package, whether it runs scripts on the installing machine, whether its repository is archived, how many advisories are on reco

  • check_package

    Read the current standing of one open-source package: downloads with the window they cover, OpenSSF scorecard, advisory count, licence, whether the repository is archived, and when it was last pushed to.

  • check_stack

    Read a whole dependency list at once and report what is archived, what carries advisories, what has a source-available licence, and what has not been pushed to in a year. Use when reviewing a package.json, requirements.txt, Cargo.toml, composer.json or Gemfile.

  • search_repositories

    Find watched repositories whose name contains a string, with their current readings. Use it to discover what is covered before calling the other tools.

  • compare_repositories

    Hold two watched repositories against each other across downloads, OpenSSF scorecard, advisories, forks, stars and findings on record. Compares only; it does not pick a winner.

  • find_model

    Find language models by price and context window, from a catalogue read daily across sixty providers. Use this before choosing a model: prices move without announcement and training data is out of date on the day it ships.

  • check_eol

    Check whether a runtime, database or framework release is still receiving security fixes, and what to move to. Covers about two dozen products read daily from endoflife.date.

  • check_provider

    Recorded incidents for a hosting or API provider over a window, kept after the provider’s own status page dropped them.

  • list_readings

    List every reading this server can return, what each one measures, and which require a key. Call this first if unsure which tool answers a question.

  • who_can_publish

    How many accounts hold publish rights on a package, as the registry lists them. Answers who can put code on your machine, which is a different question from who writes it. Requires a key; see https://sighttrue.com/pricing.

  • package_weight_history

    How the published artefact size has moved over time. Returns the readings taken, not a verdict. Requires a key; see https://sighttrue.com/pricing.

  • withdrawn_but_installed

    Packages whose own publisher has withdrawn them and which are still being installed heavily, with the download figure and the publisher’s notice. Requires a key; see https://sighttrue.com/pricing.

  • typosquat_check

    Whether a name is one edit away from a more widely installed package. States that both names exist; which one was meant is the caller’s call. Requires a key; see https://sighttrue.com/pricing.

  • funding_gap

    Packages that ask for funding, beside how heavily they are installed and how many people write them. Requires a key; see https://sighttrue.com/pricing.

  • time_to_fix

    Days between an advisory being published and a release appearing that postdates it, per package and as a distribution. Requires a key; see https://sighttrue.com/pricing.

  • advisory_severity

    Advisories broken down by severity rather than counted, with identifiers and dates. Requires a key; see https://sighttrue.com/pricing.

  • runtime_deadlines

    Support end dates for the runtimes a dependency set requires, including any already past. Requires a key; see https://sighttrue.com/pricing.

  • base_image_check

    For a container base image: its size, when it was last rebuilt, and whether the OS underneath it is still supported. Requires a key; see https://sighttrue.com/pricing.

  • registry_health

    Recorded outages of the package registries themselves, kept after their status pages drop them. Requires a key; see https://sighttrue.com/pricing.

  • provider_incidents

    A provider’s recorded incidents, grouped by the component that failed, over the whole archive rather than the window its status page shows. Requires a key; see https://sighttrue.com/pricing.

  • provider_transparency

    How long a provider takes to acknowledge an incident: the interval between an incident starting and its first public update. Requires a key; see https://sighttrue.com/pricing.

  • provider_terms_changed

    When a provider last changed its terms or pricing page, from a stored fingerprint of the page. Requires a key; see https://sighttrue.com/pricing.

  • model_price_history

    Every recorded price for a model, with the date each was read. Requires a key; see https://sighttrue.com/pricing.

  • model_withdrawn

    Models that were in the catalogue and no longer are, with the date last seen. Requires a key; see https://sighttrue.com/pricing.

  • help_availability

    For a technology tag: questions asked against questions answered, over time. Requires a key; see https://sighttrue.com/pricing.

  • audit_manifest

    Read a whole manifest and return every reading on record for it, ordered by how much a reviewer would want to know. One call instead of one per dependency. Requires a key; see https://sighttrue.com/pricing.

  • diff_since

    What changed for a set of packages since a given date, read from the daily archive. Requires a key; see https://sighttrue.com/pricing.

  • watch_add

    Add a package to the caller’s own private watchlist, so later readings are about their stack rather than the public one. The list is private to the key that created it. Requires a key; see https://sighttrue.com/pricing.

  • watch_changes

    Everything that has changed across the caller’s private watchlist since a given date: withdrawals, licence changes, advisories, archived repositories and runtimes going out of support. Requires a key; see https://sighttrue.com/pricing.

  • explain_finding

    Given a finding id, return what was measured, when, by whom, and the address it can be checked at. For an agent quoting a figure into a review. Requires a key; see https://sighttrue.com/pricing.

  • domain_risk

    Whether the domains a package points at — homepage, funding, documentation — still resolve to a registered owner. Requires a key; see https://sighttrue.com/pricing.

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月13日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント sighttrue で確認済みです

  • ✓ 合格

    今もメンテナンスされている

    コードの最終更新:今日

  • ✓ 合格

    ライセンスがある

    MITを使用

  • ✓ 合格

    エンドポイントが応答する

    259ミリ秒で応答(HTTP 200)

  • – 対象外

    OAuthでサインイン

    サインイン不要

  • ✓ 合格

    ツールの説明に隠れた指示がない

    31件のツールの説明を読み、AIへの隠れた指示は見つかりませんでした

話し合い

質問、コツの共有、使えないことの報告ができます。「役に立った」の多い順です。

まだ投稿はありません。最初の質問や共有をどうぞ。

ここの投稿は利用者によるもので、PopNx チームのものではありません。

Google でログインして投稿

ユーザーレビュー

まだレビューはありません

Google でログインしてレビューを書く

クリニック・健康のほかのサーバーとの比較i

  • このカテゴリのほかの1100件のうち82%よりスターが多い
  • このカテゴリのほかの1100件のうち24%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの1100件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

Sighttrueは安全ですか?

当てはまる基本チェック5項目のうち5項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか?

作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は今日、最新バージョン(1.0.0)がレジストリに届いたのは3 か月前です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URL で接続するので、リモート MCP を受け付けるアプリでも使えます。例:Web 版 ChatGPT(Business 以上はフル MCP、Pro は読み取りのみ)。

代わりに使えるものは?

同じカテゴリには:Medplum MCP, Mirobody, Apple Health

同じカテゴリのほかの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Medplum MCP

Securely access and manage FHIR healthcare data stored in Medplum.

作者:medplum広く使われている★ 27914 か月前更新

クラウドで動く✓ 提供元 · medplum.com

Mirobody

Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.

作者:thetahealth成長中↓ 290/週★ 14863 日前更新

パソコンで動く✓ thetahealth.ai

Apple Health

Local-first Apple Health MCP server for questions about your sleep, workouts and heart data.

作者:neiltron成長中↓ 106/週★ 5752 か月前更新

パソコンで動く

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

Sighttrue

[sighttrue.com](https://sighttrue.com) · your stack · compare · method · feed

Check your dependencies in CI

permissions:

pull-requests: write # only needed for the comment

steps:

  • uses: actions/checkout@v4
  • uses: sighttrue/sighttrue@v1 with: manifest: package.json fail-on: withdrawn,archived,relicensed

Fails the build when a dependency's own publisher has withdrawn it — npm calls it deprecated, PyPI and crates.io call it yanked, RubyGems yanked, Packagist abandoned, NuGet deprecated — or when its repository has been archived or moved to a source-available licence, and reports advisories either way. Reads package.json, requirements.txt, pyproject.toml, Cargo.toml, composer.json and Gemfile. No key, no account, no service to sign up to — it reads published measurements and talks to OSV. A network problem is never a finding: if the readings cannot be fetched the step says so and passes, because a build that breaks when somebody else's site is down is a build that gets deleted.

On a pull request it also leaves a comment with the findings as a table, and rewrites that same comment on every push rather than adding another. A red build tells a reviewer that something is wrong; it does not tell them which dependency, or what changed about it, without opening the log. Set comment: false to report only in the step summary. A pull request from a fork gets a read-only token, so the comment is skipped there and the step still passes.

Also runs against requirements.txt and Cargo.toml.

Or install the App and change nothing

The Action needs a workflow file in every repository that wants it. The GitHub App needs one install and then watches every repository it is given, with no workflow, no key and no configuration: when a pull request adds a runtime dependency that is on the watchlist, it leaves one comment with what is on record — downloads, OpenSSF scorecard, advisory count, licence, last push — and edits that same comment on every later push.

It says nothing at all when a pull request changes no manifest, adds no dependency, or adds nothing that is tracked. That is the common case and it is the point: a bot that comments to say it found nothing gets uninstalled. It never calls a package safe, unsafe or recommended, because none of those are things this project measures.

The Action fails a build; the App only reports. Both read the same published bundle, so they cannot disagree.

An SBOM you are allowed to hand over

/stack exports the readout as a CycloneDX 1.6 document, with each dependency's advisory count, scorecard, licence, publish date and bus factor attached as properties. Built in the browser from the pasted manifest, like everything else on that page — nothing is uploaded, and there is no endpoint to send a manifest to.

It states no versions. A manifest declares ^1.6.0; it does not say what was installed, and it says nothing about the transitive tree underneath. The document says both of those things in its own metadata rather than leaving a reader to notice, because an SBOM that guessed would be worse than none: a compliance artefact asserting something nobody resolved.

Suggest something to watch

The watchlist is curated and partial, and it was chosen by hand with no method beyond judgement — its weakest point. Open an issue to argue for a repository. Every change to the list is a reviewed commit, so that issue is where the review happens.

For coding agents

An MCP server over the same readings, so an agent can answer "is this dependency healthy" from a measurement taken today rather than from training data a year old.

{ "mcpServers": { "readout": { "url": "https://sighttrue.com/api/mcp" } } }

Nine tools free, twenty-two paid. check_before_install is the one to reach for while writing code: given a package it returns only what a reviewer would be annoyed to discover afterwards — a publisher that withdrew it, scripts it runs on the installing machine, an archived repository, advisories, a source-available licence, a long silence — each with the address of the body that published it. It does not say whether to install. It says what is on record so the decision is made knowing it, and an empty result says plainly that it means nothing was found rather than that the package is safe.

Then check_package, check_stack, search_repositories, compare_repositories, find_model, check_eol, check_provider, list_readings . Read-only, no key, no account. Every result carries the limits of what it can support, because an agent will paste these figures into a code review and a scorecard quoted without "measures declared practices, not whether the project is safe" is a claim this project does not make.

Without MCP, one GET returns the same thing:

curl 'https://sighttrue.com/api/verdict?pkg=npm:axios'

curl 'https://sighttrue.com/api/verdict?pkg=pypi:django&version=4.2'

Advisories, licence, when the registry last shipped it, the bus factor, and whether the release is still supported — each with the address of the body that published it, so a figure quoted into a review can be checked in one click. Despite the name there is no verdict in it: no score, no rank, no recommendation. Those would be this project's judgement of somebody else's work wearing the costume of a measurement.

One agent watches 417 open-source repositories and takes eleven readings, most of which never touch GitHub: 807 provider incidents kept after their own status pages dropped them, 522 release lines on the end-of-life clock, 382 model prices, 182 packages by real ship date, 416 commit histories for the bus factor. It runs every four hours on GitHub Actions, commits what it reads to this repository, and publishes a static site.

Every page and every bundle is a file. There are five dynamic routes and no page depends on any of them: /api/ask, /api/mcp, /api/chain, /api/github/webhook for the App, and the sign-in and watchlist endpoints under /api/auth and /api/watchlist. Signing in with GitHub saves a watchlist and nothing else — the readings on a signed-in page are the same published bundle anyone can download.

The commit history of data/ is the point. It is an audit trail: every reading is timestamped, append-only, and checkable against GitHub directly.

What it reports

Eleven readings, each named by the question it answers rather than by the collector that produces it. The same list drives the site's navigation, so the two cannot drift — they had, three times over, before it was written down once.

ReadingQuestion it answersTouches GitHub
LiveWhat changed in the last few hours?yes
ShipsWhat released a new version?yes
ForksWhat is being copied faster than its own baseline?yes
DemandWhat are developers asking for, across more than one project?yes
DependenciesWhat is being added, dropped, or jumped a major version?yes
LineageWhich models say they were built on which?no
Model pricesWhat does a million tokens cost, and when did that change?no
OutagesDoes the thing I depend on go down, and how often?no
EcosystemWhat do the registries, advisories and forums say?no
Depended onWhat does everything else quietly rely on?no
This weekWhat would I have missed looking once a week?—

The six that never touch GitHub are the answer to the fair complaint that a GitHub summariser is worth only what GitHub already shows you.

Whether each detector's threshold is reachable at all is published too, on the index under Our record. A detector nothing has ever come close to is not a quiet detector, it is a misconfigured one, and the site says so about itself.

How to read it

Every comparison is against a repository's own history, not against other repositories. "27× baseline" means 27 times what that project normally does, and the baseline is drawn on the chart so you can see what normal means.

Confidence is stated, never implied.

StateMeaning
formingUnder 14 days of history. Raw counts only. No multiplier is computed and none is implied.
detectedCrossed the threshold once. Neutral treatment.
confirmedPersisted across two consecutive daily snapshots.

Only confirmed signals are treated as findings. That costs up to a day of speed and buys the thing that cannot be bought back.

Generated prose is set in a different typeface from measured values. Where a sentence explains a number, every figure in that sentence is checked against the source record before it is published; if any of them is not in the record, the sentence is discarded and a templated one is used instead.

What this does not claim

  • The watchlist is curated and partial. It is chosen by hand and is not a survey of open source. Dependency and demand findings describe the repositories being watched, not the ecosystem.
  • The data is not real-time. Four hours is the floor, and scheduled runs are routinely delayed.
  • Nothing here predicts anything, and nothing here says a repository is good, bad, safe, or unsafe.
  • Appearing on the watchlist is an observation, not a relationship. No project listed here has endorsed this.

Published findings that turn out to be wrong are superseded by a correction event carrying the same prominence. Events are never deleted and history is never rewritten.

The data

Every bundle the site reads is served as JSON, so any claim can be checked against the same file the page used.

data/

├── live/state.jsonl Latest reading per repository. Sorted, rewritten each pulse. ├── live/window.jsonl Timestamped fork samples, for the rolling 24h delta. ├── live/manifests.jsonl Last-seen dependency set, diffed daily. ├── history/YYYY-MM-DD.jsonl One immutable snapshot per day. ├── events/YYYY-MM.jsonl Append-only. Never rewritten, never pruned. ├── summaries.jsonl Generated prose, keyed by event id. ├── watchlist.jsonl What is watched, and since when. └── meta.json Last run status.

Files are sorted with a fixed key order so a repository that did not change produces no diff. That is what keeps a repository committed to six times a day from growing without bound.

Running it

Node 24. Types are stripped natively, so there is no build step and no runtime dependencies.

It said 22.18+ until the D1 schema arrived. The tests load migrations/ into node:sqlite, which is stable in 24 and behind a flag in 22 — so on 22 the suite fails on an import rather than on an assertion, which is a confusing way to learn a version requirement.

npm install          # dev dependencies only: typescript, vitest, fonts

npm test npm run typecheck

node scripts/pulse.ts --limit=20 # needs GITHUB_PAT node scripts/daily.ts node scripts/build.ts # emits dist/

Watchlist maintenance

The watchlist is curated. Deriving it from a search query was tried and produced a worse list — topic search only finds repositories that tagged themselves, and sorting by stars ranks tutorials and link collections above infrastructure. derive-watchlist.ts is kept for proposing candidates a curator might have missed, and because the negative result is worth being able to reproduce.

node scripts/verify-watchlist.ts   # check every entry against the API

node scripts/retire-watchlist.ts # mark archived and deleted ones inactive node scripts/derive-watchlist.ts # propose candidates, writes n

冒頭だけを表示しています。続きはリポジトリで読めます