diff --git a/.claude/skills/issue-pr/SKILL.md b/.claude/skills/issue-pr/SKILL.md index f78da3b88..ca1bcb7e9 100644 --- a/.claude/skills/issue-pr/SKILL.md +++ b/.claude/skills/issue-pr/SKILL.md @@ -14,7 +14,9 @@ This skill assumes the issue has already been triaged — the daemon only invoke ## 1. Read the ticket -Fetch it with `gh issue view --json title,body,labels,comments`. The bot's own triage comment (opens with "automated first-pass triage") already has the classification, priority, and any root-cause pointer — start from there rather than re-investigating from scratch. +Fetch it with `gh issue view --json title,body,labels,comments`. The bot's own triage comment (opens with "automated first-pass triage") already has the classification, priority, and any root-cause pointer — start from there rather than re-investigating from scratch. If it's labelled `bug` and the triage reached a full investigation, the comment also has a one-line statement of the fault right after the classification — use that as the precise claim to fix, not the reporter's (often vaguer) symptom description. If the issue carries any follow-up bot comments (opening with "automated follow-up triage review"), check the most recent one too — it may have restated, sharpened, or only just written that statement, and its version of the claim supersedes the first-pass one. A statement that a later bot comment retracted no longer counts. + +A `bug` label can arrive without that statement: the split and evidence gates (`/issue-triage` steps 1a and 1b) apply a type label and stop before any investigation. If no bot comment has a bug statement or a root-cause pointer, the fault hasn't been verified yet — don't fall back to the reporter's title or symptoms. Go to step 8 and say the issue needs a full triage (the follow-up review that the reporter's reply triggers) before a fix can be attempted. ## 2. Investigate diff --git a/.claude/skills/issue-triage-followup/SKILL.md b/.claude/skills/issue-triage-followup/SKILL.md index a9cfd972a..53c6daa23 100644 --- a/.claude/skills/issue-triage-followup/SKILL.md +++ b/.claude/skills/issue-triage-followup/SKILL.md @@ -50,11 +50,18 @@ Compare your updated understanding against the original triage comment's classif - If the classification, priority, or root-cause should change given the new information, update it. You may change or remove a label **you previously applied as the bot** (classification, priority, `waiting_for_user`) — never remove a label a human added. - Apply the same duplicate check as `/issue-triage` step 4 if the new information suggests one. +If the bot's most recent prior comment (the one you found in step 1) carries a one-line bug statement (`/issue-triage` step 3), that statement is a standing claim and this review must settle it rather than silently carry it forward or drop it — including when nothing material changed, one of: + +- **Still a bug** — restate the one-line statement in this comment, unchanged if the new evidence doesn't bear on it, updated if it sharpens or changes what the fault actually is. +- **Not a bug after all** — say so plainly, retract the statement, and give the corrected classification. This is the expected outcome when, as happened on #5390, a maintainer's own reply shows the reported behaviour is Predbat doing what the config says. + +If this review concludes the issue is a bug and there is no live statement to restate — the bot's most recent prior comment has none, or retracted one — write the one-line statement now, to the same standard as `/issue-triage` step 3. That covers this review changing the classification **to** `bug` (for the first time, or back to `bug` after an earlier follow-up retracted the statement), and this review confirming a `bug` label that an early-exit gate (`/issue-triage` step 1a or 1b) applied without investigating — those gates stop before step 3, so the first full investigation after one is where the statement gets written, even though the label is already there. A statement in an older comment that a later one retracted is not live, so it never stands in for a new one. + ## 5. Post one follow-up comment Check the comment history first: if the most recent comment is already a bot comment with nothing from a human posted after it, stop — this review already happened and nothing new has arrived since. -Post exactly one comment via `gh issue comment --body "..."`, opening with a line disclosing this is an automated follow-up triage review (a maintainer will review before any action is taken), followed by: what was new since the last review, whether the classification/priority/root-cause changed and why (or confirmation nothing changed), and any further information request. +Post exactly one comment via `gh issue comment --body "..."`, opening with a line disclosing this is an automated follow-up triage review (a maintainer will review before any action is taken), followed by: what was new since the last review, whether the classification/priority/root-cause changed and why (or confirmation nothing changed), the one-line bug statement from step 4 whenever one is restated, newly written, or retracted there — restated as-is if the new evidence didn't bear on it — and any further information request. Do **not** touch the `BOT_TRIAGED` or `BOT_REVIEW` labels — the daemon manages both. diff --git a/.claude/skills/issue-triage/SKILL.md b/.claude/skills/issue-triage/SKILL.md index 4ee59b0ee..80258d60c 100644 --- a/.claude/skills/issue-triage/SKILL.md +++ b/.claude/skills/issue-triage/SKILL.md @@ -73,11 +73,13 @@ A `predbat_debug.yaml` can also be replayed against current main to reproduce th Apply exactly one of: `bug`, `question`, `configuration` (user error/misconfiguration), `enhancement` (feature request). If genuinely ambiguous, apply `unclear` instead of guessing. +If you classify as `bug`, write a one-line statement of the bug in your own words — what Predbat actually does wrong, not the reporter's symptom description. State the faulty behaviour and, if you have one, the mechanism, e.g. "The dispatch-cancel check re-reads the car's live status instead of the status at cancel time, so a car that resumes charging a second later still loses its slot." A restatement of the title ("battery charging not working") is not acceptable. This line carries into step 9. + ## 4. Check for duplicates Search existing issues (`gh issue list --search ...`, both open and closed) for the same symptom. -- High confidence match: label `duplicate`, comment linking the original issue, and close this one. +- High confidence match: label `duplicate`, comment linking the original issue (including the step 3 one-line bug statement, if you wrote one), and close this one. - Low confidence: mention "possibly related to #N" in your triage comment; don't close. Then look for **similar** issues and PRs as well, whether or not they are duplicates: search both open and closed ones for the symptom, the integration and the component it touches (`gh issue list --state all --search ...` and `gh pr list --state all --search ...`). Read the findings in the best matches — what was diagnosed, what was fixed, and what was ruled out — before forming a hypothesis, and link the relevant ones in your triage comment as "related to #N". An issue that shares a symptom or a trigger is not necessarily the same problem: only call it a duplicate when the cause matches, not just the symptom, and treat a past finding as a lead to confirm against current main, not as a conclusion. @@ -106,6 +108,7 @@ Then look for **similar** issues and PRs as well, whether or not they are duplic - Form a root-cause hypothesis with a `file:line` pointer if the investigation supports one. It's fine to say the cause needs maintainer review if it doesn't. - You may edit files locally to test a hypothesis (e.g. a temporary debug print, a tweaked test fixture) — this clone is hard-reset and cleaned before the next run, so nothing here persists. Never `git commit` or `git push`. +- If this investigation changes your mind about step 3's classification — e.g. you classified `bug` but the investigation shows Predbat is doing what the config says — go back and revise it, and drop or rewrite the one-line bug statement to match. Don't let step 9 post a statement step 3 wrote before you knew better. ## 6. Apply component labels @@ -131,6 +134,8 @@ Check existing comments first — if one from you is already there, stop; don't Post exactly one comment via `gh issue comment --body "..."`, opening with a line disclosing this is an automated first-pass triage (a maintainer will review before any action is taken), followed by: classification, priority (if set), what you investigated and found (including test result if you ran one), a root-cause pointer if you have one, and any information request. +If you reached step 3 and classified as `bug`, lead with the one-line bug statement immediately after the classification. Gates 1a/1b apply a type label without ever reaching step 3, so there's nothing to include if you took one of those paths. + After posting, apply the `BOT_TRIAGED` label via `gh issue edit --add-label BOT_TRIAGED` — every triage run gets this label, including a duplicate-close, regardless of classification. It marks the issue as triaged for the separate PR-creation flow (see `.claude/skills/issue-pr/SKILL.md`). ## Guardrails