How to work with Claude Code in a team: plans, order and acceptance

What changes when Claude Code works in a team

Claude Code reads code, edits files and runs commands, and it takes a task described in plain language. While a single person works with it, that person tells it in conversation whatever the agent can’t learn from the code. Once several people start working with agents at the same time, the team has to answer three questions.

• What should the agent do? When a task lives in a message to the agent and nowhere else, the rest of the team can’t see it.
• Who is doing what, and in what order? Two sessions can start the same work, or work that depends on something nobody has done yet.
• When is the work finished? The agent itself reports that it has finished. The team needs to know who checks the result and against what.

The answer lies in three things that the team settles, not the agent: plans, order and acceptance.

The task as a plan, not a message

Planning work with an AI agent starts with where you write the task down. A plan is a document that describes one piece of work so that a person or an agent can do it without asking. It works well with a few fixed parts: the goal, scope, steps, acceptance criteria and definition of done.

Acceptance criteria do two jobs: they tell the agent when to stop, and they tell the person who accepts the work what to check. What to write in each of these parts, so the agent doesn’t have to guess and can check the result itself, is covered in the post How to write a plan an AI agent can deliver without guessing.

Keep an eye on the plan’s size. A good measure is one piece of work that one agent session delivers whole. Split a larger topic into several plans and write down which waits on which.

A plan is a document of its own, not one of the messages in a conversation. Another person will read it, so will another agent session, and so will you a month from now, when you need to check what was agreed. Working from such a document is called spec-driven development.

People set the order

When several agents work in parallel, the order stops being one person’s business. A screen that lists invoices can’t be finished until invoices can be saved to the database. Two sessions that change the same part of the code get in each other’s way.

What helps:

1. Write down the dependencies. For each plan, write down which plans it waits on. Then you can see what is ready to start now and what has to wait.
2. Group plans into epics. An epic gathers the plans of one topic and shows how many of them are already done.
3. Put the ready plans in order. The agent can take the next ready plan itself. People decide which one is next: the agent sees the task and the code, but not the team’s priorities, deadlines or conversations with the client.
4. Give each session its own copy of the code. When one person runs several sessions at once, each session should work in a separate working copy of the repository, for example a git worktree, so the changes don’t collide. The post Multiple AI agents in one project shows how to set this up.

Shared rules for the agent’s work

Each person can work with the agent their own way: one asks for tests and another doesn’t, one lets the agent widen the scope and another expects a question. In a team, it pays to write the rules down once, for everyone, in two places.

• In the repository. Claude Code loads the CLAUDE.md file at the start of every session. A project’s CLAUDE.md goes into the repository with the code, so every person’s session gets the same rules. Put in it what the agent can’t learn from the code: the test commands, the team’s decisions, the places where the code is misleading.
• In a role prompt. Here you describe the process: how the agent takes work, what it does when something is missing, and what it writes at the end. A text like this is called a role prompt.

A role prompt for an agent that delivers plans might say, for example: do what the plan says and nothing more; when the plan leaves something open, ask a question instead of guessing; at the end, write what you did, what you did differently from the plan and why, and what you didn’t do. The question and the answer should go into the plan, not stay in one conversation. Then the person who accepts the work knows what was agreed along the way.

Acceptance belongs to a person

The agent reports that it has finished, but that doesn’t yet mean the work is accepted. Even when the agent works on its own, two decisions should stay with a person: what “done” means, and whether the result is accepted.

How to accept an agent’s work:

• Compare the result with the acceptance criteria in the plan, not with the agent’s summary.
• Ask the agent for evidence: the command it ran and its output.
• Read what the agent did differently from the plan and why.
• Accept or reject the work. When you reject it, write the reason, so the agent knows what to fix.
• Decide as the work comes in. When plans wait a long time for a decision, the fix comes late, and other plans may already be built on the rejected work.

Acceptance doesn’t replace tests or code review. It answers a different question: was what the plan asked for actually built? This split of roles, in which the agent works on its own and a person decides at the points that matter, is called human-in-the-loop.

How to start as a team

1. Choose one place for the whole team’s plans and one plan template.
2. Break one topic down into a few small plans with acceptance criteria and dependencies.
3. Write the test commands in CLAUDE.md, and the agent’s working rules in a role prompt.
4. Agree with the team that you take plans in order, and that each agent session works in its own copy of the code.
5. Give a verdict on every plan, and write down the reason when you don’t accept one.
6. After a few weeks, check which plans came back for rework and what they were missing. Improve the plan template or the role prompt.

How it looks in featureloom

featureloom is a plan board each person on the team connects their own Claude Code, Codex or Cursor to. There, a plan is a markdown document on a kanban board, and the whole thing works like this:

• Plans. featureloom generates plans in the app from the plan template, and agents follow it when they write plans in a console. The built-in template asks, among other things, for the goal, scope, steps, acceptance criteria and definition of done. You adjust it on the Project settings screen, in the Plan template tab.
• Order. The Waits on… dependency says which plan must be delivered before another, and the Order screen shows what is ready to start. An agent gets the next plan in board order: one that waits on nothing and that nobody else is responsible for. A console won’t start a plan that waits, and two consoles won’t take on the same plan. The card shows who is working on the plan and with which console. You’ll find the details in the Epics and Order tutorial.
• Working rules. The organization’s prompts work as commands in Claude Code, Codex and Cursor. Every new organization has a ready-made Realizer prompt: it holds the rules from the example above and leaves columns, order and acceptance to people. The command featureloom realizer INV-14 gives the agent this prompt, the whole plan INV-14 and the documents of the delivered plans INV-14 directly depends on. The Role prompts tutorial shows how to write your own prompts.
• Questions. The agent asks in the plan, and you answer on the plan’s screen with the Answer button. The question and the answer stay in the plan document. Read more in the tutorial The agent’s questions and your answers.
• Acceptance. In the Acceptance section you press Accept or Do not accept, and in the Reasons (optional) field you can add why. The verdict is always given by a person, in the app. After a rejection, the agent reads the verdict and goes back to rework, as the tutorial Acceptance: Do not accept and the agent’s rework shows. On the Reports screen, the Waiting for acceptance part lists the oldest undecided plans at the top.

featureloom doesn’t connect to your code, so separate copies of the repository, the tests and the review of changes stay with the team. To start, an administrator opens the People screen and invites the team with the Invite person button, as in the tutorial Invite people and grant rights. Then each person opens Integrations and connects their console on the Your consoles card, as in the tutorial Connect Claude Code with one command.