Review and hand off a fix

The goal of review is not to approve a polished report. It is to decide whether the evidence supports a specific change and whether an implementer could verify that change without repeating the investigation.

You review and hand off from the incident's page: open incidents in the sidebar, then open the incident. Its Overview tab summarizes the report and its Recommended action; the Evidence tab holds the traces and source records; the Investigations tab lists every investigation run and opens each full report.

Follow one report through review

Suppose the investigation says:

Refund answers cite expired policies because the retrieval call does not receive the request date.

Before handing off work, the reviewer opens the failed and successful trace citations, confirms the earliest divergence, checks that the recommendation addresses it, and verifies that nearby behavior is protected.

The review can end in three ways:

Record the decision and its reason in a comment on the incident. When the work is not actionable at all, archive the incident: open the status menu in its sidebar, choose Archived, and confirm Archive fix? with Archive. Archived incidents stay available under Archived fixes on the Incidents page. Changing status can require the Project Member role; viewers should ask a project member or admin.

Review the report in five passes

1. Confirm the problem

Check that the report describes the same observed failure and expected behavior as the incident. A technically interesting explanation is irrelevant if it addresses a different symptom.

2. Open the strongest evidence

Follow citations to traces, spans, detection matches, Eval responses, comments, and connected sources. Confirm:

• the evidence belongs to the intended project, workflow, and period;
• the quoted content appears in the cited object;
• failed and successful runs are comparable;
• missing or contradictory evidence is acknowledged.

3. Challenge the root cause

Ask whether the cause explains the earliest meaningful divergence rather than restating the outcome.

Add counterexamples or authoritative business context when they could change the conclusion. Select report text and choose Comment to anchor a correction to the sentence it concerns, or use Comment under the title for the incident as a whole. To change the report itself, open the run on the Investigations tab and select Edit on the section, or use Give feedback to ask the AI to rewrite it or investigate again. Report edits are recorded on the Activity tab.

4. Check the recommended action

The action should:

• address the supported cause;
• state intended behavior;
• identify important constraints;
• avoid unrelated cleanup;
• leave implementation details open when the evidence does not determine them.

Reject a technically plausible recommendation when it does not solve the demonstrated failure.

5. Test the verification plan

A plan is useful only if it could reveal that the fix failed.

Require:

• the original failing cases;
• successful controls that must remain unchanged;
• important boundary cases;
• relevant Eval questions or deterministic checks;
• cost, latency, and error limits when affected;
• a production signal and monitoring window;
• a condition for reopening the incident.

Prepare the focused handoff

The handoff should contain the smallest complete implementation context. The report's Root cause, Evidence & reasoning, and Recommended action are the starting point for the fix brief; every hand-off destination receives them.

Problem: Refund answers can cite a retired policy.
Impact: Customers may receive an option support cannot honor.
Cause: request_date is omitted from the policy retrieval filter.
Evidence: Linked failed traces and successful control runs.
Intended change: Filter policy versions by request date.
Controls: Preserve current-policy and non-refund retrieval behavior.
Verify: Rerun linked failures and the policy-validity Eval.
Operational limits: No material latency increase.

Include evidence links rather than copying large payloads. Exclude secrets and irrelevant investigation transcript.

Choose and confirm the destination

The hand-off controls sit at the bottom of the incident. Fix in and Push to appear once an investigation has written a report for the incident.

An Open in agent receives the prompt prefilled; nothing runs until you submit it there. If the agent cannot accept a prompt through a link, Neatlogs copies it to your clipboard instead.

To dispatch a cloud run:

1. Select the arrow next to Fix in, then Cursor under Cloud Agent.
2. In Send to Cursor Background Agent, choose the Repository explicitly. It is prefilled from the project's repository when one is set, and lists only repositories your Cursor account can access.
3. Optionally set a Base ref and a Model.
4. Review Instructions. They are prefilled from the report; edit them to match the focused brief.
5. Select Dispatch.

Dispatching and pushing are available to anyone with access to the incident who has connected their own account. For run details, see Long-running agent sessions.

After sending:

1. confirm the task, agent run, or ticket exists;
2. verify the destination repository, team, or project is correct;
3. check that evidence and verification criteria survived;
4. check the incident's Activity tab, which records Coding task requested for a cloud run and Sent to Linear or Sent to Jira with the ticket identifier;
5. incidents have no assignee field, so add a comment on the incident that @mentions the person who owns the work and includes any external link.

Move from investigation to tracked work without losing the evidence or expected behavior.

Handing off work does not change the incident's status. It stays open until someone marks it resolved after verification.

Frequently asked questions

Does tracking an investigation result as an incident dispatch it?

No. Track as issue adds the result to Incidents. Handing off the fix is a separate action.

Can Neatlogs choose a repository automatically?

The cloud-agent dialog prefills the project's repository when one is set, but you confirm the Repository before dispatching. Do not rely on an inferred target.

What if no destination is configured?

Use Copy context and paste it into your normal workflow, or connect the destination yourself: Cursor under Settings → Account → Coding agents, Linear or Jira under Settings → Organization → Integrations. These connections belong to the person who connects them, so each teammate who hands off work connects their own account.

Can I edit the brief before sending it?

Yes. Edit Instructions in the Cursor dialog, or the title and description in the Linear or Jira dialog. To change the report itself, edit it from the Investigations tab or use Give feedback.

What if I disagree with the investigation?

Do not dispatch it. Add the contradictory evidence as a comment, then use Give feedback to revise the report or Investigate further to run again.

Next step

Verify the implemented change →