What happened
On PR #476, the fix agent flip-flopped on a design decision across iterations. In iteration 2 (Jul 27), the review agent suggested Setup section stubs were low-value, so the fix agent moved Setup to OPTIONAL_SECTIONS and removed stub sections from 6 docs. In iteration 4, the review agent pointed out the PR description said Setup was required while the code made it optional, so the fix agent reversed its iteration 2 change — moving Setup back to REQUIRED_SECTIONS and re-adding the stubs. Two of the five bot-cap iterations were spent oscillating on the same decision, and the fix agent did not recognize it was undoing its own prior work.
What could go better
The fix agent processes each review independently with no awareness of its own prior iteration actions. When two review findings pull in opposite directions ("make optional" vs. "description says required"), the fix agent follows each in turn without detecting the contradiction. This wastes iteration budget (2 of 5 bot-cap iterations on oscillation) and delays convergence. The pattern is likely to recur on complex PRs where the review agent raises competing architectural concerns across cycles. Confidence: HIGH — the oscillation is directly visible in the fix agent iteration comments (iteration 2 reported fixing Setup as optional, iteration 4 reported fixing Setup as required). Related but distinct from agents#564 (which addresses strategy escalation changing PR direction, not detecting diff-level oscillation).
Proposed change
In skills/fix-review/SKILL.md, step 4 (Plan fixes), add an oscillation guard: before finalizing each planned fix, the fix agent should examine the git log for prior fix-agent commits (identifiable by the fullsend-fix committer or iteration metadata). If the planned fix would revert or substantially undo a prior fix-agent change in the same file and function, the fix agent should: (1) flag this as a design disagreement between review iterations, (2) record a disagree action with reason explaining the oscillation, and (3) skip that fix to preserve the prior iteration's decision. This check should activate when FIX_ITERATION >= 2 and can use git log --author=fullsend-fix plus git diff against the prior fix commit to detect reversals.
Validation criteria
Review the next 5 PRs where the fix agent runs 3+ iterations across any repo using this skill. Verify: (1) no iteration reverts a change made by a prior fix-agent iteration without explicit human direction via /fs-fix, and (2) when the fix agent detects a potential oscillation, it records a disagree action and the iteration summary notes the design conflict rather than silently reversing.
Generated by retro agent from #476
What happened
On PR #476, the fix agent flip-flopped on a design decision across iterations. In iteration 2 (Jul 27), the review agent suggested Setup section stubs were low-value, so the fix agent moved Setup to
OPTIONAL_SECTIONSand removed stub sections from 6 docs. In iteration 4, the review agent pointed out the PR description said Setup was required while the code made it optional, so the fix agent reversed its iteration 2 change — moving Setup back toREQUIRED_SECTIONSand re-adding the stubs. Two of the five bot-cap iterations were spent oscillating on the same decision, and the fix agent did not recognize it was undoing its own prior work.What could go better
The fix agent processes each review independently with no awareness of its own prior iteration actions. When two review findings pull in opposite directions ("make optional" vs. "description says required"), the fix agent follows each in turn without detecting the contradiction. This wastes iteration budget (2 of 5 bot-cap iterations on oscillation) and delays convergence. The pattern is likely to recur on complex PRs where the review agent raises competing architectural concerns across cycles. Confidence: HIGH — the oscillation is directly visible in the fix agent iteration comments (iteration 2 reported fixing Setup as optional, iteration 4 reported fixing Setup as required). Related but distinct from agents#564 (which addresses strategy escalation changing PR direction, not detecting diff-level oscillation).
Proposed change
In
skills/fix-review/SKILL.md, step 4 (Plan fixes), add an oscillation guard: before finalizing each planned fix, the fix agent should examine the git log for prior fix-agent commits (identifiable by thefullsend-fixcommitter or iteration metadata). If the planned fix would revert or substantially undo a prior fix-agent change in the same file and function, the fix agent should: (1) flag this as a design disagreement between review iterations, (2) record adisagreeaction with reason explaining the oscillation, and (3) skip that fix to preserve the prior iteration's decision. This check should activate whenFIX_ITERATION >= 2and can usegit log --author=fullsend-fixplusgit diffagainst the prior fix commit to detect reversals.Validation criteria
Review the next 5 PRs where the fix agent runs 3+ iterations across any repo using this skill. Verify: (1) no iteration reverts a change made by a prior fix-agent iteration without explicit human direction via
/fs-fix, and (2) when the fix agent detects a potential oscillation, it records adisagreeaction and the iteration summary notes the design conflict rather than silently reversing.Generated by retro agent from #476