Skip to content

Onboarding a repo

Available today

A freshly activated workspace is not “no context.” It is “no trusted durable graph yet.” Your team’s decisions already exist, scattered across the repo’s docs, its conventions, and its history. Onboarding is the process of pulling those in as candidates and letting a human decide which become trusted knowledge.

The cold-start shape

Onboarding follows the same law as everything else: ingest generously, promote conservatively.

  1. Scout the repo generously. Read the structure, the docs, the conventions, and a bounded slice of history to find things that look like durable decisions, constraints, and boundaries.
  2. Distill candidates, born pending. Turn what the scouts find into structured governance candidates. None of them is trusted yet.
  3. Review at the bundle level. A human looks at the candidates together and accepts or rejects them.
  4. Promote conservatively. Only accepted candidates become trusted knowledge that injection and Ask will use.

Two ways to do it

  1. The deterministic bundle. mla activate (and mla activate --bootstrap fast) produces a deterministic review bundle from a scan of the repo. It is fast and predictable, and it gives you a starting set of candidates to review.

  2. Agent-orchestrated enrichment. For a deeper pass, the /mla onboard skill runs inside a Claude Code session and orchestrates time- and token-capped scout subagents. They read repo structure, deep docs, and bounded git history, distill candidates, and hand them back for one-gesture human review. The CLI verbs behind it are mla enrich plan | brief | ingest | materialize: plan scans the repo into an immutable run record and prints the scout plan; ingest persists the scouts’ candidates, born pending; materialize writes the durable rules you accept into the local rules file.

Everything stays human-gated

It is worth being explicit: onboarding never auto-trusts what it discovers, even when the discovery is obviously a real convention. Candidates are born pending and sit in a review worklist. That is deliberate. The point of governed memory is that a human decided each trusted claim is correct, and cold-start is not an exception to that rule.

After onboarding

Once you have a reviewed starting corpus, injection has something real to place in context and Ask has something real to answer from. From there the corpus grows through normal capture as you work, always through the same review gate. The next page is that gate: Reviewing & promoting knowledge.