What happened
On PR #1101 (fix skillsaw CI failures, linked to #1099), the code agent ran on Aug 31 17:19 UTC and correctly fixed all three skillsaw violations that existed at that time. Three hours later (Aug 31 20:21 UTC), PR #1085 merged into main, introducing skills/jira-components/SKILL.md — a new file with a content-description-routing violation. When the branch was rebased onto updated main, the human pushed a second commit to fix this new violation so the PR could achieve its stated goal of making skillsaw --strict pass.
The review agent then flagged this file as scope-creep: "This file is not mentioned in the linked issue #1099 or the PR body's change list... this change does not fix any existing CI failure." The finding was technically correct (the file was not in the issue) but contextually wrong — the file didn't exist when the issue was filed, and fixing it was necessary to achieve the PR's goal.
What could go better
The scope-authorization sub-agent evaluates scope by checking whether each changed file appears in the linked issue or PR body. This heuristic fails when a concurrent merge introduces new files that contain the same class of violation the PR is fixing. The sub-agent lacks temporal context — it cannot distinguish "file is unrelated to the issue" from "file was introduced after the issue was filed and now contains a violation that must be fixed to achieve the stated goal."
This is a moderate-confidence finding. The false positive had low practical impact here (low severity, PR already approved, did not trigger a fix agent). But for PRs where the review agent has more autonomy, a scope-creep flag on a necessary fix could cause a fix agent to incorrectly revert a valid change. The pattern will recur in any "fix CI" or "fix linting" issue where concurrent merges introduce new violations of the same type.
Related but distinct from #831 (soften findings when the linked issue is bot-authored) — that addresses authorship context, while this addresses temporal context of file introduction relative to issue creation.
Proposed change
Teach the scope-authorization sub-agent (or its prompt) to apply a softening heuristic when ALL of these conditions hold:
- The PR's stated goal is to fix a class of violations (CI failures, linting errors, etc.) rather than to implement a specific feature.
- A changed file was not present in the repo at the time the linked issue was created (i.e., the file was introduced by a merge to the base branch after issue creation).
- The change to the file is consistent with the same violation class the PR is fixing (e.g., adding "Use when" trigger phrasing when other files in the PR also add trigger phrasing).
When all three conditions hold, the sub-agent should either suppress the scope-creep finding or downgrade it to informational with a note explaining that the file was introduced by a concurrent merge and the change appears goal-aligned.
The specific implementation would be in the scope-authorization sub-agent's prompt or definition within the review agent's skill/harness configuration. The sub-agent already reads the linked issue and PR body — it would additionally need to check whether the flagged file existed at the issue's creation time (e.g., by checking git log --diff-filter=A -- <file> against the issue timestamp).
Validation criteria
On the next PR where a concurrent merge introduces a new file with the same class of violation being fixed, the scope-authorization sub-agent should either not flag the file as scope-creep, or should include a note acknowledging the concurrent-merge context. Validate by replaying this PR's scenario: a "fix CI" PR where a file introduced after issue creation contains the same violation type. The scope-creep finding should not appear at the same severity without temporal context.
Generated by retro agent from #1101
What happened
On PR #1101 (fix skillsaw CI failures, linked to #1099), the code agent ran on Aug 31 17:19 UTC and correctly fixed all three skillsaw violations that existed at that time. Three hours later (Aug 31 20:21 UTC), PR #1085 merged into
main, introducingskills/jira-components/SKILL.md— a new file with acontent-description-routingviolation. When the branch was rebased onto updatedmain, the human pushed a second commit to fix this new violation so the PR could achieve its stated goal of makingskillsaw --strictpass.The review agent then flagged this file as scope-creep: "This file is not mentioned in the linked issue #1099 or the PR body's change list... this change does not fix any existing CI failure." The finding was technically correct (the file was not in the issue) but contextually wrong — the file didn't exist when the issue was filed, and fixing it was necessary to achieve the PR's goal.
What could go better
The scope-authorization sub-agent evaluates scope by checking whether each changed file appears in the linked issue or PR body. This heuristic fails when a concurrent merge introduces new files that contain the same class of violation the PR is fixing. The sub-agent lacks temporal context — it cannot distinguish "file is unrelated to the issue" from "file was introduced after the issue was filed and now contains a violation that must be fixed to achieve the stated goal."
This is a moderate-confidence finding. The false positive had low practical impact here (low severity, PR already approved, did not trigger a fix agent). But for PRs where the review agent has more autonomy, a scope-creep flag on a necessary fix could cause a fix agent to incorrectly revert a valid change. The pattern will recur in any "fix CI" or "fix linting" issue where concurrent merges introduce new violations of the same type.
Related but distinct from #831 (soften findings when the linked issue is bot-authored) — that addresses authorship context, while this addresses temporal context of file introduction relative to issue creation.
Proposed change
Teach the scope-authorization sub-agent (or its prompt) to apply a softening heuristic when ALL of these conditions hold:
When all three conditions hold, the sub-agent should either suppress the scope-creep finding or downgrade it to informational with a note explaining that the file was introduced by a concurrent merge and the change appears goal-aligned.
The specific implementation would be in the scope-authorization sub-agent's prompt or definition within the review agent's skill/harness configuration. The sub-agent already reads the linked issue and PR body — it would additionally need to check whether the flagged file existed at the issue's creation time (e.g., by checking
git log --diff-filter=A -- <file>against the issue timestamp).Validation criteria
On the next PR where a concurrent merge introduces a new file with the same class of violation being fixed, the scope-authorization sub-agent should either not flag the file as scope-creep, or should include a note acknowledging the concurrent-merge context. Validate by replaying this PR's scenario: a "fix CI" PR where a file introduced after issue creation contains the same violation type. The scope-creep finding should not appear at the same severity without temporal context.
Generated by retro agent from #1101