Context Intelligence Layer for all Coding Agents

██╗     ███████╗ █████╗ ███╗   ██╗     ██████╗████████╗██╗  ██╗
██║     ██╔════╝██╔══██╗████╗  ██║    ██╔════╝╚══██╔══╝╚██╗██╔╝
██║     █████╗  ███████║██╔██╗ ██║    ██║        ██║    ╚███╔╝
██║     ██╔══╝  ██╔══██║██║╚██╗██║    ██║        ██║    ██╔██╗
███████╗███████╗██║  ██║██║ ╚████║    ╚██████╗   ██║   ██╔╝ ██╗
╚══════╝╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝     ╚═════╝   ╚═╝   ╚═╝  ╚═╝

どのような位置づけか

Files · repositories · tool results · configured providers
                          │
                          ▼
                LeanCTX Context Gateway
             Select · Control · Learn · Prove
                          │
                          ▼
                Your AI application / agent
                          │
                          ▼
                     Your model

• 選択： 検索、構造化ビュー、圧縮、再利用を通じて、タスクに必要なコンテキストをAIに提供します。
• 制御： 対応する呼び出しに、設定済みのパス権限、コンテンツフィルター、コンテキストの上限を適用します。
• 学習： 設定されたアクセスと保持のルールの範囲内で、ローカルのタスク記録を保持し、セッションをまたいでコードとナレッジを結び付けます。
• 証明： ソース参照、ポリシーの判断、使用状況の証跡を確認します。 コンテキストのみの連携では準備した結果を記録し、その後のモデル呼び出しはホストが担います。

コーディングワークフローでは、まず Claude Code、Cursor、またはCodex をお試しください。 インストールマトリックスでは、 ファーストクラスの導入経路とその他の互換性に関する記載を区別しています。

LeanCTXとは？ · LeanCTXの位置づけ · アーキテクチャ

動作をご覧ください：

読み取り＋シェル マップモードでの読み取り＋圧縮されたCLI出力

ゲイン（リアルタイム） トークン使用量と推定コストの差

ベンチマーク測定 言語とモード別に圧縮率を測定

_{すべてのGIFは、demo/にある再現可能なVHSテープから生成されています。}

開発者がLeanCTXを使う理由

• 入力の絞り込み — 読み取りの繰り返しやノイズの多い出力に使うコンテキストウィンドウを削減します。
• 設定可能な制御 — ファイルアクセスを制限し、対応する結果を配信前にフィルタリングします。
• 継続性 — ローカルのタスク、発見事項、判断の記録をセッション間で保持します。
• 既存ツール — lean-ctx setupで対応する連携を設定できます。
• 確認可能な使用状況 — トークンの推定値、プロバイダーからの観測値、計算コストを分けて表示します。
• モデルの選択 — 独自のモデル呼び出しとアプリケーションのワークフローを維持できます。

LeanCTXが役に立ちましたか？ スターを付けてください — AIシステム向けコンテキストゲートウェイを、より多くの方に知っていただく助けになります。

LeanCTX Engineの内部

Engineは、既存のAIツールのコンテキスト経路に「選択」「制御」「学習」「証明」を組み込みます。タスク、エージェントループ、モデルの制御はホストが維持します。

1. 選択 — 各タスクに必要なコンテキスト

検索と構造ビューにより、エージェントはファイル全体を読む前に関連情報を見つけられます。対応する読み取りパスとシェルパスでは、ファイルやコマンド出力の要点を絞ったビューを返し、詳細を取得するための参照も提供します。

• ファイルの読み取り：16 種類の読み取りモード（full、map、signatures、diff、lines:N-M、density:X、…）。条件を満たすキャッシュ済みの再読み取りでは、内容を繰り返す代わりに簡潔な参照を返します
• 目標密度（density:0.4）：SDE スタイルの予算圧縮。元のトークンの約 40％が残るまで、エントロピーの高い行を優先して保持します。結果は決定論的です
• JIT 開示：signatures は行範囲を示し、対象を絞って展開できる lines:N-M を参照します。まず概要を確認し、必要に応じて本文を取得できます
• シェル出力：85 種類以上のシェル出力パターンが git、npm、cargo、docker、kubectl、terraform などを圧縮します（250 種類以上のパススルールール）
• Tree-sitter AST：27 言語の構造を理解します。単なるテキスト圧縮ではありません
• ソースの復元（CCR）：対応する簡潔なビューには、ctx_expand、ctx_retrieve、または参照 API を使った展開に対応するソース参照またはアーカイブ参照が保持されます。復元の可否は、権限、保持期間、ソースが引き続き利用可能かどうかによって異なります。読み取りモードと詳細 →

2. 制御 — 対応パスに適用される設定済みルール

• **PathJail とロール：**ツールのファイルシステムアクセスを、設定された範囲内に制限します。
• **コンテンツフィルター：**設定済みの検出器は、対応パス上で警告、編集、またはブロックを行えます。検出範囲と適用内容は、インテグレーションと設定によって異なります。
• **コンテキスト予算：**選択された入力と、対応するツール出力を制限します。
• **ホストが管理するモデル選択：**ホストがモデルを選択し、Engine の監視対象パス外で行われるモデル呼び出しを実行します。

既定値、対応する制御、適用範囲の制限については、セキュリティポリシーを確認してください。ファイルシステムの境界は、オペレーティングシステムのサンドボックスではありません。

3. 学習 — セッションをまたいで作業をつなぐ

有用なタスク記録を保持し、コードとローカルのナレッジとの関係を見つけられます。ここでいう学習とはコンテキストの継続性を指し、モデルをトレーニングすることではありません。

• セッションメモリ（CCP）：タスク、事実、決定事項をチャット間で保持します。構造化された復元クエリは、コンパクション後も利用できます
• ナレッジグラフ：有効期間を持つ時間的な事実と、エピソード記憶および手続き記憶を扱います
• プロパティグラフ：複数のエッジを持つコードグラフ（imports、calls、exports、type_ref）が、影響分析と検索ランキングを支えます
• **権限に基づく再利用：**保存済みのコンテキストを取得する場合も、アクセスと保持のルールが適用されます。実験的な .ctxpkg のエクスポートについては、以下の「研究」を参照してください。

4. 証明 — Engine が記録した内容を確認

対応パスから、ソース参照、記録されたポリシー決定、配信の証拠を確認できます。lean-ctx inspect は、観測されたコンテキスト操作について説明します。コンテキストのみを扱うインテグレーションでは、準備した結果が記録されますが、その後ホストが行うモデル呼び出しを証明することはできません。

• Context Manager：トークンのリアルタイム追跡、圧縮統計、使用率ゲージを備えたブラウザダッシュボード
• **監査エクスポート：**記録された証拠を、明示された範囲内でのレビュー用に保持します。
• Context Proof（ctx_proof、ctx_verify）：エクスポート可能な監査証跡（検証者、SLO、パイプライン、来歴の記録）に加え、実行時にチェックされるポリシーの主張（アクセス対象ファイルごとの PathJail、予算）

使用量とコスト — 結果を測定

まずコンテキストの制御と証拠を確認します。使用量の推定と計算コストは、その運用上の影響を評価するのに役立ちますが、回答の品質を証明するものではありません

シャドーモード — シミュレーションによるベースライン

シャドーモードは、アクティブなワークフローを変更せずに、LeanCTX を使わずに同じ作業を行った場合のコストを推定します。ベースラインは、2 回目の実測ではなく、圧縮前のトークン数と同じ成果シグナルからシミュレーションされます。そのため、レポートで推定されるのはコスト、トークン数、CPAO の差分であり、回答の品質を測定するものではありません。

LeanCTX は、エージェントのコンテキストにレポートを追加せずに、コストと成果のシグナルをローカルに記録します。CPAO（受け入れられた成果あたりのコスト）は比較指標の 1 つであり、シャドーモードでは節約額をシミュレーションで推定します。推定値、プロバイダーが実測した使用量、成果の品質は、それぞれ別に扱ってください。

lean-ctx savings --period week                 # costs, token savings, and CPAO
lean-ctx value-report --format markdown --last 20  # recent outcome quality
lean-ctx shadow --latest                       # latest baseline comparison

クイックスタート：使用状況の追跡

# Enable shadow mode for savings comparison
lean-ctx config set shadow.enabled true

# After using LeanCTX for a while:
lean-ctx savings
lean-ctx shadow --latest

アドオンマニフェストとゲートウェイ統合は、引き続き実験的なリサーチインターフェースです。 ローカルの addon release|add|list コマンドは署名済みパッケージを扱いますが、 公開マーケットプレイス、ホスト型レジストリ、管理された配布、addon search は提供しません。パッケージには、サンドボックス化された WASM モジュール、または外部サーバー用の [mcp] 宣言を含められます。

lean-ctx addon release ./my-addon   # build a signed .ctxpkg — no artifact host, no CI
lean-ctx addon add ./my-addon-1.0.0.ctxpkg   # verify, disclose, ask, install
lean-ctx addon list                 # what's installed, what loads, what's wired

• 自分で公開する — モジュールは署名済みパッケージの内部に格納されるため、 署名は実行可能なバイト列を対象とします。外部でホスト、ハッシュ化、配信するものはなく、 独自のパイプラインも必要ありません。
• ローカルで検証してから確認する — add はソースを信頼するのではなく、 お使いのマシン上で署名を再検証し、すべてのモジュールを固定された SHA-256 と照合し、 公開者の鍵と、宣言されたサーバーが実行する正確なコマンドを表示してから、確認を求めます。
• LeanCTX がサーバーをインストールすることはありません — uv tool install も npx も使いません。宣言されたツールの取得はお客様自身の手順となり、 お使いのパッケージマネージャー独自の信頼モデルが適用されます。マニフェストには、そのツールの実行方法が記載されています。
• 単にプロキシするのではなく、統合する — オプトインの後処理では、コードと同じパイプラインでアドオンの出力を処理します。予算に合わせて圧縮し、大きすぎるデータを ctx_expand ハンドルに退避し、BM25／グラフ／ナレッジにインデックス化します。型付きの integration を使うと、特定のツールを ctx_expand、ctx_callgraph、ctx_knowledge に直接ルーティングできます。
• デフォルトでは信頼しない — アドオンの結果はシークレットのスクラブ処理を通過し、統合パイプラインで信頼できないものとしてタグ付けされます。スクラブ処理の対象は、設定された検出パターンであり、考えられるすべてのシークレットではありません。

ローカルのワークフローでは、署名とモジュールハッシュを検証し、インストール前に公開者の 鍵と宣言されたコマンドを表示します。また、外部サーバーをインストールすることはありません。 オプトインの後処理では、アドオンの結果を圧縮、ctx_expand、BM25、グラフ、ナレッジに渡せます。 結果は引き続き信頼できないものとして扱われます。設定されたシークレットのスクラブ処理は、考えられるすべてのシークレットを対象とするわけではありません。境界については、 **ステータスに関する注記付きのアドオンガイド**をご覧ください。

リサーチの方向性

LeanCTX は引き続き、AI システム向けのコンテキストゲートウェイです。以下のリサーチの方向性は、 コンテキスト機能を拡張するものであり、サポート対象の製品としての確約ではありません。

• ホスト型コンテキスト履歴 — ローカルでのスナップショットの作成／表示／検証／復元と、ファイルベースの署名付き共有は実験的なリサーチ機能です。ホスト型レジストリとモデル表示の比較は、今後の課題です。(概念 →)
• コードとしてのコンテキスト — TOML で宣言的なパイプライン、プロファイル、ポリシーを定義し、インフラストラクチャと同様にバージョン管理します
• 統合コンテキストグラフ — コード、テスト、コミット、CI 実行、ナレッジ項目を単一のセマンティックグラフにまとめます
• エージェント間のコンテキスト制御 — ホストがエージェントのスケジューリングとワークフロー実行を担う一方で、コンテキストのロール、予算、権限を検討します
• コンテキストの可観測性 — コンテキスト消費に関する SLO、異常検知、OpenTelemetry／Prometheus へのエクスポート

ロードマップの全容は VISION.md にあります。

仕組み

LeanCTX は、エージェントが読む内容と、エージェントがモデルに送信する内容という、2 つのプレーンで動作します。

read path:   AI tool  →  (MCP tools + shell)  →  lean-ctx  →  your repo + CLI
wire path:   AI tool  →  lean-ctx proxy        →  model provider   (supported, configured requests)

• MCP サーバー（読み取りパス）：ctx_* ツールを公開します（読み取りモード、キャッシュ、差分、検索、メモリ、マルチエージェント）。
• シェルフック（読み取りパス）：一般的なコマンドを透過的に圧縮し、LLM に表示されるノイズを減らします。
• リクエストプロキシ（通信経路、オプトイン）：lean-ctx proxy enable を実行すると、対応するリクエストがローカルプロキシ経由でルーティングされます。設定した変換により、対応するプロバイダーキャッシュの境界を尊重しながら、対象となるプロンプト、履歴、ツールの結果の内容を削減できます。プロバイダー固有の推論負荷のマッピング（proxy.effort）、詳細度の制御、変動するプレフィックスの処理には、それぞれ互換性の制限があります。復旧には、保持されている認可済みのアーティファクトが必要です。使用状況とコストの証拠は、この経路で確認できるプロバイダーデータに依存します。
• プロパティグラフ：複数のエッジで構成されるコードグラフにより、影響分析、関連ファイルの検出、検索順位付けを実現します。
• セッションメモリ：認可済みの記録が利用可能な場合に復旧できるよう、選択したセッション状態を保持します。
• コンテキストマネージャー：LeanCTX から確認できるコンテキストのアクティビティと記録を調べるためのブラウザーダッシュボードです。

はじめに

# 1) Install (pick one)
curl -fsSL https://leanctx.com/install.sh | sh      # universal (no Rust needed)
brew tap yvgude/lean-ctx && brew install lean-ctx    # macOS / Linux
npm install -g lean-ctx-bin                          # Node.js
cargo install lean-ctx                               # Rust

# 2) One-command setup for your agent
lean-ctx wrap cursor      # or: wrap claude / wrap codex

# Inspect recorded context metrics after your AI's first lean-ctx call.
lean-ctx gain

lean-ctx wrap は MCP サーバーを登録し、そのエージェントでサポートされているローカルトランスポートを設定します。lean-ctx unwrap cursor を実行すれば、いつでも元に戻せます。

Claude Pro/Max： サブスクリプションの OAuth では、カスタムの ANTHROPIC_BASE_URL を使用できません。そのため、lean-ctx wrap claude は ctx_* ツールとシェル出力の圧縮を有効にしつつ、プロキシへのリダイレクトは追加しません。既存のカスタムエンドポイントは変更されません。 Claude の通信レベルでのリクエスト圧縮には ANTHROPIC_API_KEY が必要です。 高度なプロキシ設定を参照してください。

lean-ctx onboard          # connect all detected AI tools (zero prompts)
lean-ctx setup            # interactive wizard with every option

Windows でソースからビルドしますか？ リポジトリをクローンし、PowerShell で ./install.ps1 を実行してください。リリースバイナリをビルドし、Cargo の bin ディレクトリにインストールします（インストールせずにビルドするには -BuildOnly を渡します）。

実際の利用シナリオ

LeanCTX は利用に合わせて進化します。以下は、多くの人が実際にたどる利用の流れです。それぞれのリンク先では、機能ごとの詳しい手順を確認できます。 **リファレンス**には、すべての CLI コマンドと MCP ツールの完全な説明が掲載されています。

lean-ctx wrap cursor  # one-command setup for your agent
lean-ctx doctor       # confirm you're wired up

lean-ctx read src/server.rs -m map   # API surface, ~13 tok on re-read
lean-ctx -c "git status"             # compressed shell output

lean-ctx overview                    # task-aware project recap
lean-ctx knowledge recall "auth"     # facts that survive resets
lean-ctx knowledge consolidate       # import session + compact lifecycle
lean-ctx knowledge consolidate --all # compact every project store

lean-ctx graph impact src/auth.rs    # blast radius
lean-ctx smells scan                 # code-smell hotspots

lean-ctx provider list
lean-ctx serve --root ./api --root ./web   # multi-repo

lean-ctx doctor --fix
lean-ctx update

lean-ctx plan "refactor billing" --budget 8000
lean-ctx compile --mode balanced

ctx_agent action=register role=dev
ctx_handoff action=create        # baton-pass with full context

lean-ctx team serve --config team.toml
lean-ctx bootstrap            # zero-prompt CI setup

lean-ctx compression standard
lean-ctx harden               # enforce token discipline

lean-ctx gain --deep          # savings, cost, per-agent, heatmap
lean-ctx wrapped              # shareable recap (also: gain --svg / gain --share)
lean-ctx savings              # verified per-event ledger (auditable; savings verify)

LeanCTX は MCP サーバーを提供します。クライアントの対応状況は、トランスポート、ツールの処理方法、設定によって異なります。以下の表に、統合の範囲を示します。 対応エージェントでは、次の 2 つの統合モードを選択できます。

エージェントの互換性マトリクス

MCP クライアントには、互換性のあるトランスポート、ツールのサポート、設定が必要です。この表にはセットアップ対象を記載しています。クライアントの制約では、検証済みの統合と一般的な互換性を区別しています。

利用に適した場合と、そうでない場合

次のような場合に最適です……

• AI コーディングツールを毎日使い、セッションでシェルを多用する（git／テスト／ビルド）
• 中規模または大規模なリポジトリ（50 ファイル以上／モノレポ）で作業する
• ネットワークとテレメトリの制御を確認できる、ローカルでのコンテキスト処理を希望する

次のような場合はおすすめしません……

• 小規模なリポジトリでの作業が中心で、AI ツールからシェルを呼び出すことがほとんどない
• 常に未加工／未フィルタリングのログが必要（--raw も使えますが、投資対効果は低くなります）

率直に言うと、効果を左右する要素は 3 つあります。適用範囲（ctx_* ツール層だけでなく、プロキシ／エンジンを介してウィンドウ全体を扱う）、コンテキストの存続期間（長時間存続する 1 つのセッションか、フェーズごとに新しいプロセスを起動するか）、プロバイダーの料金体系（プロンプトキャッシュ料金か、ターンごとに再課金されるか）です。これらがすべてそろえば明確な効果が得られ、そろわなければ収支がほぼ均衡します。詳しくは、効果が得られる場合と収支がほぼ均衡する場合のマトリクスで、各ケースの詳細と調整方法をご覧ください。

デモ

任意のリポジトリで次のコマンドを試してください。

lean-ctx read rust/src/server/mod.rs -m map
lean-ctx -c "git log -n 5 --oneline"
lean-ctx gain --live
lean-ctx dashboard                              # Context Manager (browser)
lean-ctx benchmark report .

• GIF の生成に使用したテープそのものが、demo/ に含まれています
• ローカルで再生成するには：

vhs demo/leanctx.tape
vhs demo/gain.tape
vhs demo/benchmark.tape

ベンチマーク

測定や推定には、明示されたワークロードと手法が必要です。以前の読み取りモードごとの圧縮テーブル（50 ファイルに対する map / signatures）は、BENCHMARKS.md に記載されたほかの過去の数値とともに撤回されました。代わりに、lean-ctx benchmark report . でご自身のリポジトリを測定してください。キャッシュ参照によってコンテキストの繰り返しを減らせます。トークンコストは、出力結果とトークナイザーによって異なります。

lean-ctx doctor overhead --gate を使って、Engine が公称するスキーマ、指示、ブリーフィングのオーバーヘッドを測定できます。決定論的な lean-ctx benchmark dual-arm --json のリプレイが示すのは合成上限値です。ベースラインではプロバイダーのプロンプトキャッシュを一切使用しませんが、エージェントのホストでは LeanCTX の有無にかかわらずプレフィックスをキャッシュできます。これはプロバイダーの請求額でも、オン／オフの比較でも、結果の品質評価でもありません。比較方法として、lean-ctx eval ab サブコマンド（--suite でスイートファイルを指定する必要があります）、lean-ctx eval footprint による注入コンテキストのフットプリント比較（--suite でスイートを、--compare でベースラインを指定する必要があります）、およびプロキシのオプトイン式圧縮ホールドアウト（[proxy] compression_holdout）を利用できます。

精度は、明示された制限の範囲内でゲートされています。モデル不要の A/B ゲートでは、JSON クラッシャーがフィクスチャ内のすべての正解を維持しつつトークンを削減すること、およびプロキシのリライトが同じ入力と設定のもとでプロンプトキャッシュの対象となる安定した出力を維持することを確認します。実際のキャッシュヒット、価格、割引はプロバイダーによって異なります。オフ対オンのテストベンチ（lean-ctx eval testbench）では、ピン留めされた実際のリポジトリを、生ダンプのベースラインと同一のトークン予算での lean-ctx の両方で実行します。自由形式の QA は LLM ジャッジで、コードは各リポジトリ独自のテストで評価し、FINDINGS.md（トークン数／ターン数／経過時間／品質）とリグレッションファイルを出力します。CI でリプレイされるのは、コミット済みの小規模な記録です。これはメカニズムのゲート（パイプラインの破損や評価結果の変化を検出するもの）であり、圧縮によって回答品質が維持される証拠ではありません。すべての評価レポートにはエビデンス階層（A：メカニズム……E：本番環境）が記載されます。ペアになったタスクが 30 件未満の実行は UNDERPOWERED となり、明示的な --mechanism チェックとして実行しない限り、--gate で失敗します。詳しくはcontext-quality-v1を参照してください。 品質に関する、十分な検出力を備えた使用有無の調査はまだ実施されていません。プロキシの圧縮ホールドアウトは、実際のトラフィックにおけるプロンプトサイズを測定し、回答品質は unknown と報告します。データパスごとに各数値から分かることと分からないことについては、測定範囲を参照してください。

• 最新のスナップショット：BENCHMARKS.md
• 再現方法：lean-ctx benchmark report .

導入と互換性

• GitHub の活動状況とリリースでは、現在のリポジトリ数とリリース履歴を確認できます。
• サポート対象の統合方法では、検証済みのセットアップとプロトコル互換性を区別しています。
• 生成された MCP レジストリでは、現在のツール数とステータスを確認できます。
• 公開メトリクスには測定範囲が記載されています。導入数だけでは、削減効果や結果の品質を立証できません。

ドキュメント

• リファレンス（ユーザージャーニー別の全機能）：docs/reference/ — 11 のジャーニーに加え、CLI／MCP／設定の付録
• AI エージェント／LLM 向け：llms.txt — llms.txt の規約に沿った、lean-ctx の厳選された機械可読マップ
• はじめに：https://leanctx.com/docs/getting-started
• ツールリファレンス：https://leanctx.com/docs/tools/
• CLI リファレンス：https://leanctx.com/docs/cli-reference/
• LeanCTX とは：https://leanctx.com/what-is-leanctx/
• 比較（RTK、Context+、MemGPT との比較）：https://leanctx.com/compare/
• コミュニティと商用オプション：https://leanctx.com/pricing/
• FAQ：discord-faq.md
• 機能カタログ（SSOT スナップショット）：LEANCTX_FEATURE_CATALOG.md
• モノレポガイド：docs/guides/monorepo.md
• セマンティックコードインテリジェンス：docs/guides/semantic-intelligence.md
• アーキテクチャ：ARCHITECTURE.md
• ビジョン：VISION.md

プライバシーとセキュリティ

• 確認可能なテレメトリー制御： lean-ctx telemetry status を実行すると有効な設定を確認でき、lean-ctx telemetry show でペイロードを確認できます。lean-ctx telemetry disable を実行すると報告が無効になります。
• 無効化可能な更新チェック（設定 update_check_disabled = true または LEAN_CTX_NO_UPDATE_CHECK=1）
• v3.5.16 で 40 件以上のセキュリティ強化修正（パストラバーサル、インジェクション、CSPRNG、CSP、リソース制限 — 詳細）
• Context Governance Benchmark 自己評価： 32 項目の制御を定める CGB v1.0-draft 仕様に照らして C2 — Managed と評価され、ギャップを公開しています — docs/compliance/cgb-self-assessment.md
• コンテキスト処理はローカルで実行されます。設定済みのソースプロバイダー、プロキシ／モデルへのリクエスト、送信されたフィードバック、更新、および有効化されたテレメトリーには、それぞれ独自のネットワーク経路があります。

SECURITY.md を参照してください。

アンインストール

1 つのコマンドですべてを削除できます。すべてのプロセスを停止してから、フック、 エディター設定、ルール、自動起動（LaunchAgent/systemd）、データディレクトリ、そして バイナリ自体を削除します。

lean-ctx uninstall                 # full clean removal
lean-ctx uninstall --dry-run       # preview every change, write nothing
lean-ctx uninstall --keep-config   # keep MCP configs + rules (for reinstall)
lean-ctx-off                       # or just disable for the current shell session

PATH にバイナリがない場合（または curl インストーラーを使用した場合）は、インストーラーから同じ削除処理を実行してください。

curl -fsSL https://leanctx.com/install.sh | sh -s -- --uninstall

パッケージマネージャー経由でインストールした場合、uninstall はインストール時に書き込まれたものをすべて削除し、バイナリの削除を完了するためのコマンドを案内します。

brew uninstall lean-ctx        # Homebrew
cargo uninstall lean-ctx       # cargo install
npm uninstall -g lean-ctx-bin  # npm

スター履歴

貢献

CONTRIBUTING.md から始めてください。最初の PR におすすめ： issue template を使って、新しい CLI 圧縮パターンを提案してください。

ライセンス

ライセンスは混在しています。Trust Core は Apache-2.0 のままですが、明示的に指定された v4 モジュールには、商用のソース公開型ライセンス条項が適用される場合があります。LICENSE.md と LICENSE_MATRIX.toml を参照してください。