/LEH-jee/オープンな仕様とツール

あなたのコンテキストを
読めるものに。

チームのチャットやツールごとの指示に埋もれた意図を、Leji はひとつの場所に集約します。それが、チームでレビューし所有する共有コンテキストレイヤーです。標準化するのは形とガバナンスであり、内容ではありません。人もエージェントも同じ出典を参照でき、検証ツールによってずれを可視化できます。

AI エージェントの支援による翻訳です。内容に相違がある場合は、英語版ページが優先されます。文章に問題を見つけた際は、Issueまたはプルリクエストをお願いします。

$ leji adopt --yes --wire-adapters
Wrote 16 files (context root: docs/):
   .leji/work/onboarding-brief.md   AGENTS.md   docs/agents/core.md   …

$ leji validate
ok (0 errors, 0 warnings)

$ leji conformance
ok (0 errors, 0 warnings; claimedLevel: core, verifiedLevel: core, processAttested: 4)
npm install -g @leji-org/leji

無料でオープンソース · Apache-2.0 · CC-BY-4.0

移行せずに導入

いまあるリポジトリから始める。

CLI は、既存のツリーにコンテキストレイヤーをスキャフォールドします。ファイルは一切移動せず、エントリポイントが変わるのは、明示的に--wire-adapters を指定した場合だけです。

  1. まず

    既存ツリーにスキャフォールドする

    adoptは、既存のドキュメントルートを再利用し、カテゴリインデックスファイルのひな型を配置して、エージェントのエントリポイントに書かれている内容をコンテキストレイヤーへコピーします。既存ファイルは移動されず、--wire-adapters を指定するまで、エントリポイントも書き換えられません。

  2. 次に

    エージェントがマッピングを提案する

    オンボーディングブリーフに従って、エージェントがリポジトリを読み、各文書をどのカテゴリに分類するか提案します。その提案は、他の変更と同じようにレビューします。

  3. その後は

    そこから統制する

    変更は、リポジトリのレビューのゲートを通ります。CI での検証がずれを検出し、鮮度の期限によって古くなったコンテキストを識別できます。

人が読み、エージェントが利用する

ひとつの出典、ふたつの読み手。

チームの考え方を、リポジトリが所有する記録として残します。内容は、ドメインの言葉、制約、決定、規約、エージェントのガードレールです。出典はひとつで、変更はすべて同じレビューのゲートを通ります。

共有コンテキストレイヤーレビューを通して変わる

人のために

チームの誰もが、エージェントが参照するのと同じコンテキストレイヤーを読めます。leji view は、共有コンテキストレイヤーを、人が読める形でブラウザに開きます。

エージェントのために

エージェントはブートプロファイルから入ります。作業前に読むべき内容を示す、ただひとつのファイルです。エントリポイントファイル(AGENTS.mdCLAUDE.md)は、独自の写しを持たず、そこへ誘導します。MCP サーバーは、エージェントに仕様とスキーマを提供し、検証と適合性の判定を直接実行できるようにします。

適合性

レベルを宣言し、検証する。

4 つのレベルは段階的に積み上がります。自己評価による成熟度ではなく、実際に何が整っているかで判定されます。たいていのチームは governed まで進み、そこで止めます。CLI が機械的に確認できる項目を検証し、残りはチームが確認します。

  1. coreチームで共有されたコンテキストマニフェスト、ブートプロファイル、実質のある内容、最初の決定、明示された所有者。
  2. indexedツールから読めるように生成されたインデックスと、機械可読な変更履歴。
  3. governedレビューされ、ずれが検出されるプルリクエストのレビュー、エージェントプロファイル、CI、確認対象となる鮮度の期限。
  4. federated組織全体の実践他のリポジトリでのピン留めされたマウントと、古いピンの報告。フェデレーションの仕組み。

なぜこの形なのか

持続する意図を循環させ、仕組みで確かめる。

I.

指示ではなく意図を

持続する意図は、レビューされたひとつのコンテキストレイヤーに置かれ、人もエージェントもそこから行動を導き出します。ベンダーのエントリポイントはそこへ誘導するので、AI ネイティブなチームのコンテキストは、どのツールよりも長く存続します。意図が長持ちする理由。

II.

階層ではなく輪

人から人へ、人から AI へ、人から AI を経て人へ。この 3 つはいずれも、ひとつの共有コンテキストレイヤーを中心とする主要な流れです。全員が読み、誰でも提案でき、人がプルリクエストを通じて承認します。 輪がうまくいく理由。

III.

善意ではなく仕組みを

現実が変われば、共有コンテキストは古くなります。コードレビュー、機械的なずれの検査、鮮度の期限によって、保守が仕組み化されます。古くなったコンテキストが、黙って現行のものとして扱われることはありません。 仕組みが効く理由。

機械向けのエントリポイント

マニフェストは 1 ファイル

既存の docs/ ツリーは、名前を変えずに割り当てることで適合します。リポジトリルートのひとつの leji.jsonで、コンテキストルート、ブートプロファイル、カテゴリの割り当て、適合性の宣言を記述します。

十分に整備されたコンテキストレイヤーには、ベンダーファイルは不要です。invocation でエージェントホストをブートプロファイルへ直接誘導するか、leji startで検出したホストをそこで起動します。

エントリポイントファイルは参照先を示すポインタであり、コンテキストそのものを置く場所ではありません。AGENTS.mdは、多くのエージェントホストが読み込める移植可能な形式です。詳しくは導入ガイドを参照してください。

マニフェストのリファレンス →

{
  "leji": "1.0",
  "name": "acme-billing-context",
  "description": "Shared context layer for this repository.",
  "rootPath": "docs/",
  "bootProfilePath": "docs/boot-profile.md",
  "categories": {
    "domain": { "indexes": ["docs/context/domain.md"] },
    "system": { "indexes": ["docs/context/system.md"] },
    "governance": { "indexes": ["docs/context/governance.md"] },
    "decisions": { "indexes": ["docs/context/decisions.md"] }
  },
  "owners": { "primary": { "name": "Acme Platform Team", "contact": "platform@acme.example" } },
  "conformance": { "claimedLevel": "core" },
  "vendorAdapters": ["AGENTS.md"]
}