You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9a380e4
Browse filesBrowse the repository at this point in the historyBrowse files
CI
committed
Merge remote-tracking branch 'origin/main' into fix/smart-control-off-planned-slots-5339
Copy file name to clipboardExpand all lines: .claude/skills/issue-triage/SKILL.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,6 +80,8 @@ Search existing issues (`gh issue list --search ...`, both open and closed) for
80
80
- High confidence match: label `duplicate`, comment linking the original issue, and close this one.
81
81
- Low confidence: mention "possibly related to #N" in your triage comment; don't close.
82
82
83
+
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.
84
+
83
85
## 5. Investigate against current main
84
86
85
87
- Sync the clone first and discard anything left over from a previous run, so you are reading the code you think you are:
Copy file name to clipboardExpand all lines: .claude/skills/journal-update/SKILL.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ Arguments: `queue=<dir> limit=<n>`. Every `*.md` directly in that directory is o
18
18
19
19
Read it end to end before touching anything. You need to know what is already covered — most candidates restate something the journal says, and the right outcome for those is to drop them, or to sharpen the existing entry rather than add a second one.
20
20
21
-
Note its own "Adding to this file" section: name the symbol rather than the line number, cite the issue number, keep it short.
21
+
Note its own "What belongs here" and "Adding to this file" sections: keep techniques and traps, one-line device or API facts, and short dated findings that explain a class of report; leave per-issue narrative (what was tried, the fix, rejected alternatives) to the PR and issue. Name the symbol rather than the line number, cite the issue number, keep it short.
22
22
23
23
## 2. Verify every candidate against current main
24
24
@@ -32,7 +32,7 @@ For each candidate, check the claim still holds — grep the symbol it names, re
32
32
33
33
-**Fold it in** — place it in the right table row or section, rewritten in the journal's voice. Say what was verified and how.
34
34
-**Rewrite it** — the observation is real but the explanation was wrong or has been overtaken.
35
-
-**Drop it** — already covered, unverifiable, or fixed since. Dropping is a normal outcome; say so in the PR body with the reason.
35
+
-**Drop it** — already covered, unverifiable, fixed since, or a per-issue narrative that belongs in the PR or issue rather than the journal. Dropping is a normal outcome; say so in the PR body with the reason.
36
36
37
37
Anything the candidate flagged as suspected rather than verified stays marked that way, or comes out. Do not upgrade a hypothesis to a fact because it reads well.
Look for merges touching areas the journal makes claims about. For each, ask whether an existing entry is now wrong: a bug it calls "still live" that has been fixed, a line citation that has drifted onto unrelated code, a `confirmed on main (checked ...)` that a later merge has invalidated. Correct those in the same PR, and say plainly in the body which entries changed and why.
48
48
49
-
If a fix has landed, say so and keep the mechanism — "this was the bug, it was fixed in PR #N" is useful to a reader holding an older log. Do not simply delete the entry.
49
+
If a fix has landed, say so and keep the mechanism — "this was the bug, it was fixed in PR #N" is useful to a reader holding an older log. Cut the entry down to that rather than leaving the full story, and do not simply delete it. Where the code an entry describes has since changed, correct or delete the entry; do not leave it marked stale.
0 commit comments