Agent · Architect 🏗️

E11 Architect (skill: e11-agent-architect) — the system architect. Produces the lean architecture spine: a numbered list of binding decisions (AD-n) instead of a sprawling document. Composes existing @engineering11/* SDKs first; proposes custom work only when alloy has no answer.

What it produces

• An architecture spine — ARCHITECTURE-SPINE.md under {planning_artifacts}/architecture/architecture-<project>-<date>/, with its .memlog.md working memory alongside.
• An E11 SDK Composition section in the spine — Capability | SDK | Alloy doc | Rationale, plus explicit Gaps and proposed alloy follow-ups.
• [ADOPTED] architecture decisions for composed SDKs, each citing its alloy doc, that later sections never re-litigate.
• A readiness report when [IR] is run.

When to use it

• After the PRD is finalized — you need SDK, pattern, and infrastructure decisions pinned as invariants.
• The PRD changed — the spine needs updating (it's an Update intent, not a rewrite).
• Before sprint planning — [IR] confirms PRD + UX + architecture + stories agree.

How to invoke

Invoke e11-agent-architect; on activation it pre-loads the alloy foundation set (foundation:platform-model, fullstack-sdk-pairs, backend-sdk-structure, frontend-sdk-structure) before doing anything else.

Code	Dispatches to	Purpose
[CA]	e11-architecture	Create / Update / Validate the architecture spine
[IR]	e11-check-implementation-readiness	Cross-artifact alignment gate
[QK]	e11-knowledge	Pull an alloy doc directly

The lean spine

e11-architecture replaced the long-form architecture doc of earlier releases with a spine of invariants: one test decides what belongs (is it a decision that must not drift, or just a seed?). The coaching path is the default - load-bearing calls are shown to you rather than silently made; the fast path drafts with [ASSUMPTION] tags. Validation runs a deterministic spine linter (lint-spine.mjs) plus rubric and reviewer lenses - one of which enforces the SDK-composition contract (every alloy:// cite resolves against the pinned corpus, swept with alloy check-consumers).

When a PRD with a Platform Capability Map exists, capability enumeration inherits it — the Architect settles each Covered/Composed mapping into [ADOPTED] ADs and takes the "New" rows as the actual design work.

Example session

You: e11-agent-architect

Architect: 🏗️ E11 Architect. Foundation set loaded
           (alloy://shared/foundation/platform-model.md, ...).

You: CA — architecture for the usage dashboard PRD.

Architect: Found prd-usage-dashboard-2026-07-20 with a Platform Capability Map.
           Inheriting: 4 Covered, 2 Composed, 1 New (export scheduler).
           AD-1 [ADOPTED] Usage metering via @engineering11/billing
                (alloy://sources/sdks-nodejs/sdks/billing/backend-using.md)
           ...
           The one open design problem is the export scheduler. Coaching path:
           here are the three options and what each commits us to...

Gotchas

• Don't hand-patch the spine. If the PRD changed, run [CA] with Update intent; the memlog keeps the decision history coherent.
• Inherited invariants are read-only. In a parent/child spine setup, parent ADs bind — the child spine never renumbers or overrides them.
• Gaps are output, not failure. If alloy doesn't cover a capability, the spine's Gaps section makes it visible and proposes an alloy follow-up. Don't paper over it.
• The old name forwards. e11-create-architecture shims to e11-architecture (create intent) for one release. See Upgrading.

Customizing

Persona and menu in .foundry/custom/e11-agent-architect.toml; the skill's own surface (spine_template, output paths, finalize_reviewers, the e11_platform_composition gate) in .foundry/custom/e11-architecture.toml. See Customization.

Source

src/foundry/workflows/3-solutioning/e11-agent-architect/SKILL.md

See also: Phase 3 — Solutioning · Knowledge layer.