Retro agent files too many duplicate issues (33% dup rate)

[fullsend-ai-retro]

What happened

On 2026-05-26, the retro agent filed 15 issues against fullsend-ai/fullsend. Five of them (33%) were closed as duplicates of existing issues: #1459, #1458, #1456, #1455, #1454. These duplicated issues #1452, #1453, and others that were already open. Additionally, issue #1409 (filed by the retro agent itself) is titled "Investigate and fix systemic retro agent failures," indicating awareness of the problem.

What could go better

The retro agent should search for existing open issues before filing new ones. The current deduplication gap wastes human triage time — someone has to read each duplicate, find the original, and close it. Given the retro agent filed 15 issues in a single day, this creates meaningful noise.

Confidence: Medium. The retro agent may already have dedup instructions that aren't working well, or it may lack them entirely. I haven't inspected the retro agent definition to confirm. The 33% rate across 15 issues is a strong signal regardless.

Proposed change

In the retro agent definition (internal/scaffold/fullsend-repo/agents/retro.md) or the retro analysis skill, add an explicit deduplication step before filing: search for open issues with similar titles or labels using gh issue list --search '<keywords>' --state open, and skip filing if a substantially similar issue already exists. Consider adding a --label filter for the relevant agent/* or area/* labels to narrow the search space.

Validation criteria

The duplicate closure rate for retro-filed issues should drop below 10% over the next 2 weeks. Track by checking gh issue list --author 'fullsend-ai-retro[bot]' --label duplicate --state closed against total retro-filed issues.

---

Generated by retro agent from #1308

[fullsend-ai-triage]

Triage Summary

This issue is well-documented and actionable. The retro agent filed 15 issues on 2026-05-26, and 5 (33%) were closed as duplicates — a clear signal that the agent lacks a pre-filing deduplication check.

Key distinction from #1408: That issue addresses duplicate workflow dispatches (multiple retro runs triggered per PR merge). This issue addresses the agent's issue-filing logic — even with a single retro run, the agent doesn't check whether a similar issue already exists before filing.

Recommended Fix

Add an explicit deduplication step to the retro agent definition. Before filing each issue, the agent should search for existing open issues with similar titles/labels:

gh issue list --repo OWNER/REPO --search "<keywords from proposed title>" --state open --json number,title --limit 10

If a substantially similar issue is found, the agent should skip filing and optionally add a comment to the existing issue with any new context.

Proposed Test Case

Scenario: Retro agent skips filing when similar issue exists
  Given an open issue titled "Review agent should detect duplicate PRs"
  When the retro agent generates an observation about duplicate PR detection
  Then the agent should find the existing issue via search
  And skip filing a new issue
  And optionally comment on the existing issue with new context

Validation metric: duplicate closure rate for retro-filed issues < 10% over 2 weeks
Edge cases: similar-but-not-identical titles, closed issues (should not block filing)

---

Labels: Retro agent issue-filing behavior improvement, touching the agent definition and scaffold area.