Implementation

A build prompt for an AI coding agent: how to stand up the architectural foundation of Agentfy.ai 2.0 — the monorepo, the api CleanSlice skeleton, the 8 layered slice groups, the "dependencies point only downward" invariant, and the Prisma baseline. Feature slices are filled in later (each has its own Implementation page).

This page is an agent prompt

Every section gets an Implementation page — a precise, copy-paste task spec the agent executes. Read Overview, Layered slices and DB schema first; they are the source of truth this prompt points to.

The prompt

ROLE: You are scaffolding the FOUNDATION of Agentfy.ai 2.0 (NestJS + Prisma + CleanSlice). Not
features yet — the skeleton everything else is built on.

GOAL: A booting `api` with the 8 layered slice groups wired as empty-but-valid modules, the
"dependencies point only downward" rule ENFORCED in CI, Prisma connected with a baseline schema, and
the sibling apps scaffolded. Ready for feature slices to drop in.

DELIVERABLES
1) Monorepo: api/ (NestJS), app/ (Nuxt), admin/ (Nuxt), worker/, k8s/, docs/. Shared tooling
   (tsconfig base, eslint, prettier), `#`-path aliases per app.
2) `api` CleanSlice structure: src/slices/<group>/<slice>/{domain,data,dtos,<slice>.module.ts}.
   Create all 8 groups as wired modules (empty is fine):
   infra · setup · system · user · admin · runtime · agent · billing.
3) LAYERING ENFORCEMENT: a dependency-boundary check (eslint-plugin-boundaries or dependency-cruiser)
   that FAILS CI when a lower group imports a higher one. Order (low→high):
   infra → setup → system → user → admin → runtime → agent → billing.
4) infra + setup baseline: infra/prisma (PrismaService), infra/redis, infra/storage adapters;
   setup/core (config · error filter · health · rate-limit), setup/mcp (tool registry).
5) Prisma baseline: Team, User, UserTeam, Agent + the conventions (see DB schema). One migration.
6) A trivial GET /health that boots green.

CONTRACTS / CONVENTIONS (follow exactly)
- Slice anatomy: domain (gateway abstract class + entities/types), data (Prisma-backed concrete
  gateway + mapper), dtos (camelCase: createUser.dto.ts). Prisma IS the repository.
- Gateway pattern: an abstract class `IXxxGateway` in domain/ is the DI token; the concrete impl
  lives in data/ and is bound in the module.
- IDs: `{slice}-{uuid}`, generated in `mapper.toCreate`.
- `I`-prefixed abstract classes as DI tokens (IUserGateway, IUserData); `Types` suffix for enums
  (UserStatusTypes); no `any` — use `unknown` + type guards.
- Singular slice folder names (`user/`, not `users/`); routes are plural.

SECURITY: no secrets in the repo; config via env; Prisma URL + KEK from env only.

ACCEPTANCE: see the checklist below. Start at v0.1 scope.

Reference — what the agent must follow

The 8 layered groups (the invariant)

L0  infra      external-system adapters (prisma · redis · storage · vector)
L0  setup      framework plumbing (core · mcp)
L1  system     shared services (usage · setting · notification · llm · file)
L2  user       identity / tenancy
L3  admin      ops (reads others via Prisma)
L4  runtime    ephemeral execution (tasks · worker · events)
L5  agent      the agent domain + orchestrator (the brain)
L6  billing    pure sink (nothing imports it)

Rule: every group may import only groups below it. No cycles. This is the backbone — the CI boundary check exists to make a violation impossible to merge. See Layered slices.

Slice anatomy

slices/<group>/<slice>/
├── domain/                 gateway (abstract IXxxGateway) · entities · types · errors
├── data/                   concrete gateway (Prisma) · mapper (toCreate sets the id)
├── dtos/                   createXxx.dto.ts · updateXxx.dto.ts (camelCase files)
└── <slice>.module.ts       binds IXxxGateway → concrete, exposes use-cases

Prisma baseline

Implement Team, User, UserTeam, Agent exactly as in DB schema (ids {slice}-{uuid}, teamId tenancy, timestamps). Everything else lands with its feature slice.

Ordered tasks

1. v0.1 — foundation (this page): monorepo + api skeleton + 8 wired groups + the layering CI check + infra/setup baseline + Prisma baseline + /health.
2. v0.2 — core (no runtime): fill agent, system/llm, agent/chat, agent/memory, agent/orchestrator.
3. v0.3 — ephemeral runtime: runtime/task, runtime/worker, runtime/event, the worker app (see Worker → Implementation).
4. later: user/admin/billing slices, frontends, SDK — per the Plan.

Acceptance criteria

• [ ] api boots; GET /health returns 200; prisma migrate applies the baseline cleanly.
• [ ] All 8 groups exist as valid NestJS modules under src/slices/<group>/.
• [ ] The CI boundary check fails when a lower group imports a higher one (prove it with a temporary bad import, then remove it).
• [ ] A sample slice follows the anatomy: abstract gateway in domain/, Prisma impl in data/, id minted as {slice}-{uuid} in mapper.toCreate.
• [ ] No any; I-prefixed DI tokens; singular slice folders.

See also

• Overview · Layered slices · Slice breakdown · DB schema — the source of truth.
• Conventions — the CleanSlice rules in full.
• Worker → Implementation — the next subsystem's build prompt.
• Plan — the version-by-version order.