What happened
On PR #5203, the review agent's run on commit 702959b (run 29513518499) identified an internal contradiction in ADR-0027's table ("No effect" cells conflicted with the correction note) and suggested a specific remediation: "add strikethrough to the No effect cells to make the correction visually obvious."
The PR author followed this suggestion in the next commit. The subsequent review run on commit 1f63101 flagged the strikethrough as a [medium] adr-immutability-violation — directly contradicting the prior round's suggestion. This finding was then re-raised on commits c784795 (run 29571726147) and be083f8 (run 29573189003), totaling 3+ rounds of the agent flagging the result of following its own advice.
The root cause is architectural: pre-fetch-prior-review.sh extracts prior findings from only the "current section" of the sticky comment (content before the first <!-- sticky:history-start --> marker). Remediation suggestions from earlier rounds are collapsed into <details> history blocks and invisible to subsequent runs. The severity anchoring rules in meta-prompt.md match prior findings by function/class name to preserve severity, but have no concept of "this code implements a remediation I previously suggested."
What could go better
The review agent should maintain internal consistency across review rounds. When it suggests a specific remediation and the author implements it, the next review round should recognize the implementation rather than flagging it as a new violation.
This is distinct from the finding re-raising problem tracked in agents#106 (which focuses on author reply ingestion) and fullsend#2816 (which focuses on finding lifecycle management). The self-contradiction pattern has a different root cause: the agent loses track of its own prior recommendations when they're collapsed into sticky comment history sections.
Confidence: High that this is a real gap. The PR timeline provides a clear causal chain: suggestion in round N → implementation → contradictory finding in round N+1. The mechanism (history collapse hiding prior suggestions) is verified by reading pre-fetch-prior-review.sh and SKILL.md step 2a.
Uncertainty: This pattern may be relatively uncommon — it requires the agent to suggest a specific remediation that, when implemented, triggers a different dimension's finding. But when it does occur, it is highly frustrating for authors and erodes trust in the review system.
Proposed change
In skills/pr-review/SKILL.md, extend the prior-review parsing in Step 2a to extract remediation suggestions from both the current section AND the collapsed history sections of prior-review.txt. History sections are delimited by <!-- sticky:history-start --> and <!-- sticky:history-end --> markers.
Specifically:
-
Extract prior remediations: After parsing current-section prior findings, also scan history sections for finding objects that include suggested_fix or remediation fields. Build a "prior remediations" set: {finding_category, file, location, suggested_action}.
-
Add a reconciliation instruction to meta-prompt.md: After the severity anchoring rules, add: "If the current diff implements a change that matches a remediation suggested in a prior review round (including collapsed history), do not flag that change as a new violation. Instead, note it as 'addressed per prior review guidance' at info severity or omit it entirely."
-
Optionally extend pre-fetch-prior-review.sh: Extract and write a separate prior-remediations.txt file containing remediation suggestions from all history sections, so the agent has structured access without needing to parse the full sticky comment HTML.
Validation criteria
On the next 5 PRs where the review agent suggests a specific remediation and the author implements it in a subsequent commit:
- The follow-up review round should not flag the remediated code as a new violation of a different category
- If the reconciliation fires, the agent's reasoning trace should show it matched the current diff against a prior remediation suggestion
- The number of review rounds needed to reach a clean review should decrease by at least 1 compared to the baseline (no wasted round on self-contradictory findings)
Generated by retro agent from fullsend-ai/fullsend#5203
What happened
On PR #5203, the review agent's run on commit
702959b(run 29513518499) identified an internal contradiction in ADR-0027's table ("No effect" cells conflicted with the correction note) and suggested a specific remediation: "add strikethrough to the No effect cells to make the correction visually obvious."The PR author followed this suggestion in the next commit. The subsequent review run on commit
1f63101flagged the strikethrough as a[medium] adr-immutability-violation— directly contradicting the prior round's suggestion. This finding was then re-raised on commitsc784795(run 29571726147) andbe083f8(run 29573189003), totaling 3+ rounds of the agent flagging the result of following its own advice.The root cause is architectural:
pre-fetch-prior-review.shextracts prior findings from only the "current section" of the sticky comment (content before the first<!-- sticky:history-start -->marker). Remediation suggestions from earlier rounds are collapsed into<details>history blocks and invisible to subsequent runs. The severity anchoring rules inmeta-prompt.mdmatch prior findings by function/class name to preserve severity, but have no concept of "this code implements a remediation I previously suggested."What could go better
The review agent should maintain internal consistency across review rounds. When it suggests a specific remediation and the author implements it, the next review round should recognize the implementation rather than flagging it as a new violation.
This is distinct from the finding re-raising problem tracked in agents#106 (which focuses on author reply ingestion) and fullsend#2816 (which focuses on finding lifecycle management). The self-contradiction pattern has a different root cause: the agent loses track of its own prior recommendations when they're collapsed into sticky comment history sections.
Confidence: High that this is a real gap. The PR timeline provides a clear causal chain: suggestion in round N → implementation → contradictory finding in round N+1. The mechanism (history collapse hiding prior suggestions) is verified by reading
pre-fetch-prior-review.shandSKILL.mdstep 2a.Uncertainty: This pattern may be relatively uncommon — it requires the agent to suggest a specific remediation that, when implemented, triggers a different dimension's finding. But when it does occur, it is highly frustrating for authors and erodes trust in the review system.
Proposed change
In
skills/pr-review/SKILL.md, extend the prior-review parsing in Step 2a to extract remediation suggestions from both the current section AND the collapsed history sections ofprior-review.txt. History sections are delimited by<!-- sticky:history-start -->and<!-- sticky:history-end -->markers.Specifically:
Extract prior remediations: After parsing current-section prior findings, also scan history sections for finding objects that include
suggested_fixorremediationfields. Build a "prior remediations" set:{finding_category, file, location, suggested_action}.Add a reconciliation instruction to
meta-prompt.md: After the severity anchoring rules, add: "If the current diff implements a change that matches a remediation suggested in a prior review round (including collapsed history), do not flag that change as a new violation. Instead, note it as 'addressed per prior review guidance' at info severity or omit it entirely."Optionally extend
pre-fetch-prior-review.sh: Extract and write a separateprior-remediations.txtfile containing remediation suggestions from all history sections, so the agent has structured access without needing to parse the full sticky comment HTML.Validation criteria
On the next 5 PRs where the review agent suggests a specific remediation and the author implements it in a subsequent commit:
Generated by retro agent from fullsend-ai/fullsend#5203