Recipe · Start a new backend repo

Goal: from zero, end up with a fresh microservices backend repo that has the right E11 SDKs installed, builds, and is ready for its first service.

Time: ~10 minutes interactive · Owner: E11 Bootstrapper · Workflow: e11-bootstrap-wizard → e11-scaffold-backend

Prerequisites

• Foundry installed in some project — your "control" project where you run the wizard from. Doesn't have to be related to what you're scaffolding. (See installation.)
• @engineering11/alloy installed in that same control project - the wizard reads the selection matrix via skill:e11-knowledge matrix:unit (the ladder resolves it; meta/unit-matrix.yaml).
• A path in mind for the new repo. Default is a sibling directory.

Walkthrough

You: @e11-bootstrapper NB

Bootstrapper: Starting bootstrap wizard, scaffold_type=backend.

  Step 1 — Project identity
  Project name? (default: based on cwd)

You: platform-billing

Bootstrapper: Output root? (default: ../platform-billing)

You: [accept default]

Bootstrapper: Step 2 — SDK selection
  Querying matrix:unit via skill:e11-knowledge ...

  Always-included for backend (per matrix):
    configuration, security, logging, errors

  Pick additional SDKs (toggle):
    [ ] auth          [ ] user         [ ] access      [ ] datastores
    [ ] rest          [ ] tasks        [ ] functions   [ ] jobs
    [ ] notifications [ ] messaging    [ ] files       [ ] search
    [ ] client        [ ] more...

You: auth, user, access, datastores, rest

Bootstrapper: Resolving implies edges:
    auth   implies user, access     ✓ (already selected)
    access implies user             ✓ (already selected)
    rest   implies datastores       ✓ (already selected)

  Final SDK set (9):
    configuration, security, logging, errors,
    auth, user, access, datastores, rest

  Step 3 — Summary
    output_root: /Users/you/work/platform-billing
    scaffold_type: backend
    SDKs: 9 (above)
    Workflow: e11-scaffold-backend

  Confirm to scaffold? [C]

You: C

Bootstrapper: Handing off to e11-scaffold-backend workflow.
  [writes repo tree at /Users/you/work/platform-billing/]
  [runs npm install]
  [runs npm run build]

  ✓ Scaffold complete.
  Repo at: /Users/you/work/platform-billing
  Build:   passed
  Tests:   no tests yet (greenfield)

  Next steps:
    1. cd /Users/you/work/platform-billing
    2. Install Foundry there too if you want agents in-repo:
         npx @engineering11/e11-foundry install
    3. Add your first microservice:
         @e11-bootstrapper NM

What you get

The scaffolded repo (/Users/you/work/platform-billing/):

.
├── package.json              # workspaces config, npm scripts
├── tsconfig.base.json
├── microservices/            # empty — your services go here
├── shared/                   # platform-wide shared code
├── scripts/                  # build, deploy helpers
└── README.md                 # what was scaffolded and why

The selected SDKs are installed as @engineering11/* dependencies, ready to import.

First microservice

You probably want to add a service immediately. From inside the new repo (after installing Foundry there):

@e11-bootstrapper NM

Bootstrapper: Starting bootstrap wizard, scaffold_type=microservice.
  This adds a private in-repo service under microservices/service-<name>/.

  Service name?

You: tenants

Bootstrapper: Packages to scaffold (api is always included):
    [x] api    [ ] rest    [ ] tasks    [ ] functions    [ ] client    [ ] jobs

You: rest, tasks

Bootstrapper: Confirm:
    output: ./microservices/service-tenants/
    packages: api, rest, tasks

You: C

Bootstrapper: [writes service tree]
  ✓ service-tenants scaffolded with api, rest, tasks packages.

When you'd pick a different path

• A new publishable SDK instead of a backend repo → [NS] New SDK (Add a new SDK recipe).
• A frontend application instead of a backend → [NF] New Frontend App (Scaffold a frontend app).
• An in-repo microservice for an existing backend → [NM] New Microservice (covered above).
• A missing package on an existing microservice → [AM] Augment Microservice.

Gotchas

• The wizard runs from your control project, not the new repo. It writes to output_root, not the cwd. Don't cd into the not-yet-scaffolded path before starting.
• always SDKs are non-negotiable. You can't deselect configuration / security / logging / errors — the matrix marks them required for any backend project.
• implies edges are auto-resolved. Picking auth always pulls in user and access even if you didn't tick them. The wizard tells you what it added.
• Empty output_root only. If the target path exists and contains files, the wizard refuses to overwrite. Pick a fresh path or clean the target first.
• Foundry runs from node_modules. The control project where you ran the wizard remains the source of agents/skills for the wizard itself. If you want Foundry inside the new repo (you usually do), install it again there.

Source

Agent: e11-bootstrapper/SKILL.md · workflows: e11-bootstrap-wizard/SKILL.md, e11-scaffold-backend/SKILL.md, e11-scaffold-microservice/SKILL.md · SDK matrix: matrix:unit (meta/unit-matrix.yaml)

See also: Phase 5 — Scaffold · Bootstrapper agent.