📋 Get the setup prompt
navigate · F fullscreen · S scroll-mode
Multi-agent engineering

How an AI team can work

One orchestrator, seventeen specialists, three automatic review gates — and a memory that learns from every PR. A practical pattern for working with AI as a team.

Joel del Pilar · Eyevinn
📋 Get the setup prompt
The big picture

An orchestrator, not a generalist

The orchestrator never writes code or designs solutions itself. It routes every request to the right specialist, then verifies the work passes through automatic quality gates.

Orchestrator — routes & verifies
17
Specialist skills
(architect, backend, frontend, …)
3
Auto-invoked subagents
(review gates)
11
Hooks & 6 path-rules
(workflow automation)
The orchestrator's role

What the orchestrator does — and what it never does

It does

  • Understands the request in domain context
  • Picks the right specialist (or chain of specialists)
  • Invokes review gates after every code change
  • Verifies handoff contracts before marking done
  • Preserves context across long sessions

It never does

  • Writes code directly — that's the specialist's job
  • Designs solutions — that's /architect
  • Skips review gates — they are non-optional
  • Creates branches or pushes commits itself
  • Improvises outside the delegation protocol

Modern foundation models follow instructions literally. Strict delegation is the design — not a limitation.

The specialists

17 skills, each a domain expert

Invoked with a slash command. Each has its own model, effort level, allowed tools, and a Handoff Contract that defines "done".

Architecture & Design
/architect
System Architect
Data flows, service boundaries, trade-off analysis
/domain-expert
Domain Specialist
Deep expertise where your product actually lives
/ux
UX Expert
Page layout, data viz, user flows
/a11y
Accessibility
WCAG 2.2 AA, ARIA, keyboard navigation
Implementation
/backend
Backend Developer
APIs, queries, queues, server-side logic
/frontend
Frontend Developer
Components, state, styling, client tests
/db-engineer
DB Engineer
Schemas, migrations, query tuning
/cloud
Cloud Engineer
Compute, storage, networking, IAM
Quality & Safety
/qa
QA Engineer
Test strategy, load tests, integration tests
/security
Security Engineer
Auth, secrets, OWASP, threat modeling
/api-contract
Contract Specialist
Frontend ↔ backend type alignment
/observability
Monitoring Engineer
Metrics, tracing, logging, SLOs
Operations & Workflow
/devops
CI/CD Engineer
Pipelines, containers, deployments
/github
Git Workflow
Branch, commit, push, PR creation
/troubleshooter
Incident Response
Production diagnosis, runbooks, escalation
/secretary
Documentation
ADRs, runbooks, status reports
Maintenance
/weekly-audit
Weekly Audit
Manual fallback for the scheduled audit
The quality gates

3 subagents that run automatically

These never need to be invoked manually. They are non-optional gates that protect every code change and capture every lesson.

code-reviewer

Quality & consistency review
Runs after every code-writing skill
Reviews diffs for code quality, reuse, naming, and pattern consistency. Tags each finding with categories including LEARN — pairing review with teaching.
haiku
medium effort

security-reviewer

Application security review
Runs when auth / JWT / IAM / secrets / CORS / middleware touched
Catches OWASP-class vulnerabilities, validates input boundaries, checks JWT handling, and audits secret references before they ship.
sonnet
high effort

teacher

Per-PR lesson & spaced repetition
Runs after /github opens a PR
Writes a ~400-word lesson explaining what changed and why, then schedules concept reviews on the Ebbinghaus curve: 7 → 14 → 30 → 90 days.
sonnet
medium effort

A missed review gate is an orchestrator failure — not a subagent failure.

The supporting cast

Hooks, rules, and memory

Below the skills sits invisible infrastructure that catches mistakes, enforces conventions, and survives every context compaction.

11 hooks

Auto-format your code after every save. Block edits to lock files. Run your linter and type-checker before letting the session end. Preserve critical context on compaction. Desktop notification when done.

6 path-scoped rules

Different files, different conventions. Backend conventions apply to your server code, frontend rules to your UI code, migration rules to schema changes. Auto-loaded based on path — never the wrong style applied to the wrong file.

Persistent memory

Across sessions. Project state, deadlines, recent PRs, feedback, ecosystem warnings, lessons. Indexed in a project memory file. Auto-saved when something surprising happens. Verified against current code before being trusted.

Examples of conventions the system enforces

Conventional commits validated before they're written
Branch names must match feature/, fix/, chore/
No direct edits to generated or vendored components — use the source-of-truth CLI
No writes to migrations/V* without /db-engineer
No .env reads
No force-push, no git reset --hard
A real example

One sentence in. Eight specialists collaborate.

User: "Add a save function to that data-table page." (One sentence. Zero technical detail. The team fills in the rest.)

1
Orchestrator reads the request and picks the right starting point.
2
/architect decides the approach: REST route + optimistic UI updates + rollback on error.
3
/frontend implements the UI component and the client-side API call.
4
/backend adds or extends the Go endpoint (if backend work is needed).
5
code-reviewer reviews the diff automatically — quality, naming, reuse.
6
security-reviewer runs automatically because a new API route was added.
7
Hooks run type-check and lint — they must pass before the session can end.
8
/github creates the branch, commits, pushes, opens the PR.
9
teacher writes a ~400-word lesson and schedules concept reviews for spaced repetition.
The compounding effect

Every PR teaches the system something

The team doesn't just ship work — it accumulates institutional knowledge that survives every context window.

Per-PR lessons

Every merged PR generates a lesson in memory/lessons/PR-XXX-*.md. ~400 words covering What changed · Why those decisions · Domain concepts · Anti-patterns avoided.

Spaced repetition

Concepts get reviewed on the Ebbinghaus curve: 7 → 14 → 30 → 90 days → archive. Misunderstood concepts surface again. Mastered ones step aside.

Weekly digest

Weekly cadence — auto-scans your repos for version bumps, new migrations, route changes, dependency updates. Writes to a project memory file.

Weekly sharpen

Weekly cadence — multi-agent research team audits platform best practices + each skill domain. CVEs, EOL deadlines, new APIs. Applies improvements automatically.

Result: the team that ships your work today is materially better than the team from a month ago.

Why this design

Five principles that make it work

The team at a glance

One orchestrator, four pillars

Skills, subagents, automation, and memory — all coordinated from a single point.

Orchestrator
routes & verifies
17 SKILLS · DOMAIN SPECIALISTS
/architect /backend /frontend /db-engineer /security /domain-expert /cloud /qa /a11y /ux /observability /devops /github /api-contract /troubleshooter /secretary /weekly-audit
3 SUBAGENTS
code-reviewerevery code change
security-reviewerauth · secrets · IAM
teacherevery PR → lesson
MEMORY & LEARNING
Per-PR lessons~400 words each
Spaced repetition7 → 14 → 30 → 90 d
Weekly sharpenauto-improvements
AUTOMATION · GUARDRAILS
11 hooks 6 path-scoped rules auto-format lint type-check commit validation context preservation deny destructive ops
Joel del Pilar · Eyevinn — joel.delpilar@eyevinn.se