Claude Code Agent Teams Reviewing Synthesizing Results

Combine teammate outputs into one change, run cross-module checks, resolve conflicts, and accept work only against explicit success criteria.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Parallel work only pays off if the pieces fit together afterward. In an agent team, the lead session is the one that coordinates work, assigns tasks and synthesizes results from the teammates. This skill covers the stretch after teammates report done: merging their changes, checking the seams between modules, resolving conflicts, and deciding whether to accept. For background on the feature itself, see the Claude Code Agent Teams method page.

Practitioner workflows treat this as its own phase rather than a formality. One guide lays out a sequence in which the lead breaks down a feature, three teammates handle backend, frontend and tests, and then the team lead synthesizes and runs validation before a final compliance review. Another describes the orchestrator's closing duties as monitoring outputs as they complete and resolving conflicts. A coordinator guide lists aggregating results and making decisions that span multiple workers as core coordinator responsibilities, which is exactly the work nobody else on the team is positioned to do.

The reason it needs deliberate attention is structural. Each teammate verified its own slice inside its own context window, so nobody has checked the boundaries between slices. Integration defects live at those boundaries: a signature that drifted from the agreed contract, two helpers that do the same thing, a test that assumes a migration another teammate wrote differently. A practitioner guide also warns that agent teams struggle with write-heavy tasks where multiple agents modify the same files, so wherever the decomposition was imperfect, expect overlapping edits to surface here.

The inputs are the shared task list, each teammate's diff and summary, the interface contracts agreed before parallel work began, and whatever tests and validation commands the project has. The outputs are one integrated change that passes cross-module checks, a short record of each conflict and how it was resolved, and a per-task decision to accept, send back for rework, or discard.

You can tell this skill went wrong when every module's tests pass in isolation but the combined build fails, when the lead accepts teammate summaries without reading the diffs, or when the same task bounces through rework repeatedly because the acceptance criteria were never written down. Each of those points to a gap in the review, not in the teammates.

How It Works

Synthesis runs as a sequence of passes, each narrowing the risk that a broken change gets accepted. Treat them as ordered: a later pass assumes the earlier one held.

Pass one: verify completion. Before integrating anything, confirm that each task is actually finished. Anthropic's documentation notes that task status can lag because teammates sometimes fail to mark tasks complete, which can also block dependent work. The reverse happens too: a task marked done may be partial. Read the teammate's summary, then check the diff against the task's stated scope.

Pass two: integrate against contracts. When teammates had to interoperate, the decomposition should have agreed on function signatures or API schemas, created shared stubs, let agents work against mocked boundaries, and coordinated integration afterward. Integration is the afterward. Merge outputs in dependency order, prerequisites first, and replace each mock with the real implementation it stood in for. Any place where the real code does not match the stub is a contract violation to resolve, not a detail to patch quietly.

Pass three: run cross-module checks. The same guide describes a final integration phase that combines changes, resolves conflicts and runs cross-module checks. These are the tests no single teammate could run meaningfully: end-to-end flows, full builds, type checks across the whole project, and contract tests between services.

Pass four: resolve conflicts. Conflicts come in three shapes. Textual conflicts are overlapping edits to the same file. Semantic conflicts merge cleanly but break behavior, such as two teammates changing the same default in different places. Decision conflicts are incompatible choices, like two error-handling conventions. The lead owns all three because resolving them requires decisions that span multiple workers. Resolve small ones directly; for larger ones, issue a scoped rework task to the teammate whose area should change.

Pass five: acceptance review. Judge the integrated result against the success criteria set during decomposition. A decomposition is stronger when each task carries explicit scope, a defined output format and success criteria that can be evaluated programmatically, and this is where that investment returns: acceptance becomes running the checks rather than debating quality. Practitioner guidance says the lead should review the resulting work before accepting it. For higher-stakes changes, add an independent pass, such as the final review against standards in the backend, frontend, tests workflow, or a dedicated reviewer role that checks correctness, security and quality rather than implementing.

The loop closes when every task is accepted or explicitly discarded, rework tasks are resolved, and the full check suite passes on the combined change.

Step-by-Step Guide

Step 1: Confirm every task is really done

Walk the shared task list and compare each task's status with the teammate's actual output. Anthropic documents that status can lag when teammates forget to mark work complete, so a pending status is not proof of unfinished work, and a completed status is not proof of complete work. Open each diff and check it covers the full scope the task described. Flag partial or missing work before you start merging, because integrating around a gap wastes the later passes.

Pro tip: Ask each teammate for a short structured report: files changed, contract touched, checks run, open questions. It turns this step into a checklist comparison.

Step 2: Check each output against its contract

For every task that crossed a boundary, compare the delivered code with the agreed signature, schema or type stub. Note any drift, even if it looks like an improvement, because other teammates built against the original. Decide per drift whether the contract changes or the code does. Record the decision so the fix is consistent everywhere the contract is used.

Pro tip: Diff the final interface files against the stubs committed before parallel work began; drift shows up immediately.

Step 3: Merge in dependency order

Integrate prerequisite work first: schemas and migrations, then shared types, then the services and components that consume them. Replace each mock with the real implementation it represented as you go. Build or type check after each merge rather than only at the end, so a failure points to the last thing you added. If a merge produces a textual conflict, stop and resolve it before continuing.

Step 4: Run cross-module checks

Once everything is merged, run the checks that span module boundaries: full builds, project-wide type checks, integration and end-to-end tests, and contract tests between services. These are the checks teammates could not run meaningfully inside their own slices. A failure here that did not appear in any teammate's local checks is almost always a seam problem. Trace it to the boundary before assigning blame to either side.

Pro tip: Keep a fixed validation command list for the team so the lead runs the same checks every round and results are comparable.

Step 5: Resolve conflicts at the lead level

Classify each problem as textual, semantic or a decision conflict. Fix small textual and semantic issues directly, since the lead already holds the cross-module picture. For decision conflicts, pick one convention, state why, and apply it everywhere rather than leaving both. When a fix belongs squarely inside one teammate's owned area and is non-trivial, issue a scoped rework task with the failing check attached.

Pro tip: Write rework tasks like original tasks: explicit scope, the failing check as the success criterion, and the files the teammate may touch.

Step 6: Run the acceptance review

Evaluate the integrated change against each task's success criteria and the objective as a whole. Run the programmatic checks first, then read the combined diff for things tests miss: duplicated helpers, dead code from abandoned approaches, inconsistent naming across modules. For high-risk changes, hand the combined diff to a reviewer role that did not implement any of it. Accept, send back, or discard each task explicitly.

Pro tip: If a reviewer teammate starts fixing things instead of reporting them, stop it; the value of review comes from staying independent of implementation.

Step 7: Record decisions and close out

Write a brief synthesis note: what was merged, which conflicts arose and how they were resolved, which contracts changed, and what was deferred. Mark every task in the shared list with its final state so nothing stays falsely open or falsely closed. Shut down teammates only after rework is complete. The note becomes the input for the next round's decomposition, showing where boundaries were drawn badly.

Best Practices

• Plan acceptance before parallel work starts. Criteria written during decomposition turn review into running checks; criteria invented after the fact tend to bend toward whatever was delivered.
• Read diffs, not just summaries. A teammate's summary reflects what it intended to do inside its own context window, while the diff shows what it actually changed, including edits outside its scope.
• Integrate incrementally in dependency order. Checking after each merge localizes failures to the last addition, which is far cheaper than bisecting a fully combined change.
• Keep the lead as the single arbiter of cross-cutting decisions. Letting two teammates negotiate a shared convention between themselves often produces a compromise that neither module was designed for.
• Separate review from implementation. An independent reviewer role that only reports findings preserves a quality check that the authors of the code cannot provide on their own work.
• Turn every non-trivial fix into a scoped task. Rework with explicit scope and a failing check as its success criterion converges quickly; vague feedback like fix the integration restarts the ambiguity that caused the problem.
• Log conflicts by boundary. Recurring conflicts at the same seam signal a decomposition problem to fix next time, not a teammate problem to fix this time.

Common Mistakes

• Treating green per-module tests as proof the change works.: Teammates' local tests only cover their slices. Always run full builds and integration tests on the combined change before accepting anything.
• Trusting the task list as the source of truth for completion.: Status can lag in both directions. Verify each task against its diff and scope before integrating, and fix the task state afterward.
• Quietly patching contract drift in the consuming module.: Drift means other teammates may have built against a different contract. Decide whether the contract or the code changes, record it, and apply the decision everywhere.
• Leaving two conventions in place because both work.: Inconsistent error handling or naming across modules becomes permanent maintenance cost. Pick one, state the reason, and apply it across the change.
• Letting the reviewer role implement its own fixes.: Once a reviewer edits code, nobody is independently checking that code. Have the reviewer report findings and route fixes to the owning teammate or the lead.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Claude Code Agent Teams

Related Skills

• Decomposing Tasks for Agent Teams
• Designing Agent Roles and Scopes
• Coordinating Inter-Agent Communication
• Parallelizing Independent Work Across Sessions
• Choosing Agent Teams Versus Subagents
• Managing Shared Task State

Sources

• Orchestrate teams of Claude Code sessions - Claude Code Docs
• Agent Teams Workflow - claude-code-ultimate-guide - GitHub
• Claude Code Architecture & Agent Loop | Claude Code Guide
• Claude Code Agent Teams: The Future of AI-Assisted Development
• What Is Anthropic Claude Code Agent Teams? How
• Agent Teams Workflow | Claude Code Guide
• Claude Code Multi-Agent Development Sample - GitHub

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.