What each role can do
ACEF for your role
Everyone talks to the same acef agent in plain language. You never pick routes,
phases, or skills — you just describe what you want. This page shows what each role can do
and which flows concern them.
🔭One framework, different lenses
The engine is the same for everyone: it understands your project, routes the request, and runs only the steps that matter. What changes per role is the lens — which flows are yours.
👩💻Developer
What you can do — describe the work in plain words; ACEF grounds it in your repo and reviews the result.
Add a small feature A
ACEF copies the pattern your repo already uses for that kind of screen/endpoint, wires your change, and reviews it.
Build a large feature B
It turns the work into requirements, design, and tasks, then builds each task — pausing for approval on risky parts.
Fix a bug C
Give the symptom; it reproduces, finds the root cause, and makes the smallest fix that matches your code’s style.
Add unit / integration tests F
It writes tests in your project’s real framework, around behavior — not implementation detail.
🧭Project manager / architect
What you can do — shape and control the work without touching code.
Frame a brief Brief
Turn a raw idea into a clear brief: the problem, who it’s for, success criteria, scope, and explicit non-goals.
Plan a feature Planning
Break it into a story map and traceable tasks — every task links back to a requirement, so scope is auditable.
Get a risk read Risk
See the risk class of any work and exactly which steps are guarded (auth, payment, migrations, multi-repo).
Gate the work Go / Kill
Approve, hold, or kill at the gate. Guarded work cannot merge without your sign-off.
Track status Status
See what’s queued, building, in review, blocked, or done across the work in flight.
🧪Test engineer / QA
What you can do — turn behavior into checks, in your project’s real test setup.
Extract test cases D
Turn product flows into acceptance criteria and structured test cases — ready to review or automate.
Write unit / integration tests F
Tests written in your project’s actual framework and command set, around real behavior.
Build test automation E
Automate the priority user flows end-to-end, on the stack your repo already uses.
Bootstrap the first test E / F
Zero tests in the repo? It sets up one approved example pattern that every later test follows.
Scale coverage by risk All
Happy path for low-risk flows; negative, edge, permission, session, and failure cases for guarded ones.
A flow becomes structured cases like this:
| Case | Precondition | Steps | Expected | Type |
|---|---|---|---|---|
| Login · happy | valid account | enter creds → submit | lands on dashboard | positive |
| Login · wrong password | valid account | wrong password → submit | inline error, no session | negative |
| Login · locked | locked account | submit | lockout message | edge |
| Login · session | logged in | refresh | stays authenticated | session |
📊At a glance
| Role | What you can do | Flows |
|---|---|---|
| Developer | add small/large features · fix bugs · write unit/integration tests | A · B · C · F |
| PM / architect | frame a brief · plan · risk read · gate (go/kill) · track status | brief · planning · gates |
| Test / QA | extract test cases · write unit tests · build automation · bootstrap first test · scale coverage | D · E · F |
| BMAD story workers | ATDD · development · code review · verify-patch · test review · process judgment | full BMAD v2 |
All three talk to the same front-door agent — the lens is what changes. In full BMAD, the story ledger still records separate worker personas so one actor cannot build and approve the same work.