Why Foundry
Build your domain layer. Skip everything else.
Eight specialized AI agents. A catalog of sixty-plus skills spanning the delivery lifecycle. One shared knowledge corpus. Every decision cited, every behavior overridable, every step reproducible.
The E11 platform's foundation, conventions, and SDK choices are already encoded — your team writes what's unique to your product.
Install Foundry → Read the concepts →
What changes when your team uses it
Ship the first PR on day one
Cold-start engineers don't memorize the platform. The skills query @engineering11/alloy per task — pulling the right SDK doc, the right pattern, the right convention — and cite the source in every artifact. A new hire who has never seen the platform produces platform-correct code in their first session: brief → PRD → architecture → story → committed code in one sitting.
Engineers compose like the platform's authors
Architectural decisions, SDK composition rules, multi-tenancy patterns, error-handling conventions — these aren't memorized; they're queried. And not just when someone thinks to ask: the platform thread is built into the lifecycle. The PRD maps every feature to platform capabilities, the architecture inherits the map as [ADOPTED] decisions, stories carry SDK stamps, and the dev skills pre-load each SDK's conventions before writing code — capability-driven, so a task that needs outbound HTTP gets the platform's client SDK doc even when nobody named it. Reaching for axios or a raw process.env secret fails the self-check.
Audit every decision
Every non-obvious choice carries an alloy://... citation. Tests pass before tasks check off. Code review runs five adversarial layers — blind hunter, edge-case hunter, verification gap, acceptance auditor, alloy citation auditor — as context-free subagents, then triages the findings. The alloy layer verifies the pre-load record and resolves every citation on disk, so the paper trail can't quietly rot. The output isn't a black box — it's an audit trail.
Make it yours without forking it
Everything you'd want to tune — personas, menus, templates, output paths, review layers, platform gates — is data in TOML, resolved through layered overrides in .foundry/custom/ that survive every update. Add a compliance review layer, swap the PRD template, point the knowledge layer at your own runbook corpus, add a persona to the roundtable — all without touching an installed skill file. The e11-customize skill authors the overrides conversationally. See Customization.
What's actually in the install
After npx @engineering11/e11-foundry install, your project gets:
Eight agents
Every agent is a skill — a directory your AI tool reads natively; no compiled formats, no sidecars to regenerate.
- Entry points — E11 Master (orchestrator over the live catalog), E11 Bootstrapper (new repos, microservices, SDKs).
- Role agents — Analyst, PM, UX Designer, Architect, Dev, Tech Writer. Each owns a slice of the lifecycle; the sprint, story, review, and QA skills are invoked directly.
The skill catalog
Lifecycle skills grouped by phase — Analysis, Planning, Solutioning, Implementation, Scaffold — plus anytime tools: help, knowledge, refine, discovery, forge-idea, multi-perspective, the four review finders, editorial passes, shard/index, customize.
Ceremony is a dial: oneshot e11-dev-flow for tiny changes, the quick flow for small work, PRD fast paths with [ASSUMPTION]-tagged drafts for features, the full lifecycle when the work warrants it — and e11-dev-auto when you'd rather not watch: it HALTs done or blocked and writes a machine-readable result for automation callers.
The knowledge layer
A single shared skill, e11-knowledge, resolves query keys (sdk:auth, pattern:multi-tenancy, matrix:unit, list:sdks) to documents in @engineering11/alloy - E11's separately-versioned knowledge corpus. The corpus ships a manifest that declares its categories, layout, and views; the skill derives structure from that manifest, so Foundry holds zero corpus-layout knowledge. When a doc is thin or missing, the skill falls back to package source under node_modules/@engineering11/<pkg>/src/ - read the platform, never guess it. Teams extend it with their own corpora via extra_query_keys.
Every claim grounded in alloy carries an alloy://<path> citation; upstream-skill material cites under sdks-nodejs-skill://. Readers can trace any platform-touching decision back to its source.
Foundry is one piece of the E11 platform; the platform pitch lives at engineering11.com.
Four tool surfaces
Same skills, installed into each tool's native skill directory:
| Tool | Install target |
|---|---|
| Claude Code | .claude/skills/ |
| Cursor / Codex | .agents/skills/ (shared convention) |
| OpenCode | .opencode/skills/ |
Switch tools mid-project; no re-install needed. Headless, e11 agent <name> "task" runs any installed agent through a runtime, and e11 pipeline chains them through the artifacts they write to disk.
Discipline rails
The repo that produces your install holds itself to gates: vitest suites over the skills' helper scripts, reference validation across every skill file (validate:refs), guide-coverage checks so documentation can't silently drift from the catalog (validate:guide), and a zero-warning lint/format baseline enforced pre-commit. That a Foundry release passes them is part of what "disciplined AI agents" means in practice.
How it composes
Your domain layer — what you actually write
⇧ composes with
The platform stack — E11's deployed services and SDKs
⇧ documented by
The knowledge corpus — @engineering11/alloy
⇧ consumed by
Foundry — skills that read the corpus and produce
code your platform already expectsYou bring the domain. Foundry brings the discipline. The platform brings the foundation. The corpus connects them.
Start somewhere
| If you're… | Start here |
|---|---|
| New, no idea where to begin | Concepts |
| Ready to install | Installation |
| Shipping a small single-contributor change | Quick flow |
| Starting a fresh backend repo | Start a new backend repo |
| Scoping the agent catalog | Agent quick reference |
| Reshaping Foundry for your team | Customization |
| Extending Foundry itself | Contributing |