DecisionLint: Jev/Luna Lint

DecisionLint：Jev/Luna リント

送信前に、Jev と Luna の意思決定モデルに関する質問をリントします
JSON、JavaScript、TypeScript、Python、Rust、Go に対応し、TypeSafe、OpenAI、およびそれらを提供するすべてのプラットフォームで利用できます

役に立ちましたか？ 他の開発者に見つけてもらうには、スターまたは評価をお願いします — ★ GitHub · ★ Open VSX · ★ Marketplace

機能

送信前に、Jev と Luna に投げる質問をリントします。DecisionLint は、意思決定モデル向けに書いた質問をチェックします。対象は TypeSafe の Jev、OpenAI の Decisions API（gpt-6-luna）、そして OpenRouter や Vercel AI Gateway から手元の llama.cpp まで、どちらの形式にも対応するすべてのプラットフォームです。DecisionLint は JSON とコードから質問を読み取り、悪い回答につながる可能性が高い書き方の質問を報告します。リントでは API を呼び出さず、キーも必要ありません。オプションのコマンドを使えば、自分のキーで、ファイルを指定したプラットフォームに送信し、モデル自身にチェックさせることもできます。

• JSON、JavaScript、TypeScript、Python、Rust、Go で入力中にリントします。
• 機械的なミスは電球アイコンから修正でき、同意できない指摘を無視する方法もあります。
• CI、コマンドライン、MCP サーバー経由の AI エージェントで、同じルールを使用できます。 3 つすべてで同じ設定ファイルを使います。
• すべてのプラットフォームで、共通のルールセットを使用できます。 TypeSafe の /v1/systemone 形式と OpenAI の /v1/decisions 形式、predicate、choices、levels を同じルールでチェックします。また、AI SDK のどちらかの形式に対応する decide() 呼び出しも対象です。リクエストに適用される上限は、モデル ID の表記、ファイル内の URL、または target 設定から読み取る、そのプラットフォーム固有の値です。Vercel では 255 個の選択肢、LiteLLM では 128 個の質問が上限となり、プラットフォームが上限を公開していない場合は上限なしとなります。
• 自分のキーを使うオプションのコマンドが 2 つあります。 1 つは、テキストパターンでは見つけられない問題が質問にないかモデルに尋ねます。もう 1 つは、レイアウトを変えて質問を再送し、回答が変わらないかを確認します。どちらも、モデル ID が示すプラットフォーム、または指定したエンドポイントに送信します。ローカルの llama.cpp も指定できます。

次のようなリクエストは問題なさそうに見えますが、3 つの問題があります。

{
  "model": "jev-latest",
  "state": "My parcel came three days late and the lid is cracked.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": { "billing": "Charges and refunds", "delivery": "Late or damaged parcels" }
    },
    "late": { "type": "noul", "instructions": "Did more than two parcels arrive late?" }
  }
}

インストール

AI エージェントから使用する

同じプログラムがMCPサーバーでもあるため、Jev または OpenAI Decisions の質問を作成するエージェントは、作成した内容を lint して、表示される前に修正できます。ツールの説明とサーバーの指示には、両方のベンダー名と3種類すべてのリクエスト形式が記載されているため、エージェントはどの場合でもこのサーバーを呼び出すべきだと判断できます。

8つのツールを提供します。lint_text はテキストとして渡されたリクエストまたはソースコードを lint し、lint_paths はディスク上のファイルを lint します。どちらも各指摘に修正内容が含まれます。fix_text は安全な修正を適用したテキストと、残った問題のレポートを返します。書き込みは行いません。list_rules はすべてのルールとその意味を一覧表示し、explain_rule はルールのページと、指摘される例および指摘されない例を返します。これらは何も送信せず、キーも不要です。

残りの3つは、エージェント向けのエディターの Ask コマンドと Probe です。ask_model は Jev、または model: gpt-6-luna を指定した Luna に、テキスト内またはファイル内の質問の確認を依頼し、モデルの指摘を追加した lint レポートを返します。plan_ask は送信される内容を示しますが、何も送信しません。probe_question はレイアウトを変えて質問を1つ送信し、回答が維持されるかを報告します。送信を行う2つのツールはキーを使用し、費用が発生します。また、それらの説明には、ユーザーから依頼された場合にのみ呼び出すようエージェントに指示されています。キーは、クライアントがサーバーを起動した環境にある TYPESAFE_API_KEY または OPENAI_API_KEY、あるいはサーバーを起動したディレクトリ内の .env.local または .env から読み込まれます。ツールの引数から読み込まれることはないため、キーがエージェントの記録に残ることはありません。各ツールはテキストとともに構造化コンテンツを返し、ファイルへの書き込みは行いません。

MCP レジストリには io.github.nolindnaidoo/decisionlint として登録されています。レジストリからサーバーをインストールするクライアントで利用できます。

{
  "mcpServers": {
    "decisionlint": { "command": "npx", "args": ["-y", "decisionlint-mcp"] }
  }
}

検出できる問題

Jev と Luna が保証するのは回答の形式であり、回答そのものではありません。質問の形式が不適切でも、自信に満ちた数値が返ってくることがあります。これらのルールは、テキストから読み取れる誤りを検出します。

検査対象

• TypeSafe 形式または OpenAI 形式の JSON および JSONC のリクエスト本文。
• JavaScript および TypeScript のオブジェクトリテラル。client.systemOne(...) や client.decisions.create(...) にインラインで渡されたリクエスト、およびどちらのベンダーでも、モデル ID をモデルとして読み取る typeSafeAi.decisionModel('...') を含む Vercel AI SDK の decide({ questions }) も対象です。
• @typesafe-ai/sdk を使用するファイル内の noul()、choice()、score() 呼び出し。
• Python：typesafe_sdk の辞書、Noul(...)、Choice(...)、Score(...)、NoulCriteria(...) を持つ LangChain の langchain_typesafe、またはいずれかをラップするライブラリ内のこれらの呼び出し、および system_one(...) や client.decisions.create(...) に渡されるリクエスト。
• Rust：json! 内の JSON、質問タイプを名前に含む構造体や列挙型のバリアント、および ::noul(...) 形式のコンストラクター。
• Go：文字列キーを持つマップ、Type フィールドを持つ構造体、質問タイプを名前に含む構造体、および OpenAI の Go SDK の openai.DecisionNewParams{...} と、その OfPredicate、OfChoice、OfScore の質問。
• これらの言語のいずれかで、リクエストを JSON として文字列に貼り付けたもの。
• その他の言語：プログラムに送信するリクエストを .jev.json ファイルに書き出させて、それを開いてください。すべてのチェックはそのファイルに対して実行され、実行時に構築されるものはないため、検査が省略されることはありません。
• oxlint-plugin-jev の設定内の jev/ask ルール。

OpenAI の Decisions API

OpenAI の Decisions API では、モデル gpt-6-luna が Jev と同じ種類の質問を別の形式で行います。DecisionLint は 0.5.0 からこれを読み取ります。対象となる範囲は次のとおりです。

• 読み取り。 /v1/decisions のリクエスト本文、TypeScript および Python の client.decisions.create(...)、Vercel AI SDK の decide() が対象です。predicate は Noul として、choices: [{ value, description }] は Choice の選択肢として、levels: [{ label, description }] は Score のレベルとして読み取られ、同じルールが適用されます。
• チェック。 根拠のあるすべてのルールが対象です。フォールバックの選択肢の欠落、名前を繰り返すだけの説明、簡潔すぎる指示、程度を示すレベル、重複、数え上げ、未定義の境界などを検査します。指摘には Luna と表示されます。OpenAI 自身のガイドでも、同じことが求められています。
• 対象外。 DEC002 と DEC003 はプラットフォームが公開している上限をチェックしますが、OpenAI は上限を公開していないため、OpenAI 向けのリクエストにはどちらも適用されません。Vercel のように上限を公開しているゲートウェイ向けのリクエストには、両方が適用されます。DEC001 は変動する Jev のエイリアスに関するルールで、OpenAI にはモデル ID が 1 つあります。
• 形式の誤りは、OpenAI 独自のフィールド名で報告されます。choices がマップまたは名前だけで記述されている場合、Choice に choices がない場合、Score に levels がない場合などです。誤った predicate は電球アイコンから修正できます。形式を組み替える修正は Jev のみを対象とします。
• Luna に質問する。 OpenAI キーを設定し、Ask Luna About This File を実行するか、--ask-platform openai を指定します。方法は次のセクションで説明します。
• Jev で調整し、Luna で測定。 これらのルールのデフォルト値はすべて、その欠陥が jev-1.13.0 にもたらす影響を測定して設定されました。2026-10-16 にライブ API を通じて Luna でチェックを実行しました。Jev のしきい値では Luna の欠陥の大半を検出できますが、見逃しは増えるため、Luna でも同じしきい値を維持しています。Luna に問い合わせて得られた指摘にはすべて、しきい値が Jev で設定されたことが記されています。文言に関するルールが Luna にもたらす影響は、まだ測定されていません。

すべてのプラットフォーム

Jev と Luna はモデルのうちの 2 つで、TypeSafe と OpenAI はリクエストの送信先のうちの 2 つです。Microsoft、Liquid AI、Cloudflare は、TypeSafe の形式で独自のモデルを提供しています。OpenRouter、Vercel AI Gateway、LiteLLM、LLM Gateway は、どちらの形式でも、これらのいずれにも転送します。llama.cpp、vLLM、Ollaya は、オープンモデルをお使いのマシン上で実行します。DecisionLint は 2 つの形式を読み取るため、どのプラットフォームも同じルールで検査できます。それぞれの違いは、各情報の参照元ページとともに、1 つの表 src/lint/targets.ts にまとめられています。

この表から、次の 3 つのことが分かります。

• リクエストに適用される制限は、そのプラットフォームのものです。 プラットフォームは、モデル ID の表記から判別できる場合はその表記から、ファイル内の URL が示すプラットフォームから、またはすべてのリクエストを 1 か所に送るプロジェクトの場合は decisionlint.json の target または decisionlint.target から判別されます。制限を公開していないプラットフォームについては、その制限に関する指摘はありません。リクエストの送信先を示すものはありません。TypeSafe 形式の質問には TypeSafe の制限が適用され、それ以外の形式には制限が適用されません。
• 変動するエイリアスは、どの表記でも検出され、プラットフォームがドキュメントで指定する表記に固定されます。jev-latest は jev-1.13.0 に、~typesafe/jev-latest は typesafe/jev-1.13 に固定されます。
• モデルを使ったチェックは、ID が示すプラットフォームに、そのプラットフォームの環境変数にあるキーを使って送信されます。 すべてのゲートウェイが記述する openai/gpt-6-luna-decisions のように、どのホストも示さない表記は、推測せず、エンドポイントを設定するまで拒否されます。方法は次の 2 つのセクションで説明します。

「Open Jev」はこれらのいずれでもありません。これは、/v1/systemone を再実装した、少なくとも 9 つの無関係なプロジェクトで使われている名前です。llama.cpp が提供するものは ggml-org/OpenJev-GGUF です。それぞれ、設定したエンドポイントとしてアクセスします。

テスト済みのプラットフォーム

以下の各プラットフォームに対して、稼働中の API を通じて実際にリクエストを送信し、それぞれでキャリブレーションセット全体を使ってモデルベースのチェックを実行しました。

• TypeSafe の jev-1.13.0。カットオフの設定に使用しました。
• OpenRouter の typesafe/jev-1.13。TypeSafe と同じように応答するため、その指摘はキャリブレーション済みとして扱われます。
• LLM Gateway の jev-1.13.0 と、Vercel AI Gateway の typesafe-ai/jev。どちらも OpenAI 形式で送信されるため、Jev の回答に多少の違いが生じます。そのため、指摘にはカットオフが TypeSafe で設定されたことが示されます。
• OpenAI の gpt-6-luna と、Vercel AI Gateway の openai/gpt-6-luna-decisions。OpenAI と同じように応答します。
• Liquid AI の d1。

Luna と d1 には Jev のカットオフを適用します。どちらでも大半の欠陥を検出しますが、Jev より見逃しが多く、それらによるすべての指摘にはカットオフの設定元が示されます。docs/cutoffs.md には各カットオフと、各モデルで検出した既知の欠陥の数、誤って指摘した正常な質問の数、さらに各プラットフォームの回答が同じモデルの別の場所での回答からどの程度異なるかが記載されています。保存された実行結果に基づいているため、数値は実行結果そのものです。サンプル数は少ないため、参考値として扱ってください。LiteLLM、Eden AI、llama.cpp では、まだ実行していません。

ファイルについてモデルに尋ねる

ルール DEC301 から DEC312 はリンティングには含まれません。これらのルールは、いずれかの Ask コマンドを実行するか、コマンドラインで --ask を指定したときだけ実行されます。各コマンドはファイル内のすべての質問を意思決定モデルに送り、テキストパターンでは検出できない問題について確認します。たとえば、選択肢同士が重複している、選択肢の名前が説明と矛盾している、基準が別の内容を対象にしている、Choice にすべきではなく Score にすべき、2つの質問が同じことを尋ねている、別の質問への回答がないと答えられない、といった問題です。

各プラットフォームに専用のコマンドがあり、それぞれ異なるキーを使用します。

1. プラットフォームのキーを、3つの方法のいずれかで指定します。プラットフォームの ... API Key を設定 コマンドを実行し、キーを貼り付けます。キーはオペレーティングシステムのキーチェーンに保存されます。または、decisionlint.ask.keys の Settings でプラットフォームの ID を指定してキーを入力します。この設定はユーザー設定でのみ指定でき、Settings Sync から除外されます。または、VS Code が実行される環境で、プラットフォーム名に記載された環境変数にキーを設定します。
2. 質問を含むファイルを開き、プラットフォームの Ask コマンドを実行します。

各コマンドが送信するモデルは、プラットフォームごとに decisionlint.ask.models で指定します。TypeSafe のデフォルトはチェックのしきい値が設定されたバージョンです。他のモデル（Luna を含む）からの検出結果には、その旨が示されます。OpenRouter の typesafe/jev-1.13 は、そのバージョンと同等の応答をすることが測定されているため、検出結果にその旨は示されません。プローブは、TypeSafe のキーとモデルを使って、TypeSafe の Jev に質問します。

自分でホストするプラットフォームの場合、llama.cpp、vLLM、LiteLLM、または Ollaya を使う場合は、decisionlint.ask.endpoint にリッスンしている完全な URL を、decisionlint.ask.endpointModel に提供するモデルの ID を設定してください。パスが /systemone または /decisions で終わらない場合は、decisionlint.ask.endpointShape に typesafe または openai を設定します。その後、このファイルについて自分のエンドポイントのモデルに質問する を実行します。endpoint キーが設定されている場合はそれを送信します。設定されていない場合は、SDK が読み取るシェイプに応じて TYPESAFE_API_KEY または OPENAI_API_KEY のキーを送信します。どちらのキーもない場合はキーを送信しません。これがローカルの llama.cpp に接続する方法です。エンドポイントはユーザー設定でのみ指定できるため、リポジトリによってキーの送信先を任意のホストに指定されることはありません。

実行する前に知っておくこと：

• API キーを使い、クレジットを消費します。 質問ごとに 1 件、リクエスト本文ごとにさらに 1 件のリクエストが送信され、Jev ではそれぞれの入力トークンは約 800 個、Luna ではその 2 倍です。TypeSafe の公開価格では質問 1 件あたり数千分の 1 セント、OpenAI では 1〜2 セントの 100 分の 1 程度です。送信前に表示される件数は切り上げた推定値であり、プラットフォームの請求額とは異なる場合があります。
• 送信されるのは質問のみです：種類、指示、基準、ID です。decisionlint.ask.sendState を有効にしない限り、state は送信されません。有効にすると、ファイルに書き出された state も送信され、さらに 2 件のチェックが実行されます。state に各質問が尋ねている内容が含まれているか、また、読み手に指示を与えるテキストが含まれているかを確認します。
• 実行時に組み立てられる部分を含む質問は送信されません。 概要には、送信対象から除外された質問の数が表示されます。
• 1 回の実行で送信されるリクエストは、decisionlint.ask.maxCalls 件までです。デフォルトは 25 件です。
• 信頼されていないワークスペースでは無効です。 有効にするには、Workspaces: Manage Workspace Trust を実行してフォルダーを信頼します。
• ファイルを編集すると、検出結果は消えます。古いテキストに対する結果だからです。チェック中にファイルを編集するか閉じると、チェックは停止します。
• 各検出結果には、Jev が示した確率が表示されます。 数値が添えられた主張として扱い、判定として受け取らないでください。

decisionlint.ask.confirm を有効にすると、まず送信するリクエスト数、トークンのおおよその数、費用を知らせ、確認を待ちます。デフォルトでは無効です。コマンドの実行を、送信する判断とみなします。

質問を調査する

質問の中にカーソルを置き、DecisionLint: Probe the Jev Question at the Cursor を実行します。その質問を、隣に記述された state に対して、記述どおりに 3 回送信し、さらにレイアウトを変更して送信します。選択肢の順序を逆にする、選択肢名を隠す、レベルの順序を逆にする、基準を取り除く、といった変更を加えます。回答が変わったかどうかを示すレポートが開きます。

選択肢の順序だけを変えたときに回答が変わるなら、その質問では決定できていません。同一のリクエスト 3 件で回答が一致しない場合は、判定できるほど明確ではありません。

ファイルに state が記述されている必要があり、その state が送信されます。リクエストは 5〜6 件分の費用がかかります。

この拡張機能でネットワークを使う機能はほかにありません。コマンドラインでは、--ask のみがネットワークを使います。

プロジェクト設定

プロジェクトに decisionlint.json を置くと、エディターとコマンドラインの両方がそれを読み込みます。これにより、執筆中に確認できる内容と CI の報告内容が一致します。

{
  "rules": { "DEC004": "error", "DEC112": "off" },
  "fallbackOptions": ["other", "none", "unsure"],
  "ignore": ["DEC004:department"],
  "exclude": ["fixtures", "**/*.generated.ts"]
}

exclude には、リント対象から除外するファイルやフォルダーを、設定ファイルからの相対パスで指定します。** はフォルダーをまたぎ、* は 1 つのフォルダー内にとどまります。スラッシュを含まない名前は、どの階層でも一致します。エディターとコマンドラインでは、同じファイルが除外されます。

リント対象のファイルから上方向に探し、最も近いファイルが適用されるため、フォルダーごとに設定ファイルを置けます。設定ファイルが適用される場合、エディターの rules、fallbackOptions、ignore 設定は置き換えられます。読み取れない場合は何もリントされず、ステータスバーに理由が表示されます。不明なキーはエラーになるため、入力ミスによってルールがひそかに有効にならないことはありません。

検出結果を 1 件だけ非表示にするには、電球アイコンを使います。Disable DEC004 for this line または for this file を選ぶと、コメントが自動で書き込まれます。厳密な JSON にはコメントを記述できないため、検出結果を非表示にするには ignore を使います。

伝えられないこと

• 整形式の質問が、あなたのデータに対して正しいかどうか。 それを判断するには、ラベル付きの例と Jev への問い合わせが必要です。
• 確認できない値に関すること。 変数から作られた質問は読み取れないものとして報告され、ステータスバーに件数が表示されます。一部が読み取れなかったファイルを、問題なしとして表示することはありません。
• 表現に関するすべてのこと。 DEC101 から DEC112 は、英語のテキストに対するヒューリスティックです。ルールが有効になるのは、私たちの実行環境またはほかの人の環境で、質問の書き方が悪いために回答や Jev に対する信頼度が損なわれた場合だけです。また、調整に使っていない公開コードの検出結果のうち、少なくとも 10 件中 9 件で正しい場合に限り、有効なままになります。TypeSafe のドキュメントに記載された失敗モードを説明する 4 つのルール、DEC104、DEC107、DEC108、DEC111 は、jev-1.13.0 では失敗しなかったため、無効になっています。いずれかを有効にするには、decisionlint.rules で切り替えてください。さらに 2 つのルールは、検出のたびに誤りだったため、0.4.0 で削除されました。
• 英語以外の質問に関すること。
• 単独のオブジェクトに不足しているもの。 questions マップの外にある { type, instructions } は、テンプレートまたはビルダーの一部かもしれないため、criteria の不足はリクエスト内でのみ報告されます。

DEC004 は情報提供のみのルールです。根拠となる助言が条件付きだからです。選択肢がすべての入力を網羅しない可能性がある場合は、フォールバックを追加してください。TypeSafe 独自のドキュメントにある Choice の例 11 件中 9 件で検出されます。選択肢ですべてを網羅している場合は、その質問について無効にしてください。

検出結果の抑制

コード内では次のようにします。

// decisionlint-disable-next-line DEC004
const side = { type: 'choice', instructions: 'Heads or tails?', criteria: { heads: null, tails: null } };

decisionlint-disable-line は同じ行を対象とし、decisionlint-disable はファイル全体を対象とします。すべてのルールを抑制するには、コードを省略してください。

何も抑制しないコメントは DEC010 として報告されるため、検出結果を修正したあとに残したコメントが、後で新しい検出結果を隠すことはありません。

JevLint-LE 用に書かれたものも引き続き機能します。jevlint-le-disable コメントと、コメント、rules、ignore 内の JEV コードは、今後も読み取られます。すべての検出結果には DEC コードが記載されます。

修正

ユーザーの判断なしに修正できる検出結果もあります。たとえば、API が true を受け取る箇所に yes と書かれた Noul の criteria キー、誤記された質問タイプ、誤った形式の criteria などです。npx decisionlint --fix を実行すると修正され、実行結果のサマリーには修正対象の件数が表示されます。

エディターでは、保存時の修正も同じ処理を行います。

{ "editor.codeActionsOnSave": { "source.fixAll.decisionlint": "explicit" } }

フォールバックの選択肢を追加することと、モデルを固定することは、動作中のリクエストを変えてしまうため、自動で書き込まれることはありません。これらは電球メニューに表示されたままになります。

JSON にはコメントを記述できないため、設定を使用してください。

{ "decisionlint.ignore": ["DEC004:side"] }

CLI

エディター以外でも、CI や VS Code 以外のエディターで同じ lint を実行できます。

エディターと CI で同じバージョンを使う

ほかのリンターと同じように、プロジェクトにインストールしてください。

npm install --save-dev decisionlint

エディターは拡張機能に同梱されたコピーではなく、プロジェクト内のコピーを使って lint を実行します。そのため、入力中に表示される内容は、CI で npx decisionlint を実行したときの結果と同じになります。バージョンは package.json に応じて変更され、全員に一度に適用されます。プロジェクト内のコピーが使用されている間、ステータスバーには project 0.5.2 と表示されます。

何もインストールされていない場合、拡張機能は設定不要で独自のコピーを使って lint を実行します。

次の場合も、拡張機能は独自のコピーを使用します。理由はツールチップに表示され、ステータスバーには project has 0.2.0 と表示されます。

• コピーの読み込みでコードが実行されるため、ワークスペースが信頼されていない
• エディターが読み込める最初のバージョンである 0.3.0 より、コピーのバージョンが古い
• コピーの読み込みに失敗する、またはその種類のファイルを読み取れない

コピーの package.json を読み取れない場合、表示するバージョンがないため、ステータスバーには project copy unreadable と表示されます。この場合も、理由はツールチップに表示されます。

Ask コマンドとプローブは、プロジェクトに何がインストールされていても、常に拡張機能独自のコードを実行します。

npx decisionlint src/                 # a directory, searched for files it reads
npx decisionlint request.jev.json     # one file
npx decisionlint --format github .    # annotations on a pull request

実行が成功した場合は 0、検出結果によって失敗した場合は 1、指定された処理を実行できなかった場合（不明なオプション、パスの指定漏れ、読み取る対象がない場合）は 2 を返します。エラーがあると実行は必ず失敗します。警告は --max-warnings を超えた場合にのみ失敗の原因になります。

サマリー行には、全文を読み取れなかった質問の数、サイズが大きいためスキップしたファイル、読み取れなかったフォルダーまたはファイルが必ず示されます。リンクされたフォルダーはたどりません。--ask を指定しない限り、Jev に問い合わせるチェックは実行せず、ネットワークも使用しません。

CI とコミット前

GitHub では、このアクションがプルリクエストに注釈を付けます。

- uses: nolindnaidoo/[email protected]
  with:
    paths: src

GitHub のコードスキャンでは、SARIF を出力してアップロードします。

- run: npx decisionlint --format sarif src > decisionlint.sarif
  continue-on-error: true
- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: decisionlint.sarif

--format junit は、Jenkins、GitLab、および多くのテストレポーターが読み取る XML を出力します。実行を失敗させるのはエラーのみであるため、ここで失敗ケースとなるのもエラーのみです。

pre-commit との併用：

- repo: https://github.com/nolindnaidoo/decisionlint
  rev: v1.0.1
  hooks:
    - id: decisionlint

モデルに質問する

--ask は、lint の後に判定モデルへ質問するチェック（DEC301 から DEC312）を実行します。ネットワークを使用する唯一のオプションであり、設定ファイルで有効にすることはできません。

npx decisionlint --ask-plan src/                    # what it would send. No key, nothing sent
TYPESAFE_API_KEY=... npx decisionlint --ask src/    # send it

• --ask-platform は送信先を指定します。typesafe、openai、openrouter、vercel、llmgateway、liquid のいずれかを指定でき、それぞれに固有の表記によるデフォルトモデルと、対応するキー変数（TYPESAFE_API_KEY、OPENAI_API_KEY、OPENROUTER_API_KEY、AI_GATEWAY_API_KEY、LLM_GATEWAY_API_KEY、LIQUID_API_KEY）があります。指定しない場合、プラットフォーム固有の表記を使った --ask-model の値、OpenRouter の場合は ~typesafe/jev-latest を指定すると、そのプラットフォームに送信されます。単独の ID を指定した場合は、そのベンダーに送信されます。キーは指定された変数からのみ読み取られ、表示されることはありません。
• --ask-endpoint または DECISIONLINT_ASK_ENDPOINT を指定すると、自分でホストするプラットフォームに送信できます。パスから形式を判別できない場合は、--ask-shape も指定します。openai/gpt-6-luna-decisions のようにホストを特定できない表記は、これらを指定しない限り拒否され、何も送信されません。
• 実行時に組み立てられる部分を含む質問は送信されません。サマリーには保留された質問の数が表示されます。
• --ask-send-state を追加しない限り、状態は送信されません。
• --ask-max-calls は実行全体の上限です。上限を超える場合、実行は終了コード 2 で終了します。そのため、プロジェクトの一部だけをチェックした状態でジョブが成功することはありません。
• キーが拒否された場合、リクエストが失敗した場合、または実行を中止した場合も、終了コード 2 で終了します。また、予定していたリクエスト数のうち、何件の回答を得たかが表示されます。
• これらの検出結果はデフォルトでは警告以下であるため、--rule で重大度を引き上げるか、--max-warnings を指定した場合にのみ実行が失敗します。

コマンド

すべてのコマンドにショートカットを割り当てることができます。Keyboard Shortcuts を開いて DecisionLint を検索し、一覧の任意のコマンドで割り当てたいキーを押してください。初期状態ではどのコマンドにも割り当てられていないため、現在使用中のショートカットと競合することはありません。

または、keybindings.json に記述することもできます。以下のキーは一例です。

[
  { "key": "ctrl+alt+j", "command": "decisionlint.lintFile", "when": "editorTextFocus" },
  { "key": "ctrl+alt+k", "command": "decisionlint.askJev", "when": "editorTextFocus" }
]

Ask コマンドとプローブはキーを使ってリクエストを送信するため、誤って押さないキーを割り当ててください。

設定

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

• Lint はネットワークを使用しません。 拡張機能、コマンドライン、MCP サーバーはキーなしで lint を実行し、何も送信しません。テレメトリーも収集しません。
• プラットフォームに接続するのは Ask コマンド、probe、--ask、および送信を行う2つの MCP ツールだけです。 キーを使って接続し、実行した場合にのみ接続します。decisionlint.ask.sendState または --ask-send-state を有効にしない限り、送信するのは質問のみで、state は送信しません。probe は質問の横に記述された状態を送信します。
• キーはリポジトリに保存されません。 Set ... API Key コマンドは、オペレーティングシステムのキーチェーンにキーを保存します。decisionlint.ask.keys と decisionlint.ask.endpoint はユーザー設定でのみ設定でき、Settings Sync の対象外です。そのため、リポジトリが任意のホストにキーを送るよう指定することはできません。コマンドラインは環境変数からのみキーを読み取り、キーを表示することはありません。
• 信頼されていないワークスペースからは送信できません。 Ask コマンドは無効になり、プロジェクト独自のリンターも読み込まれません。リンターを読み込むとワークスペース内のコードが実行されるためです。
• MCP サーバーは何も書き込みません。 キーはクライアントが MCP サーバーを起動した環境、または MCP サーバーのディレクトリにある .env.local や .env から読み取り、ツールの引数からは読み取りません。そのため、エージェントのトランスクリプトにキーが記録されることはありません。

ドキュメント

開発

bun install
bun run typecheck && bun run lint && bun run test
bun run build
bun run test:integration   # real VS Code against samples/
bun run package            # release/decisionlint-<version>.vsix
bun run test:e2e-vsix      # the packaged VSIX in a clean profile

AGENTS.md はエンジニアリング標準です。SPEC.md には製品の概要と今後の予定が記載されています。samples/ は、実際の VS Code を操作する bun run test:integration で使う、意図的に誤りを含めたワークスペースです。

LE ファミリーのその他のツール

あらゆるモデルが作業する際に使える、16 個の単機能ツールです。それぞれに Rust CLI と MCP サーバーが付属します。詳細はこちら：letools.dev

取り出す

• String-LE — コードベース内のすべての文字列を抽出し、人が読めるようにします
• Numbers-LE — コードベース内のハードコードされた数値をすべて抽出し、人が確認できるようにします
• Units-LE — 単位付きのすべての数量を正規化して抽出し、曖昧なものは名前を示して除外します
• Dates-LE — すべての日付とタイムスタンプ、およびそれぞれが解決される正確な時点を抽出します
• IDs-LE — すべての UUID、ULID、NanoID、ObjectId、Snowflake を抽出し、内部の時刻をデコードします
• IPs-LE — すべての IP アドレス、CIDR ブロック、MAC アドレスを正規化して抽出し、スコープごとに分類します
• URLs-LE — コードベース内のすべての URL を、プロトコルと正確な位置とともに抽出します
• Paths-LE — コードベース内のすべてのファイルパスを抽出し、現在も何かを指しているかどうかを示します
• Colors-LE — コードベース内のすべての色を抽出し、パレットに含まれていない色を示します

チェックする

• Regex-LE — コードベース内のすべての正規表現を見つけ、壊滅的なバックトラッキングを引き起こす可能性があるものを報告します
• Versions-LE — リポジトリ内のマニフェストで、依存関係のバージョン指定が異なる箇所を見つけます
• i18n-LE — プロジェクトが使用している i18n ライブラリを特定し、そのライブラリのルールに従ってカタログを監査します
• Scrape-LE — スクレイパーを作成する前にページをスクレイピングできるか確認し、判定できない場合はその旨を示します

保護する

• Secrets-LE — コードベース内のハードコードされた認証情報を見つけ、レポートには決して出力しません
• EnvSync-LE — ツリー内の dotenv ファイルを比較し、どのファイルにどのキーが欠けているかを示します
• Unicode-LE — 意味を隠す Unicode、つまり双方向制御文字、不可視文字、同形異字、混在スクリプトを見つけます

各ツールは単独で機能します。共有クレートも、公開されたコアもありません。2 つのツールが同じ結果を出すのは、どちらも正しい答えを出したためです。

お問い合わせ — nolindnaidoo.com · GitHub · LinkedIn

nolindnaidoo によるその他のプロジェクト

Rust — pixelcoords と pixelactions はひとつのループを構成します。pixelcoords が 場所 を答え、pixelactions がそこで 操作 します。それぞれ独自のツールと独自の役割を持ち、LE ファミリーには属しません。

• pixelcoords — 画面を固定し、領域に印を付け、ピクセル単位で正確な座標と切り抜きを取得します pixelcoords.dev · crates.io · docs.rs
• pixelactions — 人間が検証した座標を受け取り、操作を実行して、正しく反映されたことを確認します pixelactions.dev · crates.io · docs.rs

ライセンス

MIT © nolindnaidoo