118 lines
5.2 KiB
Markdown
118 lines
5.2 KiB
Markdown
---
|
||
title: Code Review – Agent Teams Docs
|
||
description: Inspect task-scoped diffs, accept or reject hunks, leave inline comments, and manage review states from none to approved.
|
||
---
|
||
|
||
# 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.
|
||
|
||
::: tip 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:
|
||
|
||
```text
|
||
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](/guide/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](/guide/git-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](/reference/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:
|
||
|
||
```text
|
||
Verified with `pnpm --dir landing docs:build`. Build passed.
|
||
```
|
||
|
||
When verification is skipped, the task comment should say why:
|
||
|
||
```text
|
||
Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.
|
||
```
|
||
|
||
::: warning 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.
|
||
:::
|