What happened
On PR #2015, the review agent correctly identified a scope-tier-mismatch: the PR title used refactor(cli) but the change introduced new user-facing features (--fullsend-binary flag, three-tier acquisition policy, per-repo vendoring in github setup). The agent rated this MEDIUM and posted it as a COMMENT. The review squad (waynesun09) also flagged scope creep as MEDIUM. Despite both reviewers surfacing this, the human reviewer approved the PR and it was merged with the refactor(cli) prefix unchanged. Since GoReleaser uses conventional commit prefixes to generate release notes, a refactor prefix causes new user-facing features to be categorized incorrectly (or omitted from) the changelog.
What could go better
The review agent detected the right issue but used the wrong escalation level. A conventional commit prefix mismatch that would cause incorrect release notes is a process-integrity issue, not a style nit. When the commit prefix misrepresents the change type (e.g., refactor for a change that adds new CLI flags and user-facing behavior), the review agent should use changes_requested verdict rather than comment, since this directly affects downstream automation (GoReleaser changelog categorization). Confidence: high — the repo's CLAUDE.md explicitly states conventional commits are critical for GoReleaser, and the review agent's own finding correctly identified the impact but under-escalated it.
Proposed change
In the review agent's intent & coherence sub-agent definition (or the pr-review skill's finding-severity calibration), add a rule: when the conventional commit prefix (feat/fix/refactor/chore/docs/etc.) does not match the actual nature of the change — particularly when refactor or chore is used for changes that introduce new user-facing features — escalate to MEDIUM-HIGH or HIGH severity. The review orchestrator should treat conventional-commit-prefix mismatches as blocking findings (verdict: changes_requested) when the repo uses GoReleaser or similar prefix-dependent release tooling. This could be implemented as a check in the pr-review skill's verdict synthesis logic: if any finding has tag scope-tier-mismatch or similar, and the target repo's CLAUDE.md mentions conventional commits being used for release notes, the verdict should be changes_requested rather than comment.
Validation criteria
On the next 3 PRs where the review agent detects a conventional commit prefix mismatch, it should use changes_requested verdict instead of comment. The PR author should be required to either fix the prefix or justify why the current prefix is correct before the review agent approves.
Generated by retro agent from #2015
What happened
On PR #2015, the review agent correctly identified a scope-tier-mismatch: the PR title used
refactor(cli)but the change introduced new user-facing features (--fullsend-binaryflag, three-tier acquisition policy, per-repo vendoring ingithub setup). The agent rated this MEDIUM and posted it as a COMMENT. The review squad (waynesun09) also flagged scope creep as MEDIUM. Despite both reviewers surfacing this, the human reviewer approved the PR and it was merged with therefactor(cli)prefix unchanged. Since GoReleaser uses conventional commit prefixes to generate release notes, arefactorprefix causes new user-facing features to be categorized incorrectly (or omitted from) the changelog.What could go better
The review agent detected the right issue but used the wrong escalation level. A conventional commit prefix mismatch that would cause incorrect release notes is a process-integrity issue, not a style nit. When the commit prefix misrepresents the change type (e.g.,
refactorfor a change that adds new CLI flags and user-facing behavior), the review agent should usechanges_requestedverdict rather thancomment, since this directly affects downstream automation (GoReleaser changelog categorization). Confidence: high — the repo's CLAUDE.md explicitly states conventional commits are critical for GoReleaser, and the review agent's own finding correctly identified the impact but under-escalated it.Proposed change
In the review agent's intent & coherence sub-agent definition (or the pr-review skill's finding-severity calibration), add a rule: when the conventional commit prefix (feat/fix/refactor/chore/docs/etc.) does not match the actual nature of the change — particularly when
refactororchoreis used for changes that introduce new user-facing features — escalate to MEDIUM-HIGH or HIGH severity. The review orchestrator should treat conventional-commit-prefix mismatches as blocking findings (verdict:changes_requested) when the repo uses GoReleaser or similar prefix-dependent release tooling. This could be implemented as a check in the pr-review skill's verdict synthesis logic: if any finding has tagscope-tier-mismatchor similar, and the target repo's CLAUDE.md mentions conventional commits being used for release notes, the verdict should bechanges_requestedrather thancomment.Validation criteria
On the next 3 PRs where the review agent detects a conventional commit prefix mismatch, it should use
changes_requestedverdict instead ofcomment. The PR author should be required to either fix the prefix or justify why the current prefix is correct before the review agent approves.Generated by retro agent from #2015