Code Review

Code review in Agent Teams is task-centered. You inspect what changed for a specific task instead of hunting through a large unstructured diff.

Review surface

For each completed task that touched files, the review UI lets you:

• Inspect changed files with before/after context
• Accept or reject individual hunks
• Leave inline comments
• Connect the diff back to the task description and agent logs

Hunk-level decisions

Accept small correct changes and reject isolated mistakes without throwing away the whole task. This is useful when an agent mostly solved the task but overreached in one file.

Accept incrementally

If a diff is mostly correct, accept the good hunks first and request changes only for the parts that need fixing. This keeps the board moving.

Use hunk-level decisions for:

Situation	Action
Correct scoped change	Accept the hunk
Correct idea, wrong file or broad refactor	Reject the hunk and request a narrower fix
Unclear behavior change	Comment and ask for verification
Generated formatting noise	Reject unless formatting was part of the task

Initiating review

1. Open a completed task
2. Look at the Changes tab
3. If the diff looks reasonable, click Request Review to move the task into the review column

During review the task is not yet considered done, so other teammates or the lead can still comment on it.

Review loop

A healthy review loop looks like this:

1. The owner posts a result comment with changed scope and verification
2. The reviewer opens the task diff and checks hunks against the task description
3. The reviewer accepts good hunks, rejects bad hunks, or requests changes
4. The owner fixes only the requested scope and posts a follow-up comment
5. The reviewer approves when the task result and diff match

Example request-changes comment:

Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.

Review states

State	Meaning
none	Task is new, in progress, or completed but not yet in review
review	The task is actively under review
needsFix	Changes were requested; the owner must update before re-approval
approved	The review was accepted and the task is finalized

Agent review workflow

Teams can review each other's work before you make the final call. This catches obvious regressions and keeps the board honest, but you should still review risky areas yourself.

Agent review is most useful when the reviewer has a clear rubric. For example, tell a reviewer to check only docs clarity, only IPC safety, or only test coverage. Broad "review everything" requests tend to produce weaker feedback.

MCP-driven review state

Review state changes (request review, request changes, approve) are tool-driven. Leaving a "request changes" comment on a task does not move the kanban column to needsFix — a lead or agent must call the appropriate MCP tool:

• review_request_changes — moves the task to needsFix and notifies the owner
• review_approve — moves the task to approved and finalizes the review

Comments alone are insufficient for state transitions. For the full list of review MCP tools and their parameters, see MCP Integration.

Review participants

The team lead is the default reviewer. You can configure additional reviewers in the Kanban settings if you want peers to review each other's work.

What to check manually

Prioritize these areas when reviewing:

• Provider auth and runtime detection — did the agent change runtime setup in a way that would break other paths?
• IPC, preload, and filesystem boundaries — keep Electron responsibilities separated
• Git and worktree behavior - verify branch naming, commits, and pushes; see Git and worktree strategy for isolation patterns.
• Parsing and task lifecycle logic — changes to task references, chunking, or filtering can break message delivery
• Persistence and code review flows — changes to task storage or review state must stay consistent across IPC layers

For the canonical feature layout and hard guardrail links, use Contributor Architecture.

Verification

Prefer focused verification commands. Broad formatting or lint-fix commands should not be used unless the task explicitly intends broad formatting churn.

Good verification comments include the command and result:

Verified with `pnpm --dir landing docs:build`. Build passed.

When verification is skipped, the task comment should say why:

Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.

Do not auto-format across the whole project

Unless the task is specifically about formatting, avoid running pnpm lint:fix on unrelated files. It creates noise in the review surface.