Your team’s AIs
Each teammate’s AI reads the confirmed version and builds
Each teammate connects the Claude Code or Codex they already use, once, with their own Plaro account. The AI reads the requirements and their done-when in the version your client confirmed, and whenever they talk to it, Plaro first tells it “since the last notice — 1 new version · 3 requirement changes · 1 open question.” What isn’t decided goes to the PM as a question, and what was built is left as a built report with its commit — the tool asks each time. Developers outside the team join by invite and sign in without an account, with a code mailed to them.
[Allow the connection] → the AI reads the confirmed R-2 → asks the PM → leaves a built report (commit) → on the PM’s acceptance screen
What goes in, what comes out
- Goes in
- Teammates: their own Plaro account, once · outside developers: a mailed code, no account
- Comes out
- Requirements · what changed · open questions · failed acceptance checks → Claude Code · Codex · questions and built reports (commit) → the PM’s acceptance screen
- Limits
- Invited outside developers — 5 per project · one stops after 90 days without use · a sign-in lasts 30 days
- Time
- Told when they send a message — if it doesn’t arrive within 5 seconds, work just goes on
- What it doesn’t do
- Editing requirements, versions or amounts · reading or writing your repository · sending meeting transcripts, amounts or client contacts
How you use it
01 · A teammate connects their AI
They add Plaro to Claude Code or Codex as the project’s [Team & agents] shows, then press [Allow the connection] once with their own Plaro account. From then on, the AI reads the projects that account sees.
02 · It reads the confirmed version and builds
“v1 → v2” — what changed and whether the client confirmed reach it first, and three commands plan the work in that repository: plan the changes (plan_changes) · plan the project (plan_project) · check before acceptance (check_acceptance).
03 · It asks, and leaves what it built
What isn’t decided goes to the PM as a question; what was built is left as a built report with its commit. The tool asks before each one.
04 · The PM sees it in acceptance
“Reported as built · Sam · Claude Code · commit” sits under the requirement, and questions wait as open items. The PM’s answer reaches the AI with the next notice.
Example — Online store renewal
- Before
- Working from v1 — the R-2 card payment screen
- In the conversation
- Plaro “v1 → v2: R-2 changed (card → card + PayPal) · confirmed by the client”
- After
- Change plan — PayPal on the R-2 payment screen · 3 places to touch · 2 tests · ask the PM about R-7
Questions about this feature
- Which tools are supported?
- Claude Code and Codex for now. We connected both and checked them end to end.
- Does our code go to Plaro?
- No. Plaro only hands out the requirements; it never reads or writes your repository.
- Does the developer’s AI get the transcripts?
- Meeting and chat transcripts, amounts and client names and contacts are not sent. A name you write into a requirement’s text goes with it.
- What if a teammate leaves?
- Once someone leaves the team, their AI can no longer read the team’s projects. The PM can revoke an invited outside developer any time, and a connection unused for 90 days stops by itself.
Getting started
Requirements document example and reusable template
Use an online store redesign sample to separate requirements, acceptance criteria and open questions, and keep document versions.
Agree a requirement change with your client before it’s built
A change that comes up in a meeting becomes a new requirements version only after you review it, and your client confirms that version from a link before your team builds it. A worked example with v1, a meeting excerpt and v2.
Client change log template, with three emails for scope changes
A free change log for client projects (what changed, when, in whose words and at what cost) and three emails: confirm today's changes, quote a change outside the scope, and ask the client to confirm the new version.
Client acceptance form template, with three emails for sign-off
A free acceptance form for delivering client work (requirement, acceptance criteria, result and a sign-off block) and three emails: ask for acceptance, re-check a fixed item, and confirm the results.