Skip to content
bflo.sh

The team — six agents, exclusive ownership

A roster of specialized agents, one owner per path, and the process for evolving the roster as the codebase grows.

Adapted from the repo's docs/team.md — Part of Internals: the platform's design set, published as content on the platform it describes.

The team is a roster of specialized agents defined in .claude/agents/. The interactive session acts as lead/orchestrator and routes most build work through the roster (see orchestration.md).

This roster is a starting point. Adjust members, ownership, and responsibilities as the team and codebase evolve — see "Evolving the roster" below.

Roster

Member Mission Owns (writable) Primary consumers
contract-owner Publish, version, and guard the team-to-team interface; coordinate all cross-tier work contract/**, contract ADRs, .claude/agents/**, roster records every member
backend-api Turn the published contract into Laravel HTTP (controllers, routes, validation, serialization) backend/app/Http/**, backend/routes/**, HTTP-layer tests/config frontend (via contract)
domain-engineer Business rules, use-case actions, invariants, domain events, port interfaces backend/app/Domain/**, domain tests backend-api, data-engineer
data-engineer PostgreSQL schema, Eloquent models, port implementations, Redis cache/queue strategy backend/database/**, backend/app/Models/**, backend/app/Infrastructure/**, persistence config/tests domain-engineer
frontend-engineer Next.js application consuming the contract exclusively frontend/** end users
platform-engineer DDEV topology, CI, tooling, bootstrap scaffolding infra/**, .ddev/**, CI config, root tooling every member

Ground rules binding every member

  1. Contract-first — no implementation against an interface not published in contract/.
  2. Tier direction holds — dependencies point only in the allowed direction (see rules-of-engagement.md).
  3. Cross-tier work goes through contract-owner as tasks/messages — never direct edits to another member's files.
  4. Full autonomy within the task — members decide, implement, verify, and report faithfully; they escalate only genuine blockers.
  5. Never push to git; commit only on explicit user request — full agreement in working-agreement.md.

Evolving the roster

The roster serves the codebase, not the other way around. Adjust it when ownership areas grow, split, or disappear. To change the roster, update all three in one change:

  1. .claude/agents/<member>.md — add/remove/edit the agent definition (frontmatter name + description decide routing; body is the member's standing orders).
  2. This file — roster table and ownership.
  3. CLAUDE.md — ownership map.

Typical evolutions: split backend-api into read/write API owners as surface grows; add a qa-engineer for cross-tier end-to-end tests (owns e2e/, still contract-bound); add a docs-owner when docs/ churn justifies it; fold domain-engineer into backend-api early in a small project. Record roster changes with a short ADR when they shift ownership of existing code.