dea

Debug Anything

実行中のあらゆるプロセスを観察できます。ブレークポイントも、再起動も、計装も不要です。

あらゆるコーディングエージェント（Claude Code、Codex、Cursor、Gemini CLI）に、実行中のソフトウェアを観察する手段を提供するMCP サーバーとCLIです。システムコール、CPUフレームグラフ、スレッドスタック、ソケットとファイルディスクリプター、パケット、ヒープのリテーナー、コンテナの状態を確認できます。実戦で鍛えられたローカルツール（strace、py-spy、perf、lsof、tcpdump、gdb／lldb、Nodeのインスペクター）が観察を行い、Debug Anythingはその出力を、エージェントが推論でき、人間が監査できる構造化された証拠に変換します。

クイックスタート · Debug Anythingの仕組み · 観察できる内容 · 紹介例 · ワークフロー · Python／LangChain／LlamaIndex／CrewAI · 安全性 · よくある質問 · ロードマップ · コミュニティ

npx debuganything why <pid>       # or: why api-container --symptom leak

あらゆるpid、コンテナ、ポッドに対して、1つのコマンドで実行できます。アタッチ → 症状に応じた適切なツール（slow／leak／hang／crash／triage）→ 証拠IDを必ず引用した、優先順位付きの調査結果 → デタッチ。エージェントに接続するには、代わりにnpx debuganything setupを実行します。インストールも不要ですか？ツールの出力をブラウザーに貼り付けてください。

ウェブサイト：https://debuganything.dev · コミュニティ：Discord · ディスカッション · Debug Anythingは、このリポジトリ、debuganything npm／PyPIパッケージ、またはこのサイトからのみダウンロードしてください。

Debug Anythingの位置付け

MCP経由でステップ実行するデバッガーはすでに存在し、優れています。debugmcp/mcp-debugger（7言語対応）、microsoft/DebugMCP（VS Code）、jdwp-mcp（Java）、jkolo/debug-mcp（.NET）、pprof-mcp-agent（Go）などがあります。これらを使うには、デバッグアダプター、デバッグポート、または計装や再起動を行った対象が必要であり、ブレークポイントをどこに設定するか、すでに分かっていることを前提としています。

Debug Anythingは、その前段にあるレイヤーです。任意のpid、コンテナ、ポッドを、計装なしでブラックボックスとして観察し、証拠に変換します。

ブレークポイントの位置が分かっている場合はmcp-debuggerを使います。分からない場合はDebug Anythingを使います。

両者は相互に補完します。Debug Anythingが問題を関数やスレッドに絞り込むと、suggested_nextに引き継ぎ方法が含まれます。「file:functionにステップデバッガー（例：mcp-debugger）をアタッチする」、また、ネイティブシンボルの場合は*「静的解析ツールでlibfoo.soのparse_frameを逆コンパイルする」*といった内容です。ほかの利用例についてはdocs/examples.mdをご覧ください。

これが存在する理由

ソフトウェアは一度書けば、いつまでも動き続けます。そして、エンジニアリング上の問題の大半は、実行中に起こります。エージェントは、書く作業がとても得意になったばかりです。しかし、実行中の状態はまだ見えていません。エージェントはコードの全行を読んでも、目の前のプロセスがなぜ 4 GB を消費しているのかを説明できません。オブザーバビリティベンダーは、ダッシュボードで人間向けにこの問題を解決しました。エージェント向けに解決したものは、まだありません。

Debug Anything は、ソフトウェアエージェント向けの感覚レイヤーです。計画は次のとおりです。

1. ローカル — 1 つの MCP、1 台のノート PC、1 つのプロセス。推測ではなく証拠を重視します。（今回のリリース）
2. どこでも — コンテナー、ポッド、SSH 経由のリモートホスト、フリート。同じツール、同じ契約です。
3. 常時稼働 — 本番環境を監視し、午前 3 時にリグレッションに気づき、アタッチして診断し、フレームグラフを添付して PR を作成するエージェント。人間への通知は、証拠がある場合に限ります。
4. 標準化 — 証拠の契約（検出結果には証拠の引用が必要）が、あらゆるツールがあらゆるエージェントに報告する際の標準になります。これにより、人間はワンクリックでエージェントの主張を監査できます。

すべてのインターフェースは、ステップ 1 のコードがステップ 4 までそのまま使えるように設計されています。ターゲットは抽象化され（現在は pid、今後は container と pod、その次は host）、アダプターはプラグイン可能で、すべての結果が同じ証拠スキーマを持ちます。localhost を前提とするものはありません。

クイックスタート

0. ワンライナー

npx debuganything why <pid|container|pod>     # symptom flags: --symptom slow|leak|hang|crash

why は、1 つのコマンドで製品の機能をすべて提供します。準備状況を確認し、アタッチし、症状に合った観測ツール一式を選び、根拠となる証拠 ID とともに優先度順の検出結果を出力します。以下はすべて、同じエンジンをエージェントに組み込んだものです。

1. エージェントをセットアップする

npx debuganything setup

Claude Code、Codex、Cursor、Gemini CLI を検出し、追加する設定項目を正確に表示して、ファイルをバックアップしたうえで書き込みます。また、エージェントがスキルに対応している場合は、debug-anything スキルをインストールします。その後、エージェントを再起動してください。

ワンクリックでインストール：

Claude Code プラグイン：/plugin marketplace add shreyassaw5394/debuganything の後に /plugin install debuganything@debuganything · Gemini CLI：gemini extensions install https://github.com/shreyassaw5394/debuganything · スキル：npx skills add shreyassaw5394/debuganything

2. エージェントに尋ねる

数分経つと API が遅くなります。アタッチして、証拠を示しながら原因を教えてください。

ポート 8080 を使用しているものがあります。何が使っていますか？

この Python ワーカーは約 20 件のリクエストを処理するとハングします。何を待っているのか調べてください。

エージェントは readiness、attach、続いて適切なツールを呼び出し、証拠 ID を引用した検出結果を回答します。または、観測できなかった内容とその理由を伝えます。

3. エージェントがない場合は、1 つのコマンドで実行

npx -y debuganything@latest why 12345 --symptom leak     # or: slow | hang | crash | triage
debuganything why my-container --symptom crash
debuganything why -- node server.js                             # spawn it under observation

why はアタッチし、症状に合ったツールを実行して、それぞれの結果を出力します。 最後に優先度順の概要とレポートのパスを表示します。実行できない場合は失敗するのではなく、 readiness が実行不可と判断したツールをスキップします。

4. または、手順に沿って実行

npx -y debuganything@latest readiness
debuganything ps --filter node
S=$(debuganything attach 12345 --json | jq -r .session_id)
debuganything profile --session $S --duration 10
debuganything sockets --session $S
debuganything report  --session $S --md report.md
debuganything detach  --session $S
debuganything port 8080                      # who holds a port — no session needed

すべてのコマンドは --json を受け付け、正確な ToolResult を出力します。docs/cli.md を参照してください。

5. チーム全体で使うリポジトリをセットアップする

cd my-project && debuganything init     # .mcp.json + .cursor/mcp.json + a rule in AGENTS.md/CLAUDE.md — commit them

チームメンバー全員の Claude Code と Cursor が、リポジトリから Debug Anything を利用できるようになり、エージェントに利用タイミングを指示するルールも適用されます。日ごとの導入フローについては、docs/workflows.md をご覧ください。

6. エージェントスキルとしてインストールする

debug-anything スキル（調査指示、証拠のルール、同意に関するエチケット）は、Claude Code、Codex、Gemini CLI 向けに setup でインストールされ、skills.sh からも利用できます。

もう1つのスキルである inspect-product は、1つのバグを追うのではなく、製品全体を監査するためのものです。エージェントは、実行中のアプリを初めて使うユーザーとして操作し、これらのツールでその背後にあるランタイムを観察して、再現手順と証拠がそれぞれ付いた、優先度順の指摘事項を返します。「製品をレビューして、リリース前に修正すべき点を教えて」と頼んでください。どちらのスキルも npx debuganything setup でインストールできます。

npx skills add shreyassaw5394/debuganything

7. 更新する

debuganything update                        # or: npx debuganything@latest setup

Debug Anything の仕組み

agent ──MCP──▶ Debug Anything server ──▶ dispatcher ──▶ adapter (strace | py-spy | perf | lsof | tcpdump | gdb/lldb | inspector | docker)
                                 │                │  build command → run with caps → write raw artifact → parse → aggregate
                                 ▼                ▼
                           ToolResult { findings[] ──cite──▶ evidence[] ──point──▶ artifacts[] }  + limitations + suggested_next

• セッション。 attach はターゲット（pid、コンテナ、ポッド、またはキャプチャのもとで起動されたコマンド）を ~/.debuganything/sessions/<id>/ に解決します。すべてのツール結果は実行結果（profile_cpu#2 など）として保存されるため、diff_runs で実行前後を比較し、report で調査全体をまとめられます。
• 証拠の契約。 evidence_ids のない Finding はスキーマによって拒否されます。confidence: "inferred" は使用できますが、そうであることを明記する必要があります。エージェントが主張できるのは、証拠によって裏付けられる内容だけです。完全なスキーマについては、docs/mcp-contracts.md をご覧ください。
• アダプター。 各アダプターは、対応プラットフォーム、必要なバイナリ、提供するツールを宣言します。readiness は、このマシンで何が機能するかを判定します。パーサーは、実際にキャプチャした出力を使ってテストされた純粋関数です。新しいアダプターの追加に必要なコードは約80行です：CONTRIBUTING.md。
• プロンプト。 dea_slow、dea_leak、dea_hang、dea_crash、dea_port_busy は、ガイド付きの調査です。使用するツールの順序、確認する項目、証拠 ID なしに原因を断定してはならないというルールが含まれています。

観察できる内容

0.4 の新機能：Java スレッドダンプ（jstack、実行中のものまたはインポートしたもの）、Go のゴルーチンダンプ、ブラウザー分析ツール（貼り付けて利用）、共有可能な HTML レポート（debuganything report --html）、セッションをまたぐベースライン差分（debuganything diff --session now '<baseline>:<run>' <run>）、および GitHub Action による CI ハングのフォレンジック です。

対象	Debug Anything が返す内容	要件
任意のプロセス：ソケット (inspect_sockets)	リッスンポート、リモートごとに分類した接続、CLOSE_WAIT／TIME_WAIT／SYN_SENT の滞留、fd 数と ulimit の比較	lsof — Linux、macOS。自分のプロセスであれば root 不要
任意のプロセス：ファイル (inspect_files)	種類ごとの fd、一定時間内の fd 増加数、開いているファイルのうちサイズが大きいもの、ディスクを占有している削除済み・オープン状態のファイル	lsof — Linux、macOS（削除済み・オープン状態のファイルは Linux のみ）
任意のプロセス：メモリ (snapshot_memory)	RSS／VSZ の推移、/proc のステータス（anon／file／swap／threads）	ps — Linux、macOS
Node.js：ヒープ (snapshot_memory)	V8 ヒープスナップショット、型とコンストラクターごとのバイト数、保持サイズが大きいリテーナーと保持経路（Context.retained、Map.table など）	Node のインスペクター（必要に応じて SIGUSR1 で有効化）— Linux、macOS
Node.js：JS スタック (dump_stacks)	メインスレッドの JS コールフレーム、イベントループがアイドル状態かブロック状態か	Node のインスペクター — Linux、macOS
Python：CPU (profile_cpu)	自己時間／合計時間ごとの上位フレーム、最も負荷の高いスタック、flamegraph.svg	py-spy — Linux（ptrace_scope=0 または root）、macOS（sudo）
Python：スレッド (dump_stacks)	すべてのスレッドのスタック、ソース行（with lock_b:）を用いてロック／join／スリープ／I/O に分類したブロック中のスレッド、デッドロックの検出	py-spy — Linux、macOS（sudo）
macOS：ファイルおよびネットワークのシステムコール (trace_syscalls)	fs_usage による呼び出しごとの所要時間、ブロック中の呼び出し、errno（ENOENT、ECONNREFUSED など）。root が必要なため、Debug Anything が sudo コマンドを表示し、debuganything import fs_usage <file> で取り込みます	fs_usage — macOS、プリインストール済み
自分で取得したデータ全般 (debuganything import)	strace、fs_usage、perf script、py-spy、sample、gdb/lldb、lsof、tcpdump のテキストを取り込み、ライブ実行と同じ証拠と調査結果を取得します。「root が必要か」という質問への答えも得られます	—
Linux：システムコール (trace_syscalls)	合計時間と回数の多い上位システムコール、パス／アドレス付きの最も遅い呼び出し、エラー件数（ENOENT、EAGAIN、ECONNREFUSED など）、ブロック待機に費やした時間の割合	strace — Linux。ptrace_scope=0 または root
ネイティブ／Node／Go／Java：CPU (profile_cpu)	perf サンプリング → 折りたたみスタック → flamegraph.svg（Perl 不要）、アイドル時と処理中の内訳	perf — Linux（perf_event_paranoid ≤ 1 または root）。Node では JIT 名の取得に --perf-basic-prof が必要
ネイティブ／Node：macOS の CPU (profile_cpu)	sample のコールグラフ → 折りたたみスタック → フレームグラフ	sample — macOS、プリインストール済み
ネイティブ／Node／Go／Java：スレッド (dump_stacks)	すべてのスレッドのバックトレース、ミューテックス待ち／条件変数待ち／ブロッキング I/O 中のスレッド、デッドロックのヒューリスティック検出	gdb — Linux。lldb — macOS
ネットワーク (capture_traffic, consent)	リモートごとのパケット数／バイト数、RST、応答のない SYN、再送の可能性、DNS クエリ、.pcap アーティファクト。フィルターは対象のポートのみから導出し、範囲を無制限にしません	tcpdump — Linux、macOS。root／CAP_NET_RAW／access_bpf
Docker コンテナー (container_info)	状態、OOMKilled、終了コード、再起動回数、メモリ／CPU の制限と使用状況、cgroup のスロットリングと OOM イベント、公開ポート、ログ末尾のエラー行。他のすべてのツールで使える、コンテナーからホスト pid への対応付け	docker — Linux（ホスト pid を参照可能）、macOS（container_info のみ）
Kubernetes ポッド (attach ns/pod)	kubelet がこのホスト上で実行されている場合に、ポッドのコンテナーをローカル pid に解決します（kind、minikube、k3s）	kubectl — 実験的
使用中のポート (debuganything port N)	ポートを使用している pid、コマンドライン、ユーザー、または TIME_WAIT／CLOSE_WAIT の残留	lsof
前後比較 (diff_runs)	同じツールを実行した 2 回の間に増加、減少、出現、消失したもの	—
Windows	未対応 — readiness で確認できます	予定：ETW、procdump
正直な状況：上記の内容はすべて、サンプルアプリに対して Linux（Debian 12 コンテナー、root）および macOS 15（独自プロセス、sudo なし）で実際に実行しました。bpftrace スクリプトは用意されていますが、まだツールには接続されていません。OS ごとのインストールコマンドについては、docs/providers.md をご覧ください。

例

実際の状況 — CLOSE_WAIT の大量発生と EMFILE、du の結果と食い違うディスク容量不足、Postgres の接続プール枯渇、Celery のデッドロック、Node のイベントループのブロック、OOMKilled ポッド、すべてのリクエストで発生する DNS 解決、クラッシュ後の EADDRINUSE、読み解けないネイティブコードのホットスポット。それぞれのセッション、証拠、修正方法はこちらです：docs/real-world.md。

コピー＆ペーストして使える10の状況（API の遅延、メモリーリーク、ハング、ポートの使用中、コンテナーのクラッシュ、監視下でのプロセス起動、修正の検証、CI 回帰ゲート、同意を得たパケットキャプチャ、Python エージェント）については、docs/examples.md をご覧ください。

ショーケース

examples/ を使って再現できます。完全なトランスクリプトは docs/showcases.md、Debug Anything が自動生成した完全なレポートは docs/example-report-leaky-node.md にあります。

leaky-node — すべてのリクエスト本文をモジュールレベルの配列に保持する HTTP サーバーに、ループ内で readFileSync を実行する /slow ルートと800 ms のタイマーを加えたものです。 snapshot_memory ×2 と diff_runs：RSS は 85 → 172 MB（+102 %）、ヒープは 37 → 97 MB。リテンションの上位は Array で、保持サイズは 17 → 47 MB に増加しました。trace_syscalls（8 秒）：openat/statx による検索が5 600回、read() の呼び出しが3 314回あり、「ループ内の同期 I/O」と判定されました。また、epoll_pwait は一度に約800 ms 眠っていました。

deadlock-py — リクエスト20の後、順序を逆にして2つのロックを取得するスレッド型サーバーです。 dump_stacks：worker-ab-20 は app.py:26 の [with lock_b:] でブロックし、worker-ba-20 は app.py:33 の [with lock_a:] でブロックしています。8つのリクエストスレッドがそれらの終了を待っており、実行中のスレッドはありません。「デッドロックの可能性が高い」と判定され、worker_ab でステップデバッガーに引き継がれます。

busy-port — プロセスが :8080 を保持し、スクリプトが EADDRINUSE で失敗する状況です。 debuganything port 8080：port 8080 is held by pid 47508 (node, user shreyassawant) in LISTEN — command: node server.js. Debug Anything will not kill it; decide yourself.

エージェントが自発的に使います

インストールすると、コマンドがハングする、テストがタイムアウトする、出力に EADDRINUSE／ECONNREFUSED／EMFILE／終了コード137／OOM／セグメンテーションフォールトが含まれる、起動したサーバーが応答しない、または遅延、ハング、メモリーリーク、クラッシュについて言及した場合に、エージェントが自ら Debug Anything を使うよう指示されます。Claude Code では、setup により、コマンド出力内のこうした兆候を検出して、適切な Debug Anything ツールを使うようモデルに促す小さなフックもインストールされます。読み取り専用の監視に許可は不要ですが、capture_traffic には常に許可が必要です。詳細と無効化オプション（--no-hooks）については、docs/proactive.md をご覧ください。

Python、LangChain、LlamaIndex、CrewAI

pip install debuganything                 # plain client (no deps; uses npx under the hood)
pip install 'debuganything[langchain]'    # debuganything.langchain.debuganything_tools()
pip install 'debuganything[llamaindex]'   # debuganything.llamaindex.debuganything_tools()
pip install 'debuganything[crewai]'       # debuganything.crewai.debuganything_tools()

from debuganything import DebugAnything
debuganything = DebugAnything()
s = da.attach(12345)
print(da.findings(da.profile_cpu(s, duration_s=10)))
da.detach(s)

各アダプターは、同じ ToolResult を返す同一の14個のツールを公開します。MCP にネイティブ対応したフレームワークでは、パッケージを使わずに npx -y debuganything serve を実行できます。詳細は python/README.md をご覧ください。

エージェントにデバッグを頼むだけではだめなのですか？

現時点では、エージェントにはできないからです。エージェントはプロセスにアタッチできず、strace／perf／lsof の構文やフラグの扱いにも苦労します。10秒分の strace はテキストで1.5 MB にもなり、コンテキストウィンドウを圧迫します。測定できない場合は、自信満々に推測します。Debug Anything は、適切なツールと適切なフラグを厳格な上限内で使える「目」と、未加工の成果物を示す要約や、それらを必ず引用する所見という「証拠」を提供します。もっともらしい説明ではなく、監査可能な診断を得られます。

安全性

• 読み取り専用です。 v0 のツールは観察のみを行います。プロセスの強制終了、ブレークポイントの設定、動作を変更するプローブは行いません。文書化されている例外として、Node のターゲットにはインスペクターを有効にするため SIGUSR1 を送信する場合があります。
• 同意が必要です。 capture_traffic の実行には consent: true が必要です。スキルは、エージェントに事前にあなたの許可を求めるよう指示します。
• 厳格な上限を設けています。 各ツールの実行時間は 60 秒（キャプチャは 30 秒）、ディスク上の未加工出力は 50 MB、エージェントに返すデータは 16 KB です（要約と参照情報。引用された証拠は決して削除されません）。すべての子プロセスは SIGTERM の後に SIGKILL で終了させます。
• sudo は一切使いません。 ツールに root 権限が必要な場合は ok: false と、あなた自身が実行できる正確なコマンドを返します。readiness は ptrace_scope、perf_event_paranoid、SIP、sudo -n の状態を最初に報告します。
• 対象を限定します。 アダプターが操作するのは、アタッチされた pid ツリーまたはコンテナーだけです。キャプチャは対象のポートに絞り、無制限の実行は拒否します。
• シークレット。 ベアラートークン、AWS キー、JWT、password=、API キー、秘密鍵、user:pass@ を含む URL は、エージェントに返されるすべての内容でマスキングされます。ディスク上の未加工アーティファクトはマスキングされません。~/.debuganything/sessions/ は機密情報として扱ってください。
• クラウド接続なし。テレメトリーなし。 Debug Anything 自体はネットワーク呼び出しを行いません。すべてのデータはお使いのマシン内にとどまります。

詳細：docs/safety.md · DISCLAIMER.md · SECURITY.md

FAQ

どのエージェントが使えますか？ 標準入出力経由で MCP と通信するものなら使えます。setup は Claude Code、Codex、Cursor、Gemini CLI を認識します。それ以外の場合は、MCP 設定に {"command":"npx","args":["-y","debuganything@latest","serve"]} を追加してください（docs/installation.md）。

strace／perf／py-spy をインストールする必要がありますか？ 使いたいツールに限り必要です。readiness には利用可能なツールが一覧表示され、インストール方法も示されます。Linux と macOS では lsof、ps、Node のインスペクターをすぐに利用できます。

root 権限が必要ですか？ macOS で自分のプロセスを調べる場合（lsof、sample、lldb、インスペクター）や、Linux で ptrace_scope=0 の場合は不要です。macOS の py-spy と fs_usage、およびすべての環境で tcpdump を使う場合は必要です。Debug Anything は正確な sudo コマンドを表示します。そのコマンドをご自身で実行し、debuganything import <tool> <file> を使うと、同じパーサーで出力を分析できます。

macOS では何を確認できませんか？ strace と perf はありません。fs_usage（インポート経由）でファイルおよびネットワークの呼び出しを確認できます。残りは sample、lldb、lsof、Node インスペクターで確認できます。システムコールとカーネル時間をすべて把握するには、Linux コンテナー（docker/linux-lab）でターゲットを実行してください。

Debug Anything は何かをアップロードしますか？ いいえ。ネットワーク呼び出しも、テレメトリーも、明示的な debuganything update を除く更新確認も行いません。

Docker コンテナーをデバッグできますか？ Linux ではできます。コンテナー名を指定してアタッチすると、各ツールがホストの pid を介して動作します。macOS では Docker VM によって pid が見えないため、ホストから使えるのは container_info のみです。代わりに、コンテナー内で Debug Anything を実行してください（docker/linux-lab にはすべてのプロバイダーがそろったイメージがあります）。

ステップデバッガーとは何が違いますか？ Debug Anything はプログラムを特定の行で停止させません。実行中のプロセスをサンプリング、トレース、スナップショットし、確認すべき箇所を示します。その後、mcp-debugger または IDE に引き継いで、内部を詳しく調べてください。

アーティファクトはどこにありますか？ ~/.debuganything/sessions/<id>/（変更するには DEA_HOME を設定してください）。debuganything sessions list／debuganything sessions prune。

ロードマップ

bpftrace の定型スクリプト · 一時的なデバッグコンテナー経由の Kubernetes ポッド · Windows（ETW、procdump） · Java（async-profiler、jcmd Thread.print） · Go（pprof、delve によるゴルーチンダンプ） · Rust／C++ DWARF アンワインディング · Linux での eBPF 優先トレース · Python tracemalloc／memray · Node の CPU プロファイリング（インスペクターの Profiler 経由） · ロック所有者グラフ · SSH 経由のリモートエージェントモード。全リスト：docs/roadmap.md。

コミュニティ

• Discord： https://discord.gg/htPuQ5grg — 質問、成果の共有、セッションの読み取りに関するサポート。
• ディスカッション： https://github.com/shreyassaw5394/debuganything/discussions — 長めのアイデアやRFC。
• Issue： テンプレートを使ってバグやアダプターのリクエストを投稿してください。アイデアはディスカッションをご利用ください。
• セキュリティ： 非公開のアドバイザリーのみです。SECURITY.mdをご覧ください。

コントリビューション

mainは保護されています。変更はすべて、コードオーナーがレビューするプルリクエストとして提出してください。 アダプターは約80行です。platforms／requires／toolsを宣言し、コマンドを構築して、runCapped経由で実行し、純粋関数で解析し、ResultBuilderを使ってエビデンスと検出事項を出力します（エビデンスのない検出事項は拒否されます）。実際のツール出力を一度だけtests/fixtures/に保存し、それを使ってパーサーをテストしてください。手順はCONTRIBUTING.mdをご覧ください。

コントリビューター

プルリクエストを取り込まれた皆さんです。アダプター、フィクスチャ、またはドキュメントを追加すると、ここに顔が表示されます。

npm、PyPI、GitHub、MCP Registryの数値：bash scripts/stats.sh。

ライセンスと免責事項

MIT — LICENSEをご覧ください。Debug Anythingは**「現状有姿」で、いかなる保証もなく**提供されます。作者およびコントリビューターは、サービス停止、データ漏えい、またはその使用に起因するその他の損害について、一切の責任を負いません。Debug Anythingは、実行中のソフトウェアに観測ツールを接続します。自分が所有するシステム、またはデバッグする明示的な許可を得たシステムのみを観測してください。許可の取得と、適用される法令およびポリシーの遵守は、すべて利用者の責任です。観測にコストがかからないわけではありません（ptraceは対象を一時停止させ、キャプチャやヒープダンプには秘密情報が含まれることがあります）。検出結果は自動診断であり、専門家の助言に代わるものではありません。また、Debug Anythingはコントリビューターが個人の立場で開発する独立したプロジェクトであり、雇用主や連携するサードパーティ製ツールとは無関係です。利用規約の全文：DISCLAIMER.md。