What happened
On PR #799, the review agent flagged uses: fullsend-ai/fullsend/.github/workflows/reusable-*.yml@feat-per-repo-installation as a critical finding in every single review run (12+ times). This is a standard development pattern: when developing reusable workflows, the uses: directives must point to the current branch for testing, and are updated to a stable tag (e.g., @main or @v1) before merge.
The review agent treated this as a critical/high severity issue every time, which caused the fix agent to be dispatched repeatedly (see the feedback loop analysis). The fix agent could not resolve this because the branch refs are intentional -- changing them to @main during development would break the PR's CI.
This was the single finding that drove the entire 11+ iteration feedback loop.
What could go better
The review agent should recognize that workflow uses: directives pointing to the PR's own branch are a development-phase pattern, not a bug. This is a high-confidence assessment: branch-name refs in uses: directives on a feature branch are standard practice for testing reusable workflow changes.
The fix is nuanced: the review agent should still flag branch refs that point to other branches (potential staleness) or that remain after the PR is approved (forgotten cleanup). But refs matching the PR's own head_ref should be downgraded from critical/high to informational, with a note like "These refs should be updated to a stable tag before merge."
Uncertainty: I'm less sure about the implementation location. This could be a review skill change (teaching the code-review skill about this pattern), a review agent definition change (adding it as context), or a repo-level .fullsend/review-config entry. The skill change is most universal.
Proposed change
Update the review agent's code-review skill or agent definition to include guidance on workflow uses: directives:
-
In the review skill's evaluation criteria (or the agent definition's review instructions), add: "When reviewing GitHub Actions workflow files, uses: directives that reference the PR's own branch (matching head_ref) are expected during development. Flag them as [info] with a reminder to update before merge, not as [critical] or [high]. Only flag branch refs as critical if they point to a branch other than the PR's head branch."
-
The review agent definition in fullsend-ai/.fullsend/agents/review.md should include this as a known pattern to avoid false positives.
This belongs in the .fullsend org config since it's specific to how this org develops reusable workflows, though it could be generalized upstream if other fullsend users follow the same pattern.
Validation criteria
On the next PR that modifies reusable workflow files and uses branch-name refs for testing, the review agent should flag the branch refs as [info] rather than [critical/high], and should not trigger CHANGES_REQUESTED solely based on this finding. Validate on the next 3 PRs that touch .github/workflows/reusable-*.yml.
Generated by retro agent from #799
What happened
On PR #799, the review agent flagged
uses: fullsend-ai/fullsend/.github/workflows/reusable-*.yml@feat-per-repo-installationas a critical finding in every single review run (12+ times). This is a standard development pattern: when developing reusable workflows, theuses:directives must point to the current branch for testing, and are updated to a stable tag (e.g.,@mainor@v1) before merge.The review agent treated this as a critical/high severity issue every time, which caused the fix agent to be dispatched repeatedly (see the feedback loop analysis). The fix agent could not resolve this because the branch refs are intentional -- changing them to
@mainduring development would break the PR's CI.This was the single finding that drove the entire 11+ iteration feedback loop.
What could go better
The review agent should recognize that workflow
uses:directives pointing to the PR's own branch are a development-phase pattern, not a bug. This is a high-confidence assessment: branch-name refs inuses:directives on a feature branch are standard practice for testing reusable workflow changes.The fix is nuanced: the review agent should still flag branch refs that point to other branches (potential staleness) or that remain after the PR is approved (forgotten cleanup). But refs matching the PR's own
head_refshould be downgraded from critical/high to informational, with a note like "These refs should be updated to a stable tag before merge."Uncertainty: I'm less sure about the implementation location. This could be a review skill change (teaching the code-review skill about this pattern), a review agent definition change (adding it as context), or a repo-level
.fullsend/review-configentry. The skill change is most universal.Proposed change
Update the review agent's code-review skill or agent definition to include guidance on workflow
uses:directives:In the review skill's evaluation criteria (or the agent definition's review instructions), add: "When reviewing GitHub Actions workflow files,
uses:directives that reference the PR's own branch (matchinghead_ref) are expected during development. Flag them as [info] with a reminder to update before merge, not as [critical] or [high]. Only flag branch refs as critical if they point to a branch other than the PR's head branch."The review agent definition in
fullsend-ai/.fullsend/agents/review.mdshould include this as a known pattern to avoid false positives.This belongs in the
.fullsendorg config since it's specific to how this org develops reusable workflows, though it could be generalized upstream if other fullsend users follow the same pattern.Validation criteria
On the next PR that modifies reusable workflow files and uses branch-name refs for testing, the review agent should flag the branch refs as [info] rather than [critical/high], and should not trigger
CHANGES_REQUESTEDsolely based on this finding. Validate on the next 3 PRs that touch.github/workflows/reusable-*.yml.Generated by retro agent from #799