Repository navigation
Triage bot: require a one-line bug statement, restated or retracted on follow-up - #5441
Merged
Merged
Conversation
… on follow-up The triage bot's bug declarations can bury the actual claim in prose, leaving the reporter's vague title as the only visible problem statement (#5390). Require a concise one-line statement of the fault whenever the bot classifies as bug, and require follow-up reviews to either restate or explicitly retract that statement rather than let it stand unexamined. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Early-exit gates (step 1a/1b) can label an issue bug without reaching step 3, so no one-line statement is ever written for them. Clarify the follow-up rule doesn't apply in that case, so the bot isn't told to hunt for a line that was never produced. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gates 1a/1b apply a type label without reaching step 3, so there is no one-line statement to carry into the comment on those paths. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tatement Tie the standing-claim check to the exact comment step 1 locates (rather than an implied scan of "any prior comment"), and require the statement to be restated even when unchanged, matching the existing "say so" rule for classification/priority/root-cause. The previous "if one is in play" wording let an agent skip the restate/retract on a round where new evidence happened not to touch the bug claim. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The restate/retract rule only fired when a prior comment already carried a statement, so a follow-up that newly reclassifies an issue to bug (from configuration/question/unclear) never wrote one - defeating the point for exactly the issues this feature exists to catch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A high-confidence duplicate close (step 4) runs after step 3 writes the one-line bug statement, but used its own terse comment template that never mentioned it - silently dropping the statement on exactly the close path step 9's full template doesn't reach. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…plit run-on step 9 sentence Step 5's investigation can show the step 3 classification was wrong (bug -> actually configuration), but nothing told the agent to revise or drop the now-stale one-line statement before step 9 posts it. Also split step 9's single run-on sentence so the bug-statement conditional isn't buried inside the general comment-content list. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
issue-pr builds its PR from the triage comment's classification, priority and root-cause pointer, but had no pointer to the new one-line bug statement - risking the PR summary restating the reporter's vague symptom instead of the verified fault. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ass one A follow-up review can write the first bug statement for an issue (on a reclassification) or supersede the original with a sharpened one. issue-pr's pointer only named the first-pass comment, so it could use a stale or absent claim when a follow-up comment is the real source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Moderate gaps remain for bug statements after early-exit gates and incomplete investigations.
2 open findings
What changed in this PR
This prose-only PR requires precise bot-authored bug statements throughout triage, follow-ups, and implementation workflows.
Changes:
- Adds one-line bug statement requirements.
- Handles restatements, retractions, duplicates, and reclassification.
- Directs implementation PRs to the latest verified statement.
| File | Summary |
|---|---|
.claude/skills/issue-triage/SKILL.md |
Defines initial bug statement requirements. |
.claude/skills/issue-triage-followup/SKILL.md |
Manages statement updates and retractions during follow-ups. |
.claude/skills/issue-pr/SKILL.md |
Points implementation work to the verified fault statement. |
🧠 Review effort: Lite
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
The split and evidence gates apply a type label without investigating, so a bug label can exist with no one-line statement. issue-pr now stops and asks for a full triage instead of falling back to the reporter's title, and issue-triage-followup writes the statement on the first full investigation that confirms the bug, even when the label is already there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… again The follow-up rule keyed on "no earlier bot comment has a statement", so an issue whose statement was retracted and that later went back to bug kept the stale, retracted one as cover. It now keys on whether there is a live statement to restate, and issue-pr ignores retracted statements. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The triage bot's
bugdeclarations can bury the actual claim in prose, leaving only the reporter's own (often vague) issue title as the visible problem statement — see #5390, where the bot's first-pass analysis read asbugin tone but the eventual verdict wasconfiguration, and a maintainer had to ask the reporter to "state the bug again" because the thread never had a crisp statement of what was supposedly wrong.This PR:
/issue-triageto write a concise one-line statement of the fault — in the bot's own words, not a restatement of the title — whenever it classifies an issue asbug./issue-triage-followupto explicitly restate or retract that statement on every later review, including when nothing else material changed, including on a reclassification tobug(first time, or back tobugafter a retraction, which needs a fresh statement), and including on a duplicate-close./issue-prat the same statement (first-pass or the latest follow-up, whichever is current) so an implementation PR targets the verified fault rather than the reporter's symptom description. If a gate applied thebuglabel and no investigation has produced a statement yet,/issue-prstops and asks for a full triage instead of falling back to the title. In that case the first follow-up review that confirms the bug writes the statement.Test plan
.claude/skills/*/SKILL.mdfiles — no executable code touched, no unit tests apply./code-review highlocally across 6 rounds of fix-and-re-review; every CONFIRMED/high-confidence finding from each round was fixed (gate-exclusion gaps, a soft escape-hatch wording, missing-statement-on-reclassify, duplicate-close silently dropping the statement, stale-statement-after-reinvestigation,issue-prmissing the pointer).bug-classified issue will be the first practical validation of the new wording.🤖 Generated with Claude Code