From 008cec5427b6fb87c0b8ba6ff80fd8ace297f1d7 Mon Sep 17 00:00:00 2001 From: Jef Roosens Date: Tue, 2 Jun 2026 09:20:53 +0200 Subject: [PATCH] feat(claude): update skills to know about closed tickets --- .claude/skills/monthly-review/SKILL.md | 12 ++++++++++-- .claude/skills/weekly-review/SKILL.md | 22 ++++++++++++++++++---- project_map.json | 4 ++++ 3 files changed, 32 insertions(+), 6 deletions(-) diff --git a/.claude/skills/monthly-review/SKILL.md b/.claude/skills/monthly-review/SKILL.md index 640f8e0..aa6a134 100644 --- a/.claude/skills/monthly-review/SKILL.md +++ b/.claude/skills/monthly-review/SKILL.md @@ -138,7 +138,12 @@ the month was about and where the big threads landed, not the day-to-day. few plain sentences: what it was, how it progressed across the month's weeks, and where it ended the month (landed / merged / still in flight / handed off). Merge a theme that appears in several weekly summaries into one month-level - thread rather than repeating it per week. + thread rather than repeating it per week. To state where a thread ended with + confidence, check the backing story note's location in Joplin: a note in the + top-level `Work / Story Logs` is still active, one in + `Work / Story Logs / Archive / ` is finished (the user archives a story + log once its work is done). This confirms landed/closed vs still in flight + rather than guessing from the weekly prose alone. - **Recurring / continuous work** in a tighter list: bug-fixing load, the areas that came up repeatedly (specific subsystems), customer/incoming work, MCP/AI, security/ISMS, etc. Mirror the "Recurring areas" / "Continuous work" split in @@ -172,7 +177,10 @@ month. Cover these three lenses (and only these unless the user asks for more): or recurring-story lists and never closed within the month. - Repeated rework: rebases of the same big branch, repeated rounds of fixing the same failing tests or de-flaking the same suite (e.g. Cypress). - - Threads that opened early in the month and were still open at month end. + - Threads that opened early in the month and were still open at month end. A + thread is genuinely still open if its backing story note is still in the + top-level `Work / Story Logs`; if the note has moved to an archive + subnotebook it closed within the month, so do not list it as stuck. - These are candidates the user may want to push to close or escalate. 3. **Long weeks (only).** diff --git a/.claude/skills/weekly-review/SKILL.md b/.claude/skills/weekly-review/SKILL.md index c837044..344e4b7 100644 --- a/.claude/skills/weekly-review/SKILL.md +++ b/.claude/skills/weekly-review/SKILL.md @@ -96,8 +96,15 @@ described there. week, look for its backing note in `Work / Story Logs` (and `Work / Story Logs / Archive / `): list the notebook and/or `find_notes(" ")`, and match by ticket number. - Build a map of `ticket -> note_id` for every story that has a note. Read the - ones with real content. Note titles follow `PBI : ` / + Build a map of `ticket -> note_id` for every story that has a note, and record + **where** the note lives, because location signals whether the ticket is + finished: + - A note in the **top-level `Work / Story Logs`** notebook is an **active** + ticket: still in flight, not finished. + - A note in an **archive** subnotebook (`Work / Story Logs / Archive / <year>`) + is a **finished** ticket: the user archives a story log once its work is done. + + Read the ones with real content. Note titles follow `PBI <num>: <title>` / `Bug <num>: <title>`, or a descriptive title for research notes (e.g. "Recticel profiling research"). Many notes are near-empty section templates; link them but do not mine them for narrative. @@ -129,7 +136,11 @@ Then write the Summary: - For each significant theme, write a few plain sentences on what happened that week and where it landed. Convey the gist, not the precise detail (no exact percentages, config values, or internal symbol names; the story-log note holds - those). Someone reading it should know what the week was about. + those). Someone reading it should know what the week was about. Use the story + note's location (from step 2) to say whether the ticket finished: a ticket + whose note has moved to an archive subnotebook is done (say it landed / merged + / closed); one whose note is still in the top-level `Story Logs` is still + active, so do not imply it is finished. - Call out the shape of the week where it is real: a dominant feature, a heavy bug-fixing stretch, lots of context switching, an interruption (incoming requests, customer work like Recticel), or a spike/research day. @@ -199,7 +210,10 @@ Carry-over is the point of this section. Include: in the previous week(s) and are clearly still in flight (still being reviewed, rebased, "respond to comments", failing tests, etc.). Use judgement from the `Note` column; do not flag a story as carry-over just because the number - recurs. + recurs. The story note's location corroborates this: a note still in the + top-level `Story Logs` confirms the ticket is active and a real carry-over + candidate, while one already moved to an archive subnotebook is finished and + should not be listed as a loose end. - **Still-open todos** from the previous week note that were never checked off and are still relevant. diff --git a/project_map.json b/project_map.json index 243026d..367138b 100644 --- a/project_map.json +++ b/project_map.json @@ -57,5 +57,9 @@ "product": { "Project": "[Factry] Historian Product Development", "Task": "" + }, + "rect": { + "Project": "[Factry] Historian Product Development", + "Task": "Recticel Incoming Requests" } }