Build a Flutter sign-up flow with five role-based agents that talk through files

Devarshi Shah had five Claude agents (PM, analyst, designer, developer, QA) build a Flutter and Supabase auth module through shared docs; it shipped with 272 passing tests after QA bounced two tasks.

Done withClaudeinSupabase· Nov 4, 2026

What they did

Shah wanted to see whether a small team of agents could turn a vague idea into email and password sign-up a reviewer would accept. He defined five Claude agents, each with its own instructions and a list of things it may not touch: a product manager that owns the sprint plan, a business analyst that owns requirements, a designer that owns the screens, a developer that owns the code and tests, and a QA agent that alone can mark a task done. The agents never spoke to each other directly. Every question, decision and bug report went into files in a docs folder. Shah approved the requirements, then the designs, then reviewed the final pull request, and let the agents run on their own between those three gates. The target was a Flutter app on Supabase auth with a layered architecture whose boundaries are checked by tests.

How it went

The analyst wrote 33 numbered acceptance criteria, seven user stories and a table mapping Supabase error codes to messages, and raised six open questions, two of them security choices Shah says he would have found late. The designer audited his colours against contrast rules and changed the failing ones. QA rejected two tasks on the first pass: a committed env example with real values, and an offline network error misread as an expired email link. The developer fixed both. The result had 272 passing tests and a clean analyzer run. QA could not verify email delivery, deep links on a device or small screens, so those went to a manual checklist.

Worth knowing

The post says only "Claude agents" and does not name the harness. The agents keep no memory between sessions, so output quality depends on how good the written docs are. Scope calls stayed with Shah: email codes needed a paid Supabase plan, so he switched the design to confirmation links. All agent definitions and the docs they wrote are in the public repo.

Try it

With Claude· 4 parts to fill in

Act as a team of five roles working on [feature] in [repo]: product manager, business analyst, designer, developer and QA. Each role may only edit its own files in [docs folder] (plan, requirements, design spec, code and tests, QA report) and may not change another role's output. Roles talk only by writing to those files. Start with the analyst: write numbered acceptance criteria and a list of open questions, then stop and wait for my approval. After I approve, have the designer write the screen specs and stop again for approval. Then let the developer build with tests and let QA verify every criterion, reject anything that fails, and write a matrix linking each criterion to a test. Only QA may mark a task done. List anything that cannot be verified without [a real device or service] as a manual check. Stop when QA has passed every task and show me the summary before any merge.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related