claude-code-session-manager 0.37.2 → 0.38.0

package/dist/index.html

@@ -7,7 +7,7 @@
     <link rel="preconnect" href="https://fonts.googleapis.com">
     <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
     <link href="https://fonts.googleapis.com/css2?family=Newsreader:ital,opsz,wght@0,6..72,400;0,6..72,500;0,6..72,600;0,6..72,700;1,6..72,400&family=Geist:wght@300;400;500;600;700&family=IBM+Plex+Mono:wght@400;500;600&display=swap" rel="stylesheet">
-    <script type="module" crossorigin src="./assets/index-uVGdpAGF.js"></script>
+    <script type="module" crossorigin src="./assets/index-CQqSHpIq.js"></script>
     <link rel="modulepreload" crossorigin href="./assets/monaco-editor-BW5C4Iv1.js">
     <link rel="stylesheet" crossorigin href="./assets/monaco-editor-BTnBOi8r.css">
     <link rel="stylesheet" crossorigin href="./assets/index-CD_LuJZF.css">

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-session-manager",
-  "version": "0.37.2",
+  "version": "0.38.0",
   "description": "Local cockpit for the Claude Code CLI — multi-tab terminal, full config surface, scheduler, voice dictation, and live observability.",
   "type": "module",
   "main": "src/main/index.cjs",

package/plugins/session-manager-dev/skills/develop/standards.md

@@ -88,6 +88,7 @@ Data-driven from 400+ scheduler runs: long hangs (not bad code) are the dominant
 - **Negative-assertion checks must exit 0 when clean.** A check that verifies the *absence* of something (a `grep` that should find nothing, "no leftover X", `diff` expecting no change) must return exit 0 on the clean case. A bare `grep` exits **1 on no-match** — so the *success* path surfaces as `is_error=true` and the verifier downgrades a perfect run to `needs_review`. Always invert: `if <detector>; then echo "HALT: <what was found>"; exit 1; fi; echo clean`. Never let the no-match/empty path carry the non-zero exit.
 - **Recover or annotate every error — don't strand a Traceback in the transcript.** The verifier downgrades an otherwise-perfect run to `needs_review` when a `Traceback`/`Error` appears with *no visible recovery within ~10 lines* (the `transcript_errors` heuristic — the single most common false-positive on green deliverables). Two executor habits cause it: (1) **throwaway probes that error** — an inline `python -c` with a quoting/f-string slip, a wrong kwarg, a bad path. When a probe errors, immediately re-run the corrected version *or* print one line `# expected/handled: <why>` right after, so recovery is adjacent. Don't move on leaving a bare error as the last thing in that step. Prefer a small temp `.py` file over a fragile multi-quote `python -c` one-liner (inline f-string errors are the top source of stranded tracebacks). (2) See the timeout rule below.
 - **An *expected* bounded-timeout (exit 124) must be annotated, not bare.** `timeout`-capping a genuinely long task you expect to hit the cap (a full-universe ingest, a long scan) is correct — but a bare `Exit code 124` reads as a failure to the verifier. Wrap it so the cap is a success-with-note: `timeout 120 <cmd> || { rc=$?; [ $rc -eq 124 ] && echo "hit time cap — idempotent/partial, rows persist incrementally; OK" || { echo "HALT: <cmd> failed rc=$rc"; exit 1; }; }`. (Distinguish 124 = expected cap from a real non-zero.) For work that legitimately needs longer than a safe cap, run it in the background and poll a bounded number of times rather than capping the foreground command.
+- **Polling remote CI/job status: never `sleep N && <cmd>`, and annotate the pending exit code.** The harness hard-blocks a `sleep` chained to another command (`Blocked: sleep 90 followed by: gh pr checks ...`) and that block lands in the transcript as a bare `is_error=true` — usually in the last 20% of the run, right where the verifier weighs errors most. To wait for a remote run, use the tool's own blocking watcher under a hard cap: `timeout 600 gh run watch <run-id> --repo <owner>/<repo> --exit-status`. Also note `gh pr checks` is a **negative-assertion-shaped command**: it exits `8` while checks are pending and `1` when a check failed or none are reported — so the ordinary "still running" path is non-zero. Wrap it so the expected cases print a clean token rather than a bare error: `if out=$(timeout 60 gh pr checks <n> --repo <r> 2>&1); then echo "CI GREEN"; else rc=$?; echo "gh pr checks rc=$rc (8=pending, 1=fail/none) — expected/handled"; fi`. (Incident: PRD 745 fixed PR #188's Lint + Docs-integrity failures, pushed, and CI went fully green — but its `sleep 20 && gh pr checks` (exit 8) and `sleep 90 && gh pr checks` (harness-blocked) sat unannotated at the very end of the transcript and the run was flagged despite a truthful PASS and a landed commit.)
 - **Finish so the verifier auto-clears you.** The scheduler appends a finish protocol that requires you to COMMIT your work and emit `SCHEDULER_VERDICT: PASS` (or `FAIL <reason>` + `exit 1`) as the literal last line. Honor it exactly: a *truthful* PASS plus a commit that landed during the run is what lets the verifier override incidental transcript noise (a grep hit containing "Error", a TDD red-phase run, a debug Traceback) instead of parking the job in `needs_review` for a human. A job that exits 0 with **uncommitted** changes, or with no PASS sentinel, is the #1 cause of needless `needs_review`. Never print PASS on a red gate — a lying PASS turns the verifier into a silent-failure shipper.
 - **Don't leak expected-error text into tool output.** The verifier pattern-matches transcript content for `Traceback`/`FAIL`/`Error:`. When a step is *expected* to error (a TDD red-phase test, an availability/existence probe, a "should raise" assertion), don't let the raw exception land verbatim — capture it and surface a clean token instead: `if python -c '…' 2>/dev/null; then echo PROBE_OK; else echo PROBE_ABSENT; fi`, or pipe the noisy run through a matcher that prints only `RED (expected)` / `GREEN`. When you retry a transient failure, re-run the **same command with the same description** — the verifier's self-recovery detector pairs a failed call with a later identical-description call that succeeds and clears it.
 - **End green: run the acceptance/test gate LAST, and let nothing error after it.** The post-run verifier scans the transcript and downgrades to `needs_review` on error markers — and weighs the *final* portion of the run most heavily (a tool error in the last ~20% trips it even if everything actually passed). So order the run so the last command is the green AC gate: do any intentionally-failing step (e.g. a TDD red test, an expected-nonzero probe) **early**, never after the gate. If you must demonstrate a failure late, capture it so it doesn't surface as a raw `is_error`/`Traceback` (`… 2>&1 | tail` inside a conditional, or assert on the captured text) rather than letting it hit the transcript bare.

package/plugins/session-manager-dev/skills/issue-address/0-select/0-fetch-pool/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: issue-address:select:fetch-pool
+description: Fetch the FULL open-issue pool on the current project's repo with bodies, with verified completeness (not just a fixed --limit guess). First sub-step of issue-address:select.
+---
+
+# issue-address:select:fetch-pool
+
+## Steps
+
+1. **Fetch with a generous limit, then verify nothing was truncated** — don't trust a
+   single fixed `--limit` the way an earlier version of this skill (and, separately,
+   `pr-review-sweep`'s original GraphQL query) did; both silently truncated real data on
+   this repo before. Converge instead of guessing:
+   ```bash
+   LIMIT=100
+   while true; do
+     COUNT=$(gh issue list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --limit "$LIMIT" --json number --jq 'length')
+     if [ "$COUNT" -lt "$LIMIT" ]; then break; fi   # got everything — count came in under the cap
+     LIMIT=$((LIMIT * 2))                            # cap was hit exactly — double and re-check
+   done
+   gh issue list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --limit "$LIMIT" \
+     --json number,title,body,labels,assignees,comments,createdAt,reactionGroups
+   ```
+   `COUNT == LIMIT` is the tell that you hit the ceiling, not the true end of the list —
+   never treat that as "done." Only stop once a fetch returns fewer results than it was
+   capped at.
+
+2. **Fetch bodies, not just titles.** Title-only scanning is what let issue #180 get
+   picked without anyone reading its file/line citations first. `body` and `comments` are
+   required output fields, not optional — the next sub-steps depend on them.
+
+3. **Also fetch `reactionGroups`** (👍/👎 counts) — a real, if imperfect, community-signal
+   input for `issue-address:select:rank-impact` later, beyond just label text.
+
+## Output
+
+The full, verified-complete list of open issues with bodies, labels, assignees, comments,
+and reaction counts — handed to `issue-address:select:reject-fixed` next.

package/plugins/session-manager-dev/skills/issue-address/0-select/1-reject-fixed/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: issue-address:select:reject-fixed
+description: Reject candidates from issue-address:select:fetch-pool's pool that are already fixed in current code, by checking the actual file/behavior each issue cites against a freshly-fetched origin/main — semantically, not just a literal string grep. Second sub-step of issue-address:select.
+---
+
+# issue-address:select:reject-fixed
+
+The check that would have caught issue #180 before any other work started — its body
+cited `apps/web/app/app.css` around specific line numbers, and the current code already
+had the exact fix (`min-width: 0`) the issue was reporting the absence of.
+
+## Steps
+
+0. **Fetch fresh before checking anything.** `git fetch origin main` first, and read
+   against `origin/main`, not a local branch — a local checkout can be stale or on an
+   unrelated feature branch, and a stale read produces a false "still broken" verdict.
+   (Found live: `#194` looked unfixed against a stale local branch, but `origin/main` had
+   merged the fix days earlier.)
+
+1. **For each candidate whose body cites a specific file, line, function, or CSS
+   selector/rule**, read the actual current code at that location:
+   ```bash
+   git show origin/main:<cited-path> | sed -n '<start>,<end>p'
+   ```
+   or grep for the cited selector/function name if line numbers have drifted (files get
+   reorganized — issue #180's citation was for `apps/web/app/app.css`, which had since
+   been split into `apps/web/app/styles/*.css`; searching by class/function name across
+   the styles directory found the real current location).
+
+2. **Check the behavior semantically, not just for the literal string the issue used.** A
+   fix can land in a different code *shape* than the issue's own words. (Found live: `#57`
+   asked for a `<link rel="canonical">` tag; a literal grep for `rel="canonical"` found
+   nothing, so the naive check would have called it unfixed — but the actual fix was a
+   data-driven React Router `meta()` descriptor, `{ tagName: 'link', rel: 'canonical', href
+   }`, which produces the same tag at render time without ever containing that literal
+   string in source.) Before concluding "not fixed" on a bare grep miss:
+   - Search one level broader — the surrounding directory/module, a shared
+     helper/util file, a `meta.ts`/`config.ts`-style indirection layer — for the *behavior*
+     the issue describes, not just its exact wording.
+   - If the issue names a concrete symptom (a missing tag, a wrong computed value, a
+     missing gate), look for whatever code *produces* that output, however it's
+     structured, before deciding the symptom is still present.
+
+3. **Compare what the issue describes as broken against what the code currently does.**
+   If the issue's own hypothesized fix (or an equivalent one, per step 2) is already
+   present — reject, log as `already-fixed`, cite the exact current file:line as evidence.
+   Don't spend a full `issue-address:reproduce` pass confirming what a direct code read
+   already answered.
+
+4. **If the citation is vague, or the file has moved/renamed and a reasonably broadened
+   search (step 2) still finds nothing**, don't reject on inconclusive evidence — mark the
+   candidate `unconfirmed` and let it pass through to the next sub-step. This step only
+   rejects on positive evidence of an existing fix, never on failure-to-locate.
+
+5. **If the git history around that file shows the fix landed suspiciously close to the
+   issue's `createdAt`** (within a day or two, either direction), note that explicitly —
+   it's a strong signal the report and the fix crossed in flight (exactly what happened
+   with #180: fix committed 2026-06-29, issue filed 2026-06-30).
+
+## Output
+
+Two lists: `already-fixed` (rejected, with evidence) and `survives` (candidates to pass to
+`issue-address:select:reject-claimed` next, tagged `unconfirmed` where this step couldn't
+conclusively check).

package/plugins/session-manager-dev/skills/issue-address/0-select/2-reject-claimed/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: issue-address:select:reject-claimed
+description: Reject candidates already covered by a PR (open, OR closed-but-superseded-by-a-merged-successor) or already claimed by an assignee/comment/supersede-note — with every text-search hit manually confirmed before being trusted. Third sub-step of issue-address:select.
+---
+
+# issue-address:select:reject-claimed
+
+## Steps
+
+1. **Search for a PR that might already cover each surviving candidate — open AND
+   closed, not just open:**
+   ```bash
+   gh pr list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state all --search "<N> in:body"
+   gh api search/issues -f q='repo:$(gh repo view --json nameWithOwner -q .nameWithOwner) is:pr <N>'
+   ```
+   Also skim PR titles for matching subject matter (same file area, same symptom) — a PR
+   can fix an issue's bug without a formal `Closes #N` link. Searching only `state:open`
+   misses the real case found live: `#194` had two closed (not merged) PRs, `#203`/`#215`,
+   each superseded — but the actual fix landed in a *third*, later PR (`#251`) that neither
+   text-search-by-issue-number pass would find unless the closed ones are read first and
+   followed to what replaced them (step 3).
+
+2. **Never trust a text-search hit without reading it.** This already produced a false
+   positive once: searching `"180 in:body"` matched PR #239 ("add automated price-anomaly
+   screen"), which had nothing to do with issue #180 — the digit string almost certainly
+   matched a line number or unrelated number elsewhere in that PR's body. For every
+   text-search hit:
+   - Open the matched PR's actual title + description.
+   - Confirm it genuinely addresses the same file area / same symptom the issue describes
+     — not just that the issue number appears somewhere in the text.
+   - If it's a false positive (number coincidence, unrelated context), **discard the match
+     and keep the candidate as unclaimed** — don't reject on a search artifact.
+
+3. **For every closed-but-not-merged PR found in step 1, read its closing comment before
+   deciding the candidate survives.** A PR closed without merging is not automatically
+   "unclaimed again" — read why it closed:
+   ```bash
+   gh pr view <PR#> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --json state,mergedAt,closedAt,comments
+   ```
+   - If the closing comment says the work was split/replaced ("затварям... но не защото
+     работата е отпаднала", "closing in favor of #N", "superseded by #N", "merged into
+     #N"), **follow the chain to whatever PR(s) it names**, and check *their* merge state
+     the same way. Keep following until you reach a terminal state (merged = reject as
+     already-fixed; still open = reject as already-covered; abandoned with no successor =
+     candidate survives).
+   - This chain can be more than one hop deep (found live: `#194`'s PR `#203` was split
+     into `#251`/`#252`/`#253`; a sibling PR `#215` was independently closed in favor of
+     the same `#251`) — don't stop at the first successor if its own comments point
+     further.
+
+4. **Reject candidates already claimed by a person, or already noted as superseded in the
+   issue's OWN comments** (not just a linked PR's). Check `assignees` (non-empty =
+   explicit claim) and skim the issue's `comments` for:
+   - Claim language: "работя по това", "assigned to me", "I'll pick this up".
+   - Supersede/decompose language: "предлагам да се затвори в полза на", "closing in
+     favor of", "split into #N / #M / #P", "superseded by". (Found live: `#154`'s own
+     comment thread explicitly proposed closing it in favor of child issues `#156`/`#158`/
+     `#163` — a signal that lives in the issue's comments, not in any PR search at all.)
+   Reject on either signal — don't take work someone else already started or already
+   restructured, even informally.
+
+5. **Search for a duplicate open issue** describing the same underlying bug under a
+   different number — `gh issue list --state open --search "<keywords>"`, same
+   confirm-before-trusting rule as step 2 applies here too. If a better-established
+   duplicate exists, flag it rather than silently picking one.
+
+## Output
+
+`survives` list (candidates cleared of PR/claim/supersede/duplicate overlap — including
+resolved multi-hop PR chains — with any false-positive search hits explicitly noted as
+discarded) handed to `issue-address:select:rank-impact`.

package/plugins/session-manager-dev/skills/issue-address/0-select/3-rank-impact/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: issue-address:select:rank-impact
+description: Rank surviving candidates by a composite impact signal (priority label + community reactions + cross-references + repro quality), not label text alone, and output exactly one issue number. Final sub-step of issue-address:select.
+---
+
+# issue-address:select:rank-impact
+
+## Steps
+
+1. **Score each surviving candidate on multiple signals, not just its `priority:` label**
+   (a label-only heuristic silently mis-ranks an unlabeled-but-severe issue below a
+   labeled-but-minor one):
+   - **Priority label**: `high` > `medium` > `low` > none (weakest single signal alone).
+   - **Category label**: `bug`/`security`/`data-quality` outrank `enhancement`/
+     `discussion`/`docs` for this skill's purpose (fixing something broken, not building
+     something new).
+   - **Community reaction count** (from `fetch-pool`'s `reactionGroups`) — more 👍 reactions
+     is a real signal of user-felt impact independent of whatever label was applied at
+     triage time.
+   - **Cross-references** — check `gh issue view <N> --json timelineItems` (or equivalent)
+     for how many other issues/PRs reference this one; a heavily-cross-referenced issue is
+     blocking or informing other work, raising its effective priority above its label.
+   - **Repro quality** — concrete repro steps / cited file-line locations beat a vague
+     report; cheaper to reproduce reliably, lower risk of another #180-style dead end.
+
+2. **Combine into a ranked order** — no single signal should override all others (e.g.
+   don't let one 👍 reaction alone outrank an explicit `priority: high` label; use
+   priority + category as the primary sort, reaction count + cross-references as
+   tie-breakers within a tier, repro quality as the final tie-breaker).
+
+3. **Output exactly one issue number** — the top of the ranked list — with a one-line
+   justification citing which signals won, plus the full ranked list (not just the
+   winner) and the rejected list from the earlier two sub-steps, so the whole selection
+   is auditable, not just its conclusion.
+
+## Output
+
+Hand off the single selected issue number to `issue-address:confirm-open`, which
+re-verifies it fresh (state, PR/duplicate claims) immediately before work starts.

package/plugins/session-manager-dev/skills/issue-address/0-select/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: issue-address:select
+description: Step 0 of issue-address — select exactly ONE open issue on the current project's repo to work, by orchestrating 4 nested sub-skills (fetch-pool, reject-fixed, reject-claimed, rank-impact) in sequence. Only invoked when the caller hasn't already named a specific issue number.
+---
+
+# issue-address:select (sub-orchestrator)
+
+Only runs when `issue-address` is invoked without a specific issue number already named
+(if the caller already has one, skip straight to `issue-address:confirm-open` — that step
+re-verifies the single chosen issue right before work starts, as a freshness guard; this
+skill's job is choosing which issue out of many, cheaply and verifiably, across the whole
+pool).
+
+Exists because of a real incident: issue #180 was picked by title/label alone, and 2 full
+`issue-address` steps ran before discovering — only once `issue-address:reproduce`
+actually tried to reproduce it — that the fix had already shipped a day before the issue
+was even filed. The information needed to catch that (the issue's own cited file/line + a
+grep of current code) was available for free at selection time and simply wasn't checked.
+
+This skill is itself further decomposed into 4 nested sub-skills, for the same reason
+`issue-address` is decomposed: so each check is independently invokable and its result
+inspectable, instead of one opaque scan-and-pick pass. It also closes two gaps found after
+the first version shipped: an unverified fetch limit (the same class of silent-truncation
+bug that hit `pr-review-sweep`), and an unconfirmed PR-search false positive (seen live in
+the #180 trial — a text search on "180" matched an unrelated PR by number coincidence).
+
+**Naming convention:** sub-directories are prefixed `0-`, `1-`, `2-`, `3-` in execution
+order (see `issue-address/SKILL.md` for the repo-wide rule) — a plain directory listing of
+this folder sorts in DAG order without opening any file.
+
+## Pipeline DAG
+
+```
+open-issue pool
+      │
+      ▼
+┌─────────────────────────────┐
+│ 0. select:fetch-pool         │  verified-complete fetch (no silent truncation)
+└─────────────────────────────┘
+      │ full pool w/ bodies, labels, assignees, comments, reactions
+      ▼
+┌─────────────────────────────┐
+│ 1. select:reject-fixed       │  grep current code at each cited file/line
+└─────────────────────────────┘
+      │ survives (already-fixed candidates dropped, evidence logged)
+      ▼
+┌─────────────────────────────┐
+│ 2. select:reject-claimed     │  PR-search hits confirmed, not trusted blind
+└─────────────────────────────┘
+      │ survives (PR'd/claimed/duplicate candidates dropped, evidence logged)
+      ▼
+┌─────────────────────────────┐
+│ 3. select:rank-impact        │  composite score, not label text alone
+└─────────────────────────────┘
+      │
+      ▼
+one issue number + full audit trail (ranked list, rejected list, why)
+      │
+      ▼
+issue-address:confirm-open  (next skill up the chain, outside this sub-orchestrator)
+```
+
+| Step | Input | Output | On failure/empty |
+|---|---|---|---|
+| 0. `select:fetch-pool` | none (repo-wide `gh issue list`) | full open-issue pool, verified-complete | n/a — loops its own fetch until verified complete |
+| 1. `select:reject-fixed` | full pool | `already-fixed` list (w/ evidence) + `survives` list | if pool empties out here, report "no candidates, all already fixed" |
+| 2. `select:reject-claimed` | `survives` from step 1 | `already-claimed` list (w/ evidence) + `survives` list | if pool empties out here, report "no candidates, all claimed/PR'd" |
+| 3. `select:rank-impact` | `survives` from step 2 | one issue number + ranked list + justification | if `survives` was already empty, report the empty pool rather than fabricating a pick |
+
+## Output
+
+Hand off the single selected issue number to `issue-address:confirm-open`, which
+re-verifies it fresh (state, PR/duplicate claims) immediately before work starts — this
+skill's checks are about narrowing a big pool cheaply and verifiably; confirm-open's
+checks are about not acting on stale information for the one issue actually chosen.

package/plugins/session-manager-dev/skills/issue-address/1-confirm-open/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: issue-address:confirm-open
+description: Step 1 of issue-address — confirm a named GitHub issue on the current project's repo is genuinely OPEN and not already claimed/fixed by another PR or duplicate issue, before any work starts. Returns a clear go/no-go.
+---
+
+# issue-address:confirm-open
+
+Called with one issue number `<N>`. Produces a go/no-go verdict before any code work begins.
+
+## Steps
+
+1. **Fetch the issue.**
+   ```bash
+   gh issue view <N> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --json state,title,body,comments,url
+   ```
+   If `state` is not `OPEN` — **stop, no-go.** Report the actual state (closed/merged
+   reference) and why. Do not proceed to reproduce or fix a closed issue.
+
+2. **Search for an existing open PR that already covers it** — check both explicit links
+   and subject-matter overlap, since a PR can fix the bug without a formal `Closes #N`:
+   ```bash
+   gh pr list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --search "<N> in:body"
+   gh api search/issues -f q='repo:$(gh repo view --json nameWithOwner -q .nameWithOwner) is:pr is:open <N>'
+   ```
+   Also skim open PR titles for matching subject matter (same file area, same symptom).
+   If found — **stop, no-go.** Report which PR number and why it looks like a match; don't
+   duplicate work already in flight.
+
+3. **Search for a duplicate open issue** covering the same underlying bug (different
+   number, same root cause) — `gh issue list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --search
+   "<keywords>"`. If a duplicate exists and is a better-established report, flag it — the
+   caller decides which one to actually work.
+
+4. **Verdict.** Return one of:
+   - **GO** — issue is open, unclaimed, no duplicate blocking it. Include the issue title,
+     body, and any repro steps mentioned in comments, so the next step doesn't have to
+     re-fetch them.
+   - **NO-GO** — state why (closed / already covered by PR #X / duplicate of #Y), and stop
+     the whole `issue-address` sequence here. Do not continue to reproduce/fix.

package/plugins/session-manager-dev/skills/issue-address/2-claim/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: issue-address:claim
+description: Step 2 of issue-address — claim a confirmed-open, confirmed-unclaimed issue on the current project's repo before reproducing/fixing it, by self-assigning and posting a claim comment via the gh CLI (no dedicated GitHub MCP server is connected in this environment — gh is the actual mechanism). Closes the race condition where two runs could pick the same issue.
+---
+
+# issue-address:claim
+
+Runs immediately after `issue-address:confirm-open` returns GO, and before
+`issue-address:reproduce` starts any work. Exists because confirming an issue is
+open/unclaimed and then *starting work on it* are two different moments in time — without
+an explicit claim in between, a second concurrent run of this same skill (or a human
+contributor) could pick the same issue, and nothing in `issue-address:select`'s
+`reject-claimed` check would have caught it, since that check only looks for assignees and
+existing claim-language comments — which don't exist yet for an issue nobody has started.
+
+**No dedicated GitHub/issue-tracking MCP server is connected in this environment** — every
+GitHub interaction in this whole skill chain (and everywhere else this session) goes
+through the `gh` CLI via Bash. If a GitHub MCP server becomes available later, swap the
+commands below for its equivalent calls; until then, `gh` is the actual mechanism, not a
+gap to work around.
+
+## Steps
+
+1. **Self-assign**, so the issue shows a claim to anyone else's `select:reject-claimed`
+   pass or manual look:
+   ```bash
+   gh issue edit <N> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --add-assignee "@me"
+   ```
+   If self-assignment fails (e.g. insufficient repo permissions — a common case for
+   external contributors on a repo they don't have write access to), don't halt the
+   sequence on that alone; fall back to step 2's comment as the claim signal, and note in
+   the report that assignment wasn't possible so a human knows to check.
+
+2. **Post a claim comment** — visible even to someone who doesn't check assignees,
+   and consistent with the claim-language `select:reject-claimed` already scans for
+   ("I'll pick this up", "working on this"; a project with a non-English contributor base,
+   e.g. `midt-bg/sigma`'s Bulgarian-speaking reviewers, may localize this string — check
+   the project's own `AGENTS.md`/`CLAUDE.local.md` for a house phrase before defaulting to
+   English):
+   ```bash
+   gh issue comment <N> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --body "Working on this issue (issue-address skill chain). Will link the PR here after fix + verify."
+   ```
+
+3. **Re-confirm the claim actually landed** before proceeding — read the issue back and
+   check the assignee list and/or the posted comment are present:
+   ```bash
+   gh issue view <N> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --json assignees,comments
+   ```
+   If neither the assignment nor the comment is visible, don't silently proceed as if
+   claimed — report the failure; a claim that didn't actually post protects nobody.
+
+## Output
+
+Hand off to `issue-address:reproduce` — same issue number, now with a real claim on
+record. If this step's own re-confirmation fails (step 3), stop the sequence and report,
+same severity as a `confirm-open` NO-GO — proceeding to reproduce/fix on an issue that
+isn't actually marked claimed defeats the point of adding this step.

package/plugins/session-manager-dev/skills/issue-address/3-reproduce/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: issue-address:reproduce
+description: Step 2 of issue-address — reproduce a confirmed-open issue locally with a failing test (red), using hypothesis-driven debugging. Stops and reports if the issue doesn't actually reproduce.
+---
+
+# issue-address:reproduce
+
+Called after `issue-address:confirm-open` returns GO, with the issue's title/body/repro
+steps in hand. Leans on `systematic-debugging` and `test-driven-development`.
+
+## Steps
+
+1. **Form an explicit hypothesis** for what's actually broken, grounded in the issue's
+   description — name the file/function you expect is at fault and why, before touching
+   anything.
+
+2. **Locate the relevant code path** — search for the function/route/query the issue
+   describes; read it fully before writing a test against it.
+
+3. **Write a test that captures the reported bug.** It must exercise the exact scenario
+   the issue describes (same inputs, same expected-vs-actual mismatch), using this repo's
+   existing test patterns/helpers for that area (reuse fixtures, don't invent parallel
+   ones).
+
+4. **Run it and confirm it fails (red)** — this is the proof the bug is real, not just
+   assumed from the issue text. Capture the actual failure output.
+
+5. **If it does NOT fail** (test passes immediately): the issue may already be fixed,
+   stale, or a misunderstanding. **Stop and report this** rather than fabricating a fix for
+   a bug that doesn't reproduce — this is a valid, useful outcome, not a failure of the
+   skill.
+
+6. **If reproduction is hard**, bisect rather than guess repeatedly: halve the input or
+   code path, or check `git log` on the relevant files for a recent change that lines up
+   with when the bug was reported. Record each bisection step.
+
+## Output
+
+Hand off to `issue-address:fix`: the failing test (file:line), the confirmed root-cause
+hypothesis, and the actual red-phase failure output as evidence.

package/plugins/session-manager-dev/skills/issue-address/4-fix/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: issue-address:fix
+description: Step 3 of issue-address — root-cause and implement the fix for a reproduced issue, given the failing test from issue-address-reproduce. Does not run the broader verification pass — that's issue-address-verify.
+---
+
+# issue-address:fix
+
+Called after `issue-address:reproduce` hands off a failing test + root-cause hypothesis.
+
+## Steps
+
+1. **Confirm the root cause**, not just the symptom the test exercises — read the
+   surrounding code for the actual invariant being violated. A fix that makes the specific
+   test pass without addressing the underlying cause will resurface as a different bug
+   later.
+
+2. **Check for an existing helper/pattern before writing new logic** (API-reuse standard):
+   search the codebase for a similar computation/validation/formatting already
+   implemented elsewhere. Extend or reuse it rather than forking a parallel
+   implementation.
+
+3. **Implement the fix** — the smallest correct change that addresses the root cause, in
+   the style/conventions of the surrounding code.
+
+4. **Run the reproduction test from step 2 only** (not the full suite yet — that's the
+   next skill) to confirm it now passes. If it still fails, iterate on the fix, not the
+   test.
+
+## Output
+
+Hand off to `issue-address:verify`: the diff, the now-passing reproduction test, and a
+one-line statement of the actual root cause fixed (for the eventual commit message and
+review).

package/plugins/session-manager-dev/skills/issue-address/5-verify/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: issue-address:verify
+description: Step 4 of issue-address — prove the new reproduction test passes AND the full existing test suite/typecheck still pass (no regressions), given a fix from issue-address-fix. The gate before requesting-code-review.
+---
+
+# issue-address:verify
+
+Called after `issue-address:fix` lands a fix and confirms the single reproduction test is
+green. This step's job is the broader safety net.
+
+## Steps
+
+1. **Re-run the reproduction test** on its own once more — confirm green (belt-and-braces,
+   in case an intervening change touched it).
+
+2. **Run the project's full relevant test suite** — not a hand-picked subset:
+   ```bash
+   pnpm --filter <affected-package> test
+   ```
+   and if the fix touches more than one workspace package, run each affected package's
+   suite. Report the actual pass count (e.g. "419/419 passed"), not just "tests pass."
+
+3. **Run typecheck**:
+   ```bash
+   pnpm --filter <affected-package> typecheck
+   ```
+   A green test suite with a broken typecheck is not done.
+
+4. **If anything besides the target reproduction test is red**, fix it before proceeding —
+   never report this step as passed on a partially red suite. Identify whether the new
+   failure is a genuine regression from this fix or a pre-existing flake (check if it
+   fails on the base branch too, via stash/checkout if needed) before deciding how to
+   handle it.
+
+## Output
+
+A clean verification report (suite name → pass count, typecheck status) to hand to
+`requesting-code-review` (existing skill, not nested here) for the independent review
+pass — call that skill synchronously and read its result before considering the issue
+resolved.