lean-modeとは
lean-modeは、コーディングAgent向けのSKILL.mdです。目的は「コードを少なくすること」ではなく、Agentに明確な判断基準を与え、次の2つのエンジニアリング上の問いに答えられるようにすることです。
- 検証、
try/catch、抽象化レイヤー、フォールバック処理、追加のセキュリティサブシステムなど、一見安全なコードを書く価値があるか。 - 現在のビルドやテストがなぜ遅いのか、そして非効率な検証ループを合理的な範囲までどう短縮するか。
スキルファイルはskills/lean-mode/SKILL.mdにあり、標準的なfrontmatter、つまりname、description、Markdown本文で構成されています。特定のホストには依存せず、SKILL.mdの規約に対応するAgentであれば利用できます。
解決する中核的な問題
長時間のコーディングセッションでは、モデルは過剰な防御的プログラミングと非効率な検証ループという2種類の体系的な傾向を示しやすくなります。
過剰な防御的プログラミング
よくある例は、内部の信頼できるデータに対してnull検証を繰り返すこと、例外捕捉で根本原因を隠すこと、単一の実装に対して早い段階で抽象化を作ること、問題の原因を確認しないままフォールバックを追加し続けることです。コードの表面上はより「安全」になりますが、実際には保守コストを増やし、明確な失敗を追跡しにくいエラー値へ変えてしまう可能性があります。
非効率な検証ループ
よくある例は、完全ビルドを頻繁に実行すること、cleanを繰り返し使うこと、常駐プロセスを無効にすること、毎回すべてのテストを実行すること、明らかに停止しているコマンドを長時間待ち続けることです。lean-modeは、プロセスの再利用、増分実行、範囲の制御、実行順序、呼び出し頻度、タイムアウト管理という6種類のルールで、これらの行動を制約します。
READMEの定量データは、約20k行のJavaおよびGradleプロジェクトで行った1回の長時間セッションに基づくもので、問題が実際に存在することを示すためだけに使われています。モデルやプロジェクトをまたいだ業界標準とみなすべきではありません。
主な機能
- 信頼境界で1回だけ検証する：まず「このnullはどこから来たのか」に答えることを求め、信頼できるデータがシステムに入った後も何層にもわたって重複検証することを避けます。
- 根本原因を握りつぶさない：
catch後にnull、false、空のコレクション、ゼロ値を返す処理に注意します。これらは明確な例外を特定しにくいエラーへ変える可能性があります。 - 早すぎる抽象化を抑制する：実装が1つしかない場合や、将来的な置き換えの可能性だけを理由に作る抽象化は、本当に安定した拡張境界になるとは限りません。
- 根本原因の修正を優先する：フォールバックの追加は、根本原因がまだ完全には解決されていないことを意味します。本当に必要な場合は、問題の帰属、削除条件、確認済みの根拠を説明する必要があります。
- 変更量を動作の変化に合わせる：新しいコードが50行を超える場合は、総行数、検証とフォールバックが占める行数、それらのコードを書かない場合の実際のコストを先に報告します。
- 安全なコードを書く前に3つの問いに答える：問題は本当に発生するのか、発生したらユーザーはどうなるのか、書かない場合のコストは何か。どれか1つでも答えられない場合は、まずコードを追加しません。
- 検証ループを短縮する：Gradle、Maven、Go、NodeとTypeScript、Rust、Python、.NETという7種類のビルドシステムについて、最小限の検証方法をカバーします。
- 「変更不要」という結論を許容する：目標は問題を解決することであり、無理にコードを生成することではありません。ユーザーが求めていない領域までついでに強化すべきでもありません。
- 既存コードの監査手順を提供する：まず密度を定量化し、最も深刻なファイルを確認し、削除、上位への移動、維持を1件ずつ判断してから、変更前に結果表をユーザーへ提出します。
防御的コードについて、このスキルはJava、Go、TypeScript、Pythonの4言語で反例を提供し、Agentが異なる構文の背後にある同種の問題を識別できるようにします。
lean-modeのインストール
方法1：URLから取得する
Vantaloomのスキルページのように、ホストがURLからのスキルインポートに対応している場合は、リポジトリのアドレスを直接貼り付けられます。ホストはskills/lean-mode/の下にスキルファイルを見つけます。
https://github.com/Timefiles404/lean-mode-skill方法2：ワークスペースにコピーする
まずリポジトリをクローンし、スキルディレクトリをホストが定める場所へコピーします。Vantaloomのワークスペース規約を使う場合は、次を実行します。
git clone https://github.com/Timefiles404/lean-mode-skill.git
cp -r lean-mode-skill/skills/lean-mode <あなたのワークスペース>/.vantaloom/skills/ホストがClaude形式のスキルディレクトリを使う場合は、.claude/skills/へコピーします。
cp -r lean-mode-skill/skills/lean-mode <あなたのワークスペース>/.claude/skills/方法3：スキルを手動で作成する
ホスト上で新しいスキルを作成し、リポジトリ内のskills/lean-mode/SKILL.mdの完全な内容を貼り付けます。先頭のfrontmatterを省略しないでください。ホストはその中のdescriptionに基づいて、スキルをいつ読み込むか判断します。
基本的な使用フロー
インストール後、lean-modeは主に、必要に応じてスキルの説明をコンテキストへ取り込む仕組みに依存します。Agentが検証、例外捕捉、抽象化レイヤー、フォールバック、追加のセキュリティサブシステムを追加しようとするとき、または1回の作業中にビルドやテストを何度も実行したときに、スキルが呼び出されるべきです。
場面1：新しい検証が必要か判断する
- まずデータの出所を特定し、外部入力、インターフェース境界、その他の信頼できないソースから来たものか確認します。
- 同じ制約が信頼境界ですでに検証されていないか確認します。
- 問題が実際に起こり得るか、ユーザーにどのような影響があるか、検証を書かない場合のコストを検討します。
- データが内部に入った後ですでに信頼できるなら、同種のランタイム検証を何層にもわたって追加しません。
たとえばAgentが複数の内部メソッドにObjects.requireNonNullを繰り返し追加しようとした場合、「理論上nullになる可能性がある」という理由だけで追加すべきではありません。まずnullの実際の出所を追跡し、境界で検証がすでに完了しているか判断する必要があります。
場面2：例外を処理する
Agentが例外を捕捉してデフォルト値を返そうとするときは、その処理が根本原因を隠さないかを先に確認します。以下のパターンは重点的にレビューすべきものです。
catch (...) {
return false;
}重要なのは、すべての例外捕捉を禁止することではありません。特定可能な失敗を、コンテキストの不足したfalse、null、空の結果、ゼロ値へ変えないことです。業務上どうしてもデグレードが必要な場合は、スキルに記載された例外条件に基づいて評価します。
場面3：抽象化レイヤーを評価する
あるインターフェースに現在1つの実装しかなく、作成理由が「将来置き換える可能性がある」だけなら、Agentは立ち止まり、本当の変更境界を確認すべきです。lean-modeは抽象化そのものを否定するのではなく、現在の要件と安定した境界がない段階で間接層を先に作ることに反対します。
場面4：ビルドとテストを短縮する
- 既存のビルドプロセスを優先的に再利用し、必要のないコールドスタートの繰り返しを避けます。
- 増分生成物を保持し、習慣的に
cleanを実行しないでください。 - まずコンパイルだけ、関連モジュールだけのチェック、単一テストだけの実行など、最小限のコマンドを実行します。
- 最小限の検証に通過した後、モジュールテストや完全なテストへ段階的に範囲を広げます。
- 繰り返しの呼び出し頻度を制御し、コードに変更がない状態で同じコマンドを何度も実行しないようにします。
- 停止する可能性のあるコマンドには妥当なタイムアウトを設定し、失敗したら最初の根本原因を先に分析します。
READMEの完全なスキル本文では、7種類のビルドシステムについて「これだけを実行する」という最小検証ループを示しています。実際の使用時には、これらの例をプロジェクトで直接実行できる実際のコマンドに置き換えることを優先してください。
過剰に防御的なコードを監査する
lean-modeには、すでに大量の検証、フォールバック、例外を握りつぶすロジックが蓄積したプロジェクトに適した「まず測定してから削除する」監査手順が付属しています。
- 検索して定量化する：言語ごとに付録の検索パターンを使い、関連パターンの数と密度を集計します。
- 確認範囲を絞る：最初からリポジトリ全体を監査するのではなく、問題が最も集中している5ファイルだけを確認します。
- 1件ずつ分類する：各ロジックを「削除」「上位へ移動」「維持」に分類します。「上位へ移動」は通常、検証を本当の信頼境界に集約することを意味します。
- 報告してから変更する：まず監査表をユーザーに提示して選択してもらい、確認なしに大規模な削除を行わないでください。
- 分割して検証する：変更後は最小限のビルドとテスト範囲で検証し、結果に応じて範囲を広げます。
この手順では、観察可能で、選択でき、元に戻せることを重視します。「防御コードを減らす」ことを、再び制御不能な大規模リファクタリングに変えないためです。
SKILL.mdをカスタマイズする
SKILL.md自体はMarkdownなので、直接編集できます。特に価値の高いカスタマイズは次の3種類です。
プロジェクトの検証コマンドを置き換える
第7節の汎用コマンドを、現在のプロジェクトで実際に実行できる「コンパイルだけ」と「単一テストだけ」のコマンドに置き換えます。直接コピーして実行できるコマンドは、抽象的な原則よりもAgentの行動を制約しやすいものです。
検索パターンを調整する
プロジェクトのコードスタイルに合わせて、付録の検索ルールを変更します。たとえばJavaプロジェクトではGuavaのPreconditionsを使う場合もあれば、主にObjects.requireNonNullを使う場合もあります。検索パターンは実際のコードと一致させる必要があります。
基準密度を調整する
このスキルでは、200〜500行ごとに1つの検証が現れることを経験的な参考値としていますが、これは統一基準ではありません。パーサー、プロトコル境界、業務CRUDでは適切な検証密度が異なるため、ドメインのリスクとデータの出所に応じて調整してください。
高度な使用上の提案
- 例外もコンテキストに残す：スキルの判断基準はヒューリスティックなルールであり、定理ではありません。「検証しない」「catchしない」といった単純化された標語だけを残さないでください。
- Agentに変更の内訳を報告させる：追加が50行を超える場合は、総行数、検証とフォールバックの行数、それらのロジックを実装しない場合のコストを明確に説明させます。
- 検証範囲を段階的に広げる：関連ファイル、単一テスト、モジュールから開始し、その後より広いテスト範囲へ進みます。変更のたびに完全ビルドを起動することを避けます。
- 根拠でフォールバックを説明する：フォールバックを残す必要がある場合は、具体的な問題の出所、確認結果、将来削除する条件を記録します。「一部の環境ではエラーになる可能性がある」といった検証不能な表現は使わないでください。
- 「変更しない」を有効な結果にする：問題が既存のロジックですでに解決されている場合や、追加コードに明確なメリットがない場合は、Agentが変更不要と説明できるようにします。
能力の範囲と任意の補助機能
lean-modeが変えるのはモデルの傾向であり、モデルの能力ではありません。特定のコードを書くことをモデルに強制的にやめさせることはできず、適切なタイミングで判断基準をコンテキストに入れられるだけです。そのため有効ではありますが、保証を構成するものではありません。
また、静的解析ツールでもないため、コードを自動的に読み取ったりスキャンしたりすることはありません。付録の監査では、Agentが対応する検索コマンドを自分で実行し、結果に基づいて判断する必要があります。
任意で利用できるVantaloomの同名プラグインは、圧縮した規約を各ターンの動的コンテキストに継続的に追加し、ツール結果の末尾注記とlean_reviewツールを提供します。プラグインは継続的なリマインドを担当し、スキルは完全な判断基準を提供します。プラグインをインストールしなくても、このスキルは単独で利用できます。
プロジェクトのリポジトリは、GitHubのlean-mode-skillで確認できます。MITライセンスを採用しています。
まとめ
lean-modeの価値は、機械的にコードを減らすことではありません。各検証、例外処理、抽象化、フォールバック、検証コマンドについて、その理由を説明できるようにすることにあります。インストール後、プロジェクト固有のコマンド、検索パターン、リスク密度に合わせてカスタマイズすれば、コーディングAgentが根本原因により集中し、より短く信頼性の高いエンジニアリングのフィードバックループを構築する助けになります。