Get started

One command sets up a repository: e11 init. Finish the prerequisites first.

cd your-repository
npx @engineering11/e11-foundry@latest init

Init asks four things: the project name, where planning and stories live (default foundry), the editors to write skills for, and one knowledge question:

? What should agents in this repo know about?
  ● Just Foundry - no knowledge base
  ○ This codebase - build a knowledge base from your own code (Alloy)
  ○ This codebase + the Engineering11 platform - needed to scaffold E11 apps
  ○ This codebase + knowledge I already have (other repos, packages)

Init saves the answer in .foundry/project.toml, so a teammate's clone never asks again. Each answer does only what it needs.

Just Foundry

1. Run e11 init and choose Just Foundry, or run e11 init --yes --knowledge none.
2. Init writes the project file, configuration, Toolkit, price list, profiles, ignore rules and editor skills. The knowledge step reads skipped no knowledge base (choice: none).
3. Run e11 doctor. It prints No knowledge base configured and no Alloy row.
4. Commit what init lists: .foundry/project.toml, profiles.toml, pricing.json, .foundry/custom/ and .gitignore.
5. Init closes with Next: ask your agent for /e11-help.

This codebase

1. Run e11 init and choose This codebase, or run e11 init --yes --knowledge own.
2. Init runs alloy init at the version Foundry pins. The knowledge step writes .alloy/ and the MCP entry for each editor.
3. Run e11 doctor to check the Alloy rows.
4. Commit the Foundry files (including .foundry/custom/), .alloy/, the editor MCP file and .claude/. The ignore rules keep Foundry's generated skills out of .claude/, so what you commit there is Alloy's skills.
5. Init closes with Next: ask your agent to *set up Alloy*.

This codebase and the Engineering11 platform

Choose this to scaffold Engineering11 apps. It is the only answer that installs the scaffold skills.

1. Run e11 init and choose This codebase + the Engineering11 platform, or run e11 init --yes --knowledge e11.
2. Init runs alloy init, adds the Engineering11 knowledge (@engineering11/alloy) once, and runs alloy sync to fetch it.
3. The knowledge step names the pinned versions, for example .alloy/, corpus.lock (engineering11-foundation 1.11.0), MCP entry (alloy-cli 1.11.0). The version will differ.
4. Commit the Foundry files (including .foundry/custom/), .alloy/, the editor MCP file and .claude/.
5. Init closes with Next: ask your agent to *scaffold a V2 app*.

This codebase and knowledge you already have

1. Run e11 init and choose the fourth answer. A picker lists the repositories Alloy has seen on this machine, the Engineering11 platform, and Something else… for a git URL or package.
2. Without a terminal, name them: e11 init --yes --knowledge other=<name,...>. A value that is a git URL or an @-scoped package is added as typed; any other value is a known repository name or path.
3. Init runs alloy init, adds each pick, then runs alloy sync. The step lists what Alloy offered but did not add.
4. Commit the Foundry files (including .foundry/custom/), .alloy/, the editor MCP file and .claude/.
5. Init closes with Next: ask your agent to *set up Alloy*.

An Alloy CLI older than the picker prints one line and sets up this codebase alone. Add the others later with alloy add. If the picker fails for another reason, such as a token the registry refuses, init stops before writing anything and names the cause.

If none of the picks were added, the next e11 init refuses the knowledge step until you name them with --knowledge other=<name,...>.

Open an initiative

Planning skills, starting with the PRD, work inside an initiative, and a fresh checkout has none. Until one exists, e11 doctor shows initiative fix and exits 2, and the PRD skill stops with this checkout has no initiative yet. Create one, which also selects it, then commit its file:

e11 initiative new <slug> --title "<title>"
git add foundry/initiatives/<slug>/initiative.yaml && git commit -m "Open the <slug> initiative"

An agent that hits the stop offers to run initiative new for you. In a git repository, e11 doctor keeps exiting 2 with story documents fix until initiative.yaml is committed, because a run plans only from committed documents. See Initiatives.

Run init again

Run e11 init after cloning, or any time. A checkout that already answered skips the question, converges what is missing, then shows the e11 upgrade table. On a terminal, one confirmation brings the code up to date. The Engineering11 knowledge pin keeps its own question. See Upgrading.

To change the answer, pass it: e11 init --knowledge none. Init never deletes .alloy/ or an MCP file; it says what it left in place.

Read the step table

wrote means a step changed files or records. kept means the result already matches. refused names a problem and its fix, and init exits 2. skipped means an option or an earlier step prevented the step.

A repository with code but no lockfile and test script gets profiles refused: name the commands a run must pass in .foundry/profiles.toml, then run e11 init again. An empty folder gets profiles wrote with no acceptance command yet, since there is no code to check. Once the app's package.json has a test script, the next e11 init fills the profile in.

The walkthrough includes captured terminal output. Files a checkout carries explains each file and its owner.

A teammate on an older CLI

Once the project file holds the knowledge answer, an e11 from 2.4.0 or earlier refuses it:

…/.foundry/project.toml is not a project file this release understands

The fix is one command: npm install -g @engineering11/e11-foundry@latest, or npx @engineering11/e11-foundry@latest init.