For people
Anyone on the team can read the same context layer agents are pointed at. leji view opens the shared context layer, rendered human-readable in the browser.
/LEH-jee/◆Open specification & tooling
Leji gives the intent buried in team chats and per-tool instructions one place to live: a shared context layer your team reviews and owns. It standardizes the shape and the governance, not the contents. People and agents can now read the same source, and validation tooling makes drift visible.
$ leji adopt --yes --wire-adapters Wrote 16 files (context root: docs/): AGENTS.md docs/.leji/onboarding-brief.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/lejiFree & open source · Apache-2.0 · CC-BY-4.0
Adoption, not migration
The CLI scaffolds a context layer over the tree you already have. Nothing moves, and an entrypoint changes only when you ask for it with --wire-adapters.
adopt reuses your docs root, seeds the category index files, and copies what your agent entrypoint already says into the context layer. Nothing you wrote is moved, and no entrypoint is rewritten until you ask with --wire-adapters.
The onboarding brief has your agent read the repository and propose which documents belong in which category. You review that proposal like any other change.
Changes follow your repo's review gate. Validation in CI catches drift, and freshness horizons flag context that has aged.
Read by people, reached by agents
A repo-owned record of how your team thinks: domain language, constraints, decisions, conventions, agent guardrails. One source, changed through one review gate.
For people
Anyone on the team can read the same context layer agents are pointed at. leji view opens the shared context layer, rendered human-readable in the browser.
For agents
Agents enter through the boot profile (vendor entrypoints redirect there), and the MCP server hands them the spec and schemas and lets them validate it and score conformance natively.
Conformance
Four cumulative levels, graded by what is in place rather than self-assessed maturity. Most teams reachgoverned and stop. The CLI checks what a machine can; your team stands behind the rest.
Why it's built this way
Durable intent belongs in one reviewed context layer, where people and agents derive actions from it. Vendor entrypoints redirect there, so an AI-native team's context outlives any tool. Why intent lasts.
Human-to-human, human-to-AI, and human-to-AI-to-human are first-class flows around one shared context layer. Everyone reads, anyone proposes, and people approve through pull requests. Why the circle works.
Reality changes and shared context decays. Code review, mechanical drift checks, and freshness horizons make maintenance mechanical; stale context is never silently treated as current. Why mechanisms matter.
The machine entrypoint
Your existing docs/ tree conforms by mapping, not renaming. A single leji.json at the repository root declares the context root, the boot profile, the category mappings, and the conformance claim.
The cleanest context layer needs no vendor files at all: invocation points the agent host straight at the boot profile, or leji start opens a detected host there.
Entrypoint files are pointers, never homes. AGENTS.md is the portable one most agent hosts read; the adoption guide covers the rest.
{
"leji": "1.0",
"name": "ai-native-team-context",
"rootPath": "docs/",
"bootProfilePath": "docs/boot-profile.md",
"categories": {
"domain": { "indexes": ["docs/context/domain.md"] },
"system": { "indexes": ["docs/context/system.md"] },
"decisions": { "indexes": ["docs/context/decisions.md"] }
},
"machine": {
"indexPath": "docs/context-index.json",
"changelogPath": "docs/context-changelog.json"
},
"agents": { "reviewer": "docs/agents/reviewer.md" },
"owners": { "primary": { "name": "John Smith" } },
"conformance": { "claimedLevel": "indexed" }
}