Turning a Confirmed Suspicion Into an Agent Handoff
Quick answer: After a suspicion is confirmed, the next step is not a loose chat prompt but a task package. The review exports a Markdown handoff that carries the confirmed suspicion, the related context, and revision anchors, and the receiving agent assesses each item independently before fixing it. This keeps the evidence gathered during review attached to the fix, and the agent works from the confirmed trigger rather than rediscovering the problem.
Why a handoff beats a fresh prompt
If the reviewer just types "fix the bug" into a coding assistant, the agent starts from nothing, re-reads the code, and may not reproduce the exact trigger the reviewer already confirmed. The context that made the suspicion real, the callers, the data, and the failing request, has to be rebuilt or gets lost.
The task package closes that gap. It is a structured export of the review work, so the agent receives the confirmed finding and the evidence with it and can move directly to a fix rather than re-deriving the problem.
What the package carries
| Part | Purpose |
|---|---|
| Confirmed suspicion | The specific defect and its trigger |
| Code anchor | The file and line where it sits |
| Related context | The block, symbols, and callers that decide it |
| Revision anchors | The diff points the fix is based on |
| Evidence | The request and output that confirmed it |
| Recommendation | The suggested fix, still open to assessment |
The revision anchors matter because they pin the handoff to the exact code state the reviewer read, so later edits do not silently change the basis.
Building the handoff
- Confirm the suspicion first, dismissing any false alarms rather than exporting them.
- Select the confirmed item and gather the related context and the code anchor.
- Attach the request and the raw output that reproduced the defect.
- Export the Markdown package with the revision anchors and the recommendation.
- Hand it to the coding agent, which assesses each suspicion independently.
- Confirm the resulting fix with the same request that exposed the defect.
Take a confirmed deletion-filter defect. The package names the trigger, anchors the line, includes the two callers and the request that shows the archived note removed, and pins the revision. The agent reads the confirmed trigger, adds the guard so only selected notes are removed, and the rerun request now keeps the archived note. None of that required the agent to re-litigate whether the defect was real, because the evidence was already in the package.
The independent-assessment boundary
The handoff is not an instruction to apply changes blindly. The receiving agent evaluates each suspicion on its own and can push back if the context no longer holds, and modification stays optional. This keeps the review and the fix as separate judgments, which is the same boundary that keeps an AI-only claim a hypothesis until evidence backs it.
Host tools are also controlled: write and danger actions run once only after an explicit confirmation, and the model cannot execute anything outside the fixed registry.
Powerduck exports the confirmed suspicion as a Markdown task package, keeping the context and the revision anchors with the handoff.
What not to hand off
The package is only for confirmed findings, and including dismissed or open suspicions weakens it. A false alarm that the reviewer already cleared should not be sent to the agent, because the agent may fix a problem that does not exist, and an unverified suspicion should not be presented as confirmed, since that hides the uncertainty. Keep the handoff to the items with reproducible evidence, and leave the open ones in the review record where their status is honest. Also avoid handing off the whole backlog of unrelated findings just because the export is convenient. A tight package of confirmed defects is more trustworthy than a broad one, and the agent's independent assessment works best when every item it receives is already backed by a real trigger. When in doubt, a smaller confirmed package is the safer choice, and the extra findings can wait for their own review.
Honest limits
The package is only as current as its anchors, and if the code moves underneath it, the agent has to re-check rather than apply the fix mechanically. Dynamic loading and external consumers can remain outside the captured context, and the review can still miss defects.
When the fix lands, verify it with a real request rather than trusting the agent's report, and keep anything unconfirmed open.
Frequently asked questions
What makes a handoff better than a prompt? It carries the confirmed trigger, context, evidence, and revision anchors instead of making the agent rediscover the defect.
Does the agent apply the fix automatically? It assesses each suspicion independently and can push back, with writes confirmed explicitly.
Why include revision anchors? To pin the handoff to the code state the reviewer read, so later edits do not change the basis.
The bottom line
Export confirmed suspicions as a Markdown task package with the trigger, context, evidence, and revision anchors, and let the receiving agent assess each item independently rather than apply a blind fix. The handoff preserves the review work so the agent starts from the confirmed defect, and the same request that exposed it confirms the fix. Keep it anchored to the code state and verify the result rather than trusting the report. Read more in the AI code review guide.