Agent · E11 Bootstrapper 🧭

E11 Bootstrapper (skill: e11-bootstrapper) — the scaffolding wizard. Drives one-shot creation of new E11 backend repos, frontend monorepos, in-repo microservices, and new SDK packages. Resolves SDK dependencies via the alloy matrix; writes files only after an explicit [C]onfirm.

What it produces

• A new backend repo (microservices repo) or frontend monorepo (shadcn-based, apps/web).
• An in-repo microservice (microservices/service-<name>/) added to an existing backend.
• A missing package (rest, tasks, functions, client, jobs) added to an existing microservice.
• A new SDK package, backend or frontend flavor, in your local SDK checkout.
• Durable wizard state at .foundry/_scaffold/wizard-state.yaml plus a shared scaffold memlog (.foundry/_scaffold/.memlog.md) so an interrupted run resumes exactly where it stopped.

When to use it

• Greenfield: a new repo, service, or SDK. For everything else, use the lifecycle phases.
• Resuming an interrupted scaffold — the agent detects saved state at activation and offers resume/restart/cancel before anything else.

How to invoke

Invoke e11-bootstrapper:

Code	Dispatches to	Purpose
[NB]	e11-bootstrap-wizard	New backend repo
[NF]	e11-bootstrap-wizard	New frontend monorepo
[NS]	e11-bootstrap-wizard	New SDK package (backend or frontend flavor)
[NM]	e11-bootstrap-wizard	New in-repo microservice
[RI]	e11-bootstrap-wizard	Resume an interrupted wizard
[AM]	e11-scaffold-microservice-package	Add a missing package to an existing microservice
[QK]	e11-knowledge	Pull an alloy doc directly

The wizard collects identity + output root, resolves your SDK selection through the dependency matrix (skill:e11-knowledge matrix:unit → meta/unit-matrix.yaml, applying always/implies edges), summarizes, and only hands off to the matching scaffold after [C]onfirm.

Example session

You: e11-bootstrapper

Bootstrapper: 🧭 No saved wizard state. What are we scaffolding?

You: NB — a backend for the events platform.

Bootstrapper: Step 1 — identity: name "events-backend", output root?
You: ~/repos
Bootstrapper: Step 2 - SDK selection. matrix:unit resolved.
              You picked auth, billing → implies user, access.
              Step 3 — summary: 4 SDKs, 8 base microservices.
              Step 4 — [C]onfirm / [E]dit / [X]cancel?
You: C
Bootstrapper: Handing off to e11-scaffold-backend. Verification:
              yarn install && yarn build ... ✓. Report written.

Gotchas

• Alloy must be installed - the matrix resolves via skill:e11-knowledge matrix:unit (meta/unit-matrix.yaml). The wizard halts with an install instruction otherwise.
• SDK scaffolds need a local checkout. e11-scaffold-sdk-backend / e11-scaffold-sdk-frontend refuse to write into the shared cache — set FOUNDRY_SDKS_NODEJS_PATH / FOUNDRY_SDKS_REACT_PATH to your own clone.
• Non-empty targets are refused. Pick a fresh output_root or answer the emptiness-check prompt deliberately.
• In-repo microservice vs SDK: internal business logic that won't be reused → [NM] (private, never published). Reusable platform capability → [NS].

Customizing

Org defaults are the point of the scaffold surface: registry scope (npm_scope), verification commands (verify_command), starter SDKs, target-backend path — each lives in the relevant scaffold's customize.toml and can be overridden in .foundry/custom/<skill>.toml without touching skill files. The agent itself (persona, menu, wizard-state resume step) is .foundry/custom/e11-bootstrapper.toml. See Customization.

Source

src/foundry/workflows/5-scaffold/e11-bootstrapper/SKILL.md

See also: Phase 5 — Scaffold · Start a new backend repo · Scaffold a frontend app.