What happened
Issue #191 referenced fullsend-ai/fullsend#2774 with the phrasing "since fullsend-ai/fullsend#2774 sandbox output is extracted to a temp dir." The triage agent (run 29480531709) echoed this in its summary — "Since fullsend#2774 changed sandbox output extraction to use a temp directory" — treating the upstream change as already landed. It labeled the issue ready-to-code and the code agent created PR #192. However, #2774 had not yet merged. The human reviewer caught the dependency 1.5 hours later, dismissed their review with "Blocked until fullsend#2774 gets merged," and had to manually re-trigger /fs-review 4 days later once #2774 landed. The triage agent already has Step 2b instructions covering cross-repo search and blocking-relationship detection, but did not exercise them on this reference.
What could go better
The triage agent's Step 2b already instructs it to check cross-repo references for blocking relationships (e.g., unmerged PRs that must land first). In this case, the agent identified the reference to #2774 but did not verify its merge status — it parroted the issue body's framing instead. Had the triage summary noted that #2774 was still open, the code agent's PR description could have included a dependency note, and the reviewer would have had immediate context rather than needing to discover it manually. Confidence: moderate. The triage agent has the instructions but the current Step 2b language frames cross-repo search as something to do "if the issue mentions upstream libraries, services, or other repositories" — it may not have triggered because the reference was embedded in a factual description rather than an explicit dependency claim. Alternatively, the agent may have attempted the check but the gh call failed silently due to access restrictions.
Proposed change
In agents/triage.md, strengthen the Step 2b cross-repo search instructions to make PR/issue merge-status verification an explicit, non-optional step. Specifically: (1) Add a concrete sub-step: "For every cross-repo PR or issue reference (e.g., org/repo#N) found in the issue body, check its current state with gh pr view N --repo org/repo --json state,merged or gh issue view N --repo org/repo --json state. If the referenced PR is not yet merged, note it as a potential blocking dependency in the triage summary and evaluate whether the issue should be marked blocked instead of ready-to-code." (2) Add guidance to avoid parroting the issue body's temporal framing — the triage agent should independently verify whether a described change has actually landed rather than assuming past-tense references are accurate.
Validation criteria
On the next 3 triage runs where the issue body references a cross-repo PR (pattern: org/repo#N or fullsend#N), the triage summary should include the merge status of the referenced PR. If the referenced PR is not merged, the summary should note the dependency. Verify by reviewing triage summaries on issues that reference upstream changes.
Generated by retro agent from #192
What happened
Issue #191 referenced
fullsend-ai/fullsend#2774with the phrasing "since fullsend-ai/fullsend#2774 sandbox output is extracted to a temp dir." The triage agent (run 29480531709) echoed this in its summary — "Since fullsend#2774 changed sandbox output extraction to use a temp directory" — treating the upstream change as already landed. It labeled the issueready-to-codeand the code agent created PR #192. However, #2774 had not yet merged. The human reviewer caught the dependency 1.5 hours later, dismissed their review with "Blocked until fullsend#2774 gets merged," and had to manually re-trigger/fs-review4 days later once #2774 landed. The triage agent already has Step 2b instructions covering cross-repo search and blocking-relationship detection, but did not exercise them on this reference.What could go better
The triage agent's Step 2b already instructs it to check cross-repo references for blocking relationships (e.g., unmerged PRs that must land first). In this case, the agent identified the reference to #2774 but did not verify its merge status — it parroted the issue body's framing instead. Had the triage summary noted that #2774 was still open, the code agent's PR description could have included a dependency note, and the reviewer would have had immediate context rather than needing to discover it manually. Confidence: moderate. The triage agent has the instructions but the current Step 2b language frames cross-repo search as something to do "if the issue mentions upstream libraries, services, or other repositories" — it may not have triggered because the reference was embedded in a factual description rather than an explicit dependency claim. Alternatively, the agent may have attempted the check but the
ghcall failed silently due to access restrictions.Proposed change
In
agents/triage.md, strengthen the Step 2b cross-repo search instructions to make PR/issue merge-status verification an explicit, non-optional step. Specifically: (1) Add a concrete sub-step: "For every cross-repo PR or issue reference (e.g.,org/repo#N) found in the issue body, check its current state withgh pr view N --repo org/repo --json state,mergedorgh issue view N --repo org/repo --json state. If the referenced PR is not yet merged, note it as a potential blocking dependency in the triage summary and evaluate whether the issue should be markedblockedinstead ofready-to-code." (2) Add guidance to avoid parroting the issue body's temporal framing — the triage agent should independently verify whether a described change has actually landed rather than assuming past-tense references are accurate.Validation criteria
On the next 3 triage runs where the issue body references a cross-repo PR (pattern:
org/repo#Norfullsend#N), the triage summary should include the merge status of the referenced PR. If the referenced PR is not merged, the summary should note the dependency. Verify by reviewing triage summaries on issues that reference upstream changes.Generated by retro agent from #192