ljos

ljos

コーディングエージェントにルールを一度伝えれば、関連するプロンプトのたびにそのルールが適用され、違反するコマンドはフックによって拒否されます。

コーディングエージェントはセッションが終わると学習したことを忘れ、選んだシェルコマンドを何でも実行してしまいます。ljos は、どちらの問題も自分のマシン上で解決します。エージェントに伝えた内容をローカルストアに保存し、モデルが各プロンプトを読む前に、関連するメモを渡します。各シェルコマンドを、コマンドの実行前にユーザーのルールおよび組み込みの破壊的コマンドリストと照合します。エージェント独自のフックおよび MCP 設定を通じて連携します。リモートジャッジを有効にしない限り、マシンの外にデータが出ることはありません。

Claude Code、Codex、Cursor、GitHub Copilot CLI、Gemini CLI、Windsurf、Factory の Droid、Kiro、Qwen Code、Crush、Auggie、Amp、goose、OpenHands、Grok Build、opencode、omp、および Antigravity の agy で、拒否されたコマンドをブロックします。Cline のフックもインストールされますが、フックの失敗によってコマンドがブロックされるかどうかは、上流のドキュメントにまだ記載されていません。 Zed、VS Code、Claude Desktop、Continue、Roo Code、Kilo Code、hermes、Amazon Q では、MCP 経由でメモリー、スキル、ツールを提供します。

5 分で始める

curl -fsSLO https://github.com/leidarljos/ljos/releases/latest/download/install.sh && sh install.sh
export PATH="$HOME/.local/bin:$PATH"
ljos prefer "Push a tag with git push origin TAG; --follow-tags skips lightweight tags."
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."

プログラムは ~/.local/bin に配置され、export の行によって、貼り付けたシェルの PATH にそのディレクトリが追加されます。次回のリリース以降、~/.local/bin が PATH にない場合、インストーラーはその行を ~/.profile と ~/.bashrc にも追加し、~/.zshrc が存在する場合はそこにも追加します。これにより、新しいシェルで ljos が見つかるようになります。--no-modify-path を指定すると、これらのファイルは変更されません。

インストーラーは各プログラムを GitHub リリースからダウンロードし、公開されている SHA-256 ハッシュと照合します。リリースがないプラットフォームでは、cargo でソースからビルドします。その後、見つかったすべてのコーディングエージェントに対して ljos onboard を実行します。エージェントが見つからない場合も、トラッカー、メモリーライター、deed ストアはセットアップされ、後で実行するための ljos onboard --harness NAME が案内されます。ガードが force push の前に確認を求める様子も表示されます。プログラムには、ljos、packset（メモリー）、vissue（トラッカー）、deedar（作業記録）、claimdag（誰が何に取り組んでいるか）、ljos-policyd（コマンドチェック）、ljos-consensus（投票）に加え、意味ベース検索用のエンコーダーである packset-embed が含まれます。 --no-embed を指定するとエンコーダーはインストールされません。この場合、検索は単語のみを照合するため、メモリーと単語が一つも共通しない言い換えは見つかりません。プラットフォーム用のエンコーダービルドがない場合、インストーラーは警告を表示して続行します。--with-embed も引き続き受け付けますが、何も変更しません。ljos doctor を実行すると、不足している部分が表示されます。 --version 0.29.0 を指定すると最新ではなく、その ljos リリースがインストールされます。--pin packset=0.14.0 を指定すると、別のリポジトリを特定のバージョンに固定できます。固定したバージョンにそのプラットフォーム向けのリリースがない場合は、そのバージョンのクレートがビルドされ、新しいバージョンが使われることはありません。 インストーラーは各 tarball の GitHub ビルド証明書も確認します。確認には gh 2.49 以降、または cosign が必要です。結果は 1 行にまとめて表示されます。--attest を指定すると、証明書がない場合や検証に失敗した場合にインストールが停止します。 packset、deedar、consensus には次回のリリースでビルド証明書が追加されます。それまでは、サマリーでそれぞれが未公開として表示されます。 デスクトップパネルの ljos-hud は任意で、doctor では info として表示されます。 phronesis なしでビルドした ljos-policyd は、独自のテーブルのみでコマンドをチェックします。doctor では、ポリシーの行が warn と表示されます。 ソースからのビルド（cargo install、またはリリース tarball がないプラットフォームでの binstall）には Rust 1.89 以降が必要です。使用中のバージョンは rustc --version で確認でき、rustup update stable で最新版を取得できます。 古い Rust では複数のクレートでエラーが発生します。また、0.5.0 より古い ljos-policyd が何の表示もなくインストールされることがあります。その場合、doctor は該当する行を no と表示し、修正方法を案内します。

0.29.0 以降の各 ljos リリースには、install.sh としてスクリプトが添付されています。 実行する前にスクリプトを確認してください。このリポジトリの scripts/install.sh にあります。手動でインストールするには、次を実行します。

cargo binstall --locked ljos packset vissue-cli vissue-mcp deedar-cli claimdag-cli ljos-policyd ljos-consensus   # or: cargo install --locked, same list
ljos onboard                                # every coding tool found on this machine: MCP server, hooks and skill
ljos prefer "Push a tag with git push origin TAG; --follow-tags skips lightweight tags."
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."

--harness には claude、codex、grok、cursor、antigravity、 opencode、omp、hermes、windsurf、zed、vscode、claude-desktop、 gemini、amazonq、kiro、copilot、factory、qwen、crush、cline、 auggie、amp、goose、openhands、continue、roo、kiloを指定できます。 Cursor の IDE とその agent CLI は、~/.cursor/mcp.json を共有します。 新しいマシンでは、ljos cloud up または sh scripts/install.sh --cloud を実行します。 どちらも次のリリースに含まれますが、上記のインストールコマンドが取得するリリースには、どちらも含まれていません。 それまでは develop から利用できます。チェックアウトした develop で sh scripts/install.sh --cloud を実行してください。インストール済みの ljos に cloud up がない場合、スクリプトは cargo でそのツリーをビルドします。 バイナリは ~/.local/bin に配置され、~/.cursor/mcp.json は PATH 上の ljos-mcp を指定します。また、LJOS_TRACKER_REMOTE は共有トラッカーとしてクローンされます。環境ファイル、プッシュモード、ジョブのステップについては docs/cloud-vm.md を参照してください。 Codex でフックが実行されるのは、信頼した後です。ljos onboard の後、Codex で /hooks を開き、ガードが実行される前に各 ljos フックを信頼してください。また、アップグレードによってフックが書き換えられた後にも、再度信頼してください。それまでは rm、 git、find のシムだけが Codex のコマンドをガードします。ljos doctor は、信頼されていないフックを確認できる場合に報告します。

新しいセッションを開始し、リリースへのタグ付けなど、設定の好みに関係することを尋ねてください。モデルがプロンプトを読む前に、フックが次の内容を追加します。

Remembered, oldest first (`ljos search` for more):
- [preference, today] Push a tag with git push origin TAG; --follow-tags skips lightweight tags.

ランナーの JSON を介さず、ターミナルで同じテキストを読むには、次を実行します。 echo "how do I push the v0.32.0 tag?" | ljos hook --prompt --text。

その後、エージェントが git push --force origin main を実行しようとすると、ランナーは実行前に確認を求めます。ljos-policyd は、まず同梱のルールに基づいて応答します。また、main、master、develop、または保護されたブランチに対する --force-with-lease でも、同様に確認を求めます。

{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"ask","permissionDecisionReason":"git-force-push: it rewrites shared history, so the agent asks you first (ljos rule `git-force-push`)"}}

sh -c "cd repo && git push -f origin main" にも、同じ応答が返されます。terraform destroy -auto-approve のように、自分のルールだけが適用されるコマンドには、そのルールが適用されます。

{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Destroy only from the release runbook. (ljos rule `terraform destroy*`)"}}

フックは、書き込んだ瞬間から自分が作成した内容を表示します。設定の好み（ljos prefer）、ルール（ljos rule）、ljos remember で自分が入力した教訓です。エージェントが ljos finish で提案した教訓は、自分のターミナルで ljos accept ID を実行するまで表示されません。実行すると、これもすぐに表示されます。エージェントがランナー内から実行した ljos remember はエピソードです。プロンプトがその内容に関係するときにフックが表示し、レビューによって恒常的な教訓に昇格されるまで、ljos due に表示されます。

会話が課題に紐付くと、フックは作業をトラッカーに記録するよう促します。席に向けた発言がないままツール呼び出しが40回続くと、作業を記録するようリマインドします。環境または ~/.config/ljos/env に LJOS_TRACK_WORK=on が設定されている場合、課題のない会話では、最初のツール結果で vissue q を使って課題を開き、その席に着くよう指示されます。また、ツールを使ったのに席に一度も触れなかった場合、Stop によってそのターンが一度ブロックされます。これが設定されていない場合、席に着かない会話にはトラッカーについて何も通知されません。ljos が対応する形式のうち、grok と antigravity は Stop を登録します。claude または codex の場合は、そのランナーの hook_events に Stop を追加してください（~/.config/ljos/harnesses.toml）。

得られるもの

• プロンプトごとのメモリー：メモリー1件につき主張は1つで、プロンプトを使って検索します。主張がエージェントに届くのは、プロンプトと共通する語句がある場合、または判定役がプロンプトに関係すると確信した場合だけです。教訓は見直しのタイミングで再び提示され、誤った主張は編集するのではなく、新しい主張で置き換えます。
• トラッカー vissue：Git リポジトリ内のプレーンな org ファイルです。ljos sitting ISSUE で作業を開始して担当し、ljos finish ISSUE --lesson "..." で一連の作業を完了して、得られた教訓を記録します。ljos accept ID でその教訓を書き込み、受け入れを記録します。
• シェルコマンドのチェック機能：ljos-policyd に組み込まれた拒否ルール（強制プッシュ、一時ディレクトリ外での rm -rf、git reset --hard、env、timeout、xargs などのラッパーを通した読み取りなど）と、パック内の独自ルール（ljos rule）を、コマンドを実行する各行で適用します。さらに、エージェントがチェック機能自体のバイナリやフックファイルを書き換えるのを防ぐガードも備えています。通常のブランチへの git push は、指定されたリモートや、その所有者を読み取れるかどうかにかかわらず許可されます。git push -u origin BRANCH も同様です。タグのプッシュもブランチのプッシュと同じように実行されます。強制プッシュ（--force、-f、+refspec）、リモートブランチまたはタグの削除、--mirror は、独自ルールの有無にかかわらず、デフォルトで確認を求めます。--force-with-lease によるプッシュは、--force-if-includes の有無にかかわらず、main、master、develop、またはチェックアウトで保護されているブランチ（ljos.toml または .ljos/gates.toml の protected_branches）への場合は確認を求め、それ以外のブランチへの場合は実行されます。refspec の指定がない場合、ガードは現在のブランチの upstream を読み取り、判定できないときは確認を求めます。 ルールを設定した場合、git push* のように範囲が広すぎるパターンは拒否されます。
• 複数の妥当な答えがある判断は、それぞれ独自の視点を持つ投票者であるペルソナに委ねます。結果から学習する、信頼度を重み付けした合意形成によって決定します。ペルソナは、保持するランナーセッションで推論できます。
• 実績（deedar）：作業によって何が生み出されたかを記録したコンテンツアドレス方式の記録で、チケットに引用されます。

用語

用語	意味
seat	1台のマシン上で、メモリーと主張を持つ1つのエージェントランナー
pack	メモリーストア（packset）。1つのアトムにつき主張は1つ
sitting	1つのチケット上の作業。ljos sitting で開始し、ljos finish で終了します
island	タイトルによって呼び出されるメモリーと、それらの間のリンク
deed	作業によって何が生み出されたかを記録した署名付きの記録
card	人が凍結したファイル。エージェントはこれを読み取りますが、書き込みはしません
persona	視点と基準点を持ち、専門分野について意見を述べる投票者

2つの動詞で回るループ

ljos sitting ISSUE [--playbook NAME] はセッションを開始します。プロトコルの順序で手順を実行し、応答しない最初のストアで停止します。doctor、cards、review clock、issue のタイトルによって有効になる island、playbook、working set、timeline、claim の順です。記憶を呼び出す前に playbook がコピーされます。--playbook を指定しない場合、セッションでは、すでに紐付けられている名前、次にタイトル内のクローズドセットトークン、最後に sit の順で名前を取得します。playbook 名は、完了または解放されるまでトラッカーノートとして保持され、名前が紐付けられるまでは ljos panel を実行できません。 セッションでは、ljos の準備ができているか、何に対応が必要か、このタスクについてセッションが何を記憶しているか、そして claim を簡潔なレポートとして表示します。 --verbose を指定すると、すべてのセクションが完全な形で表示されます。

ljos finish ISSUE --lesson "..." [--outcome OPTION] はセッションを終了します。lesson は L0（derived）の提案として登録され、origin は agent-derived になります。ljos accept はそれを explicit に昇格させ、恒久的な lesson として書き込み、その人が承認したことを記録します。エージェントランナーの配下では、別の会話（ワーカーなど）が提出した提案だけを承認できるため、エージェントは自分自身の提案を承認できません。エージェントランナーを介さず、自分のターミナルで ljos finish に lesson を入力した場合は、ただちに自分のものとして書き込まれます。ljos accept、ljos forget、ljos graded では、ID の先頭8文字を指定します。island が実行され、セッションノードが完了し、名前付きの outcome により、反証された投票者の重みが小さくなります。ljos remember で入力した lesson は user-declared のまま保持され、同じ文言によって未解決の提案が満たされます。--close を指定しない限りチケットはオープンのままで、--close を指定した場合も、作業が承認されたときにのみチケットが閉じられます。ループは毎回の finish で実行されるため、誰かが要求するかどうかにかかわらず、セッションは記憶します。

トラッカーが Git のチェックアウトである場合、claim と finish のそれぞれで、チケットの issues.org（そのファイルのみ）をコミットしてプッシュするため、別のホストからも両方を確認できます。LJOS_TRACKER_GIT=commit にするとローカルに保持され、off にするとスキップされます。.ljos/sync.toml で同期スコープを指定しているトラッカーでは、finish ごとにこのマシンのメモリも同期されます。age でそのファイルに記載された受信者向けに暗号化され、.ljos/atoms/<host>.jsonl.age としてコミットされ、ブランチとともにプッシュされます。このコミットとプッシュにも LJOS_TRACKER_GIT が適用されます。=push はコミットし、issue ごとのフィールドマージでリベースしてからプッシュします。プッシュに失敗した場合は、次の書き込み時とセッション終了時までキューに残ります。=commit は暗号化されたログをコミットしますが、取得もプッシュもしません。.ljos/sync.toml がないトラッカーは同期されません。ljos doctor は origin にないコミット数を数え、プッシュされていないコミットが残っている間は警告します。

Claude Code プラグイン

このプラグインには、ツールサーバー（ljos-mcp）、スキル（セッションプロトコル、セットアップ、記憶、セッション、提出、意思決定、メール）、セッション、finish、remember、doctor コマンド、panelist エージェント、および ljos onboard --harness claude が登録するフックが含まれています。マーケットプレイスファイルはこのリポジトリにあり、同じツリーが以下の Cursor プラグインでも使われます。

claude plugin marketplace add leidarljos/ljos
claude plugin install ljos@leidarljos
claude plugin install vissue@leidarljos

ljos@leidarljos はこのリポジトリです。vissue@leidarljos は leidarljos/vissue から取得されるトラッカーサーバーです。ljos、ljos-mcp、vissue-mcp は PATH 上に置きます。「5分で完了」の install.sh の行を使うと、これらに加えて packset、deedar、claimdag、consensus、ljos-policyd が ~/.local/bin に配置されます。プラグインはこれらのバイナリを実行し、~/.cargo/bin と ~/.local/bin も検索します。新しいセッションを開始してください。/ljos:sitting ISSUE でセッションを開始し、/ljos:finish ISSUE --lesson "..." で終了します。チェックアウト内で claude plugin validate . を実行するとマーケットプレイスを検証し、claude plugin validate .claude-plugin/plugin.json を実行するとプラグインを検証します。警告がある場合に失敗させるには、--strict を渡してください。

Cursor プラグイン

このリポジトリは Cursor プラグインでもあります。Cursor のエージェントに ljos メモリー、コマンドガード、ljos_* ツール、上記のスキル、それらを使用するようエージェントに指示するルール、および 4 つのコマンド（/sitting、/finish、/remember、/doctor）を提供します。

最初にプログラムをインストールして（Five minutes の install.sh の行を参照）、Cursor のエージェントチャットで次のように入力します。

/add-plugin leidarljos/ljos

この方法で追加したプラグインは、最初に取得したコミットに Cursor が固定します。更新を取り込むには、代わりに Cursor のローカルプラグインフォルダーにクローンを配置して、プルしてください。

git clone https://github.com/leidarljos/ljos ~/.cursor/plugins/local/ljos

次に、ウィンドウを再読み込みします。Cursor は、そのフォルダー内を指している場合に限り、フォルダー内のシンボリックリンクを読み込むため、リンクではなくクローンしてください。

フックは、ljos onboard --harness cursor と同じ ljos hook を実行します。そのうちの 2 つ（beforeShellExecution と preToolUse）は、コマンドの実行前に各コマンドを確認します。3 つ目の beforeSubmitPrompt は、シートが把握している情報を検索します。Cursor はプロンプトフックのテキストをモデルに渡さないため、そのメモは次のツール結果とともにエージェントに届きます。プラグインがインストールされている場合、ljos onboard はそれを認識して Cursor をプラグインに任せるため、フックが二重に登録されることはありません。プログラムが見つからない場合、フックはインストール方法を案内してコマンドの実行を許可し、ljos-setup スキルがエージェントのインストールを支援します。

チャットでのコマンド承認

Grok Build と Claude では、ask ルールがランナー独自の許可プロンプトとして表示されます。フックは ask と応答し、そのプロンプトで承認するとコマンドが実行されます。

ネイティブのフックプロンプトに対応していないクライアントでは、ask ルールによってリクエスト ID が返されます。その ID を指定して MCP ツール ljos_request_approval を呼び出してください。MCP フォームのエリシテーションに対応したクライアントでは、正確なコマンド、ディレクトリ、会話、ルールが表示されます。Allow this command once を選択してフォームを承認すると、1 回の再試行が許可されます。許可は、リクエストの作成から 15 分後に期限切れになります。

拒否する、閉じる、チェックボックスをオフのままにする、またはクライアントエラーが発生した場合、許可は付与されません。このツールは引数として承認フラグを受け取りません。コマンド、ディレクトリ、会話、またはルールが異なる場合、それぞれに個別の承認が必要です。また、拒否ルールは引き続き適用されます。

フォームのエリシテーションに対応していないクライアントでは、この会話で approve REQUEST_ID と返信するか、自分のターミナルで ljos approve REQUEST_ID を実行してください。ターミナルコマンドはコーディングランナー内での実行を拒否し、シートのガードはエージェントが実行するコマンド内での実行を拒否します。その ID を指定しないチャットメッセージでは、許可は付与されません。

クライアントはツールを使用する前に読み込む必要があります。そのため、ljos_request_approval がないバージョンからアップグレードした後は再接続してください。他の呼び出しがアップグレード済みのバイナリに転送される場合でも、このツールをすでに持っている接続は、独自の承認ハンドラーを保持します。

ビルド済みサーバーに対するプロトコルの検証には、次を実行してください。

python3 scripts/test_approval.py target/debug/ljos-mcp

誰が着席しているか

シートとは、接続したプログラムのことです。ljos-mcp は、初期化したクライアントの名前を付けます。runner が開いたシェル内の ljos は、プロセスツリーまたは共有セッション ID から同じ名前を特定します。これにより、runner のツールとその動詞は、変数を設定しなくても 1 つのシートになります。上位のプログラム、または runner 配下のログインユーザーしかシート名を特定できないシェルからのトラッカーへの書き込みは、LJOS_SEAT が設定されるまで拒否されます。seats.toml にシートが列挙されている場合は、そこに記載されていないシートからの書き込みも拒否されます。

Grok Bot のようなシェル専用エージェントには MCP クライアントもコマンドフックもなく、プロセスツリーからシートを特定できません。ljos onboard --harness grokbot はスキルと環境変数ファイルを書き込みます。そのファイルを読み込むと、LJOS_SEAT にシート名が設定されます。ljos hook --prompt はプロンプトフックです。ljos policy --fail-on-deny は、拒否された場合に終了コード 1 で終了します。このフラグを付けない場合、ljos hook は引き続き終了コード 0 で終了します。

クレームは 1 つの会話に属し、メモリー、投票、信頼はシートに蓄積されます。ljos seat は、両方の名前とその取得元を表示します。ljos onboard は、どの runner でも使える 1 つの MCP エントリを表示し、ljos protocol はエージェントが最初に読むテキストを表示します。

変数を設定する必要はありません。ljos onboard --harness NAME は、deedar のストアを作成し、特に指定がなければ (~/.local/share/deedar/store) を使用します。また、~/.config/vissue/config.toml に指定されるトラッカーを ~/.local/share/vissue/tracker に作成します。ただし、DEEDAR_URL または VISSUE_ROOT がすでに指定されている場合は除きます。応答する writer がいない場合、ljos remember が起動します。どのディレクトリからでも、シートのメモリーは同じワークスペース seat であり、すべてのクレームには書き込んだシートが記録されます。

メール

ljos send SEAT TEXT は、指定したシートにメッセージを書き込みます。 ljos send --group NAME TEXT は、そのグループのほかのメンバーにメッセージを書き込みます。 --interrupt を指定すると、次のプロンプトの先頭にメッセージが配置されます。--issue ID を指定すると、メッセージを vissue の課題にスレッド化します。その場合、atom はその課題のスコープを引き継ぐため、ljos sync によって封印済みログに含まれます。

ljos inbox は未読メールを一覧表示し、受領確認を書き込みません。応答しない pack はエラーとなり、ljos send はメールを保持する packset のバージョンを表示します。ljos read ID は受領確認を 1 件書き込みます。ljos reply ID TEXT は送信者に返信し、課題を維持します。ljos hook --prompt は未読メールを表示し、表示したメッセージごとに受領確認を書き込みます。pack が応答しない場合は、mail could not be checked と表示しますが、それでも終了コード 0 で終了します。シェルのシートは ljos inbox を定期的に確認します。 プッシュモードでは、切り離された wake が起動する前に封印済みログをプッシュします。 送信処理は待機せず、プッシュに失敗した場合は wake ログに記録されます。 ljos inbox --sync [COMMIT] は、リモートにそのコミットが反映されるまで取得を繰り返します。最大 30 秒間（LJOS_INBOX_SYNC_WAIT）待機し、それでも反映されない場合はリモートの先頭を取得し、封印済みログをインポートしてから一覧表示します。 リモートがなければ、一覧表示のみを行います。

意思決定パネルの並行処理

意思決定パネルは、一度に最大 LJOS_PANEL_CONCURRENCY 人のメンバーを実行し、1 人が終了すると次のメンバーを開始します。未設定の場合、マシンの並列処理数を上限 4 に制限した値が使われます。LJOS_MAX_PARALLEL も同じ設定です。0 を指定すると、すべてのメンバーが開始されます。

コマンド

deed を引用すると、その deed が指定されます。バイト列は deedar に残ります。finish を実行してもチケットは閉じられず、ノードを完了しても同様です。作業が承認された時点で、finish --close を実行するとチケットが閉じられます。--close を付けずに finish を実行すると、クレームを解除し、ljos release と同様にチケットをクレーム前の状態に戻します。そのため、誰も保持していないのにチケットが STARTED のまま残ることはありません。

ljos sitting vissue-xxxx --playbook sit        # doctor, cards, due, island, playbook, recall, timeline, claim
ljos finish vissue-xxxx --lesson "..." [--outcome ship]   # file the lesson, fire, complete, learn
ljos accept <id>                                   # write a filed proposal into the pack
ljos calibrate -p project                      # trust rows from the voting history, no truth labels
ljos remember "the default fuse is CombMNZ"
ljos prefer "CombMNZ over RRF"
ljos search fuse
ljos island "rebuild the packset site"
ljos evidence deed-…
ljos deed vissue-xxxx --add deed-…
ljos recall vissue-xxxx
ljos claim <node>                              # the session node, and the tracker issue to STARTED under the same name
ljos claim --next [--role <role>]              # the first ready node in claimdag's order for you
ljos release <node>
ljos seat                                      # who is sitting: the seat, this conversation's holder, and where the names came from
ljos complete <node> --status done
ljos cards
ljos policy -- ls
ljos approve <request-id>                       # record explicit consent for one stopped command
ljos consensus vissue-xxxx
ljos trust alice bob 0.8 --why deed-… [--about docs]
ljos persona reviewer --anchor 0.2 --view "Reads for what breaks in production." --about release
ljos playbooks                                 # sit, arena, land, company-panel, overnight, feature
ljos playbook vissue-xxxx company-panel        # bind a recipe; sitting copies the body before recall; panel refuses until then
ljos vote vissue-xxxx --for hold --expect ship --confidence 0.6 --used none
ljos predict vissue-xxxx --expect ship          # the same forecast on its own; two forecasts and consensus names the surprisingly popular answer
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."   # argv law in the pack; the hook and policy enforce it (see "What a rule reads" in the reference)
ljos brief reviewer vissue-xxxx                # what a subagent playing reviewer starts from
ljos note ISSUE "..."                         # the agent's own lesson; the prompt does not treat it as a fact
ljos panel vissue-xxxx --out panel             # every persona's brief as a file, for a runner without MCP
ljos panel vissue-xxxx --cloud                  # one prompt file per persona: seat env, slot, push rules
ljos vote vissue-xxxx --for hold --as reviewer
ljos panel vissue-xxxx --jev                   # with Jev on: cast when every seat is sure and agrees, else briefs for subagents
ljos learn vissue-xxxx --outcome ship
ljos due
ljos hud                                       # execs sibling ljos-hud (overlay; P pops out)
ljos habit mab-cr-all 0.579 --unit acc --every 7d --source example-0001   # an example reading; the one before closes and is kept as what it was
ljos habit                                     # every habit as it stands, the change since the last reading, when the next is due
ljos graded <atom-id> [--lapsed]
ljos handover --out bag --project x --issue vissue-xxxx
ljos receive bag [--since bridge.txt] [--import]
ljos doctor                                    # whether ljos is ready, and only the rows that need action
ljos doctor --all                              # every row
ljos protocol
ljos mcp                                       # serve MCP over stdio through the ljos-mcp beside this ljos
ljos onboard                                   # at a terminal, every runner found on this machine; into a pipe, the one MCP server entry any runner takes
ljos onboard --harness all --dry-run           # what onboarding every runner found would write
ljos onboard --harness json                    # the one MCP server entry any runner takes
ljos onboard --harness hermes                  # register with a runner named in harnesses.toml; opencode, hermes, omp, grok, antigravity, cursor come as shapes
ljos onboard --harness grokbot --skills ~/.grokbot/skills   # shell-only: skill and an env file, no MCP server and no hook
source ~/.config/ljos/grokbot.env              # LJOS_SEAT=grokbot; the process tree is not this seat
echo "$prompt" | ljos hook --prompt            # the prompt hook, from a shell
ljos policy --fail-on-deny -- git push --force # exit 1 on a deny; without the flag the exit stays 0
ljos findings out/campaign.json --remember     # file each resolved finding as a proposal
ljos group ops --add bob                       # a group of seats; membership is a pack atom
ljos send bob "the build is red" --issue acme-4 --interrupt
ljos send --group ops "the build is red"
ljos inbox                                     # unread mail; listing writes no receipt. hook --prompt marks what it shows read
ljos read <id>                                 # the receipt the sender sees
ljos reply <id> "looking"                      # back to the sender, on the same issue

MCP

ljos-mcp は stdio 経由で同じ動詞を提供し、ljos mcp も同様です。これは同じ場所にインストールされた ljos-mcp を実行します。デフォルトでは、コアツールを21個一覧表示します。最初にガードとメモリーが並びます。ツールは rule、request_approval、prefer、remember、search、start、guard_check、file、options、note、recall、sitting、finish、claim、release、send、inbox、reply、vote、consensus、doctor で、それぞれに ljos_ のプレフィックスが付きます。 一覧に含まれる各ツールの説明とスキーマは、セッションのたびにトークンを消費します。コアセットでは8,103トークン、全52個では17,691トークンです（initialize の指示と tools/list の結果を o200k_base でカウント）。サーバーの環境変数に LJOS_MCP_TOOLS=all を設定するとすべてのツールが一覧表示されます。LJOS_MCP_TOOLS=core,island,due のように指定すると、名前付きのツールが追加されます。ツールが失敗した場合は、理由を含む isError マーク付きの結果を返すため、モデルがそれを読み取れます。サーバーにはプロトコル ljos://protocol、読み取り専用のカード ljos://cards/、3つのプロンプトもあります。ljos_due は、期限が最も近い8件のクレームと、まだ期限内の合計件数を返します。ランナーがサーバー設定を保持する場所に、次を貼り付けてください。

{"mcpServers": {"ljos": {"command": "ljos-mcp"}}}

公式 MCP Registry には、crates.io の ljos ページからこのサーバーが登録されており、そこでは次の行が確認されます。

• mcp-name: io.github.leidarljos/ljos

server.json にレジストリーのエントリーが記載されており、リリースタグを公開すると登録されます。 Dockerfile は ljos-mcp をビルドして起動します。これは、サーバーを実行してツールを一覧表示するレジストリー向けです。

examples/unanimous-green/ では、2人の実装者と2人のレビュアーが ljos consensus によって全会一致の GREEN に到達する様子を示しています。

5つのペルソナから成るパネルが、このシートのツールアダプターを選びました。各ペルソナが何を評価したかを示す投票と、learn の前後における settle の2通りの解釈は、examples/runtime-panel/ にあります。

スモークテスト

scripts/smoke.sh は、スクラッチストアで各ループを実行します。メモリー、合意、学習、シッティングとその完了、さらに先行するクレームを閉じる書き換えをテストします。習慣、as-of 読み取り、署名付きハンドオーバーもテストします。ハンドオーバーは受信後、1バイト変更すると拒否されます。ルールはフックと policy を通過します。

次に、それぞれ独自の LJOS_SEAT と *_SESSION_ID を持つ2つのシートが、1つのチケットを順番に引き継ぎます。A がシッティングを行い、行為を引用して引き継ぎます。B がインポートし、A が解放し、B がシッティングを行います。両者が投票し、コンセンサスが実行され、完了によってチケットが閉じられます。最後に tracker git がコミットを報告します。最後に、scripts/herd.sh が競合する1つのチケットに対して8回のシッティングと8回の完了、そして1回の island fire を実行します。 scripts/terra/ には、実行時にクラスター上でシートをビルド、スモークテスト、群れ実行する Slurm スクリプトがあります。

オプション：Jev

デフォルトでは、シートはすべての判断をローカルで行います。許可されているマシンでは、それらの判断を TypeSafe のホスト型意思決定モデルである Jev に委ねることができます。その場合は ~/.config/ljos/jev.toml に enabled = true とキーコマンドを記述してください。すると Jev は、どのクレームがプロンプトに関係するか、またそのプロンプトがエージェントを正すものか、選択肢を提示するものかを判断します。さらに、ペルソナの投票も行い、エージェントが停止してよいかを判断し、期限が来たクレームがまだ真実かどうかを確認します。

投票はペルソナ名ではなく、judge:<model> として記録されます。 ljos due --judge は、ジャッジがまだ真実だと判断したクレームを示します。ljos graded はそれを想起済みとしてマークします。ljos judge-score は、ジャッジのログを結果と照合して読み取ります。 ローカルの回答は引き続きフォールバックとして使われ、このファイルがないマシンではこれまでどおり動作します。プロンプトの費用は約 $0.00004 です。これは出力料金無料の場合に、入力約900トークンを100万トークンあたり $0.042 で計算した額で、ljos doctor が当月の支出を表示します。チャットバックエンドでは usd_per_mtok_in の指定が必要です。解説の判断に関するセクションでは、Jev がシートの既存の処理にどう組み込まれるかを説明しています。セットアップ手順はハウツーにあります。

ドキュメント

組織サイトでは座り方を説明しています：https://leidarljos.github.io。クレートのサイトはOrgとSphinxで構成されています：https://leidarljos.github.io/ljos/.

ページ	内容
最初の書き込み	インストールし、1文を記憶させ、検索して呼び出します
座る	sittingで開始し、finishで終了します
ランナー	どのランナーでも使える1つのエントリ。座席が自ら名前を付けます
ポリシー	どのシェルコマンドが、どのレイヤーによって拒否されるのか、またユーザーがどのように承認するのか
はじめに	スクラッチストアでのメモリ、合意、座り方
ハウツー	フック、オンボーディング、習慣、引き継ぎ、信頼
リファレンス	すべての動詞、ツール、変数
解説	契約、メモリモデル、データとしての時間、学習する合意