npm - claude-code-session-manager - Versions diffs - 0.37.1 → 0.38.0 - Mend

claude-code-session-manager 0.37.1 → 0.38.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (60) hide show

package/dist/index.html CHANGED Viewed

@@ -7,10 +7,10 @@
     <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--a8m5_ET.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-CTTjT08J.css">
+    <link rel="stylesheet" crossorigin href="./assets/index-CD_LuJZF.css">
   </head>
   <body class="bg-bg text-fg font-sans antialiased">
     <div id="root"></div>

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-session-manager",
-  "version": "0.37.1",
+  "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/SKILL.md CHANGED Viewed

@@ -2,9 +2,9 @@
 name: develop
 description: >-
   Lead a software-development task by decomposing a feature/refactor/bugfix prompt into a
-  series of self-contained PRDs queued for the session-manager scheduler, each carrying the
-  engineering standards inline so the headless executor honors them — then track those PRDs
-  to completion, verify them against their acceptance criteria, and report back. Use whenever
+  series of self-contained PRDs queued for the session-manager scheduler, each pointing the
+  headless executor at the engineering standards file to read at runtime — then track those
+  PRDs to completion, verify them against their acceptance criteria, and report back. Use whenever
   the user says "/develop", "develop X", "build me X", "implement X", "let's code X", or
   otherwise starts dev work that should run as scheduled PRDs rather than inline now. This
   skill is the home for the developer-only guidance (performance, debugging, API-reuse, TDD)
@@ -41,16 +41,18 @@ The engineering standards (Performance, Debugging, API reuse / single source of
 and the executor-facing Execution discipline) live in **`standards.md`** beside this file, in
 the same skill directory (`.../skills/develop/standards.md` — NOT `~/.claude/skills/develop/`,
 which is a different, non-existent path; resolve it relative to wherever this SKILL.md itself
-was loaded from). **Re-read that file fresh with the Read tool immediately before pasting it
-into each PRD (Phase 1 step 4) — never reuse a copy cached earlier in the same conversation.**
-A long authoring session can span an edit to `standards.md` (including one autonomously applied
-by a prior incident's fix-plan) without the model noticing; pasting a stale in-context copy
-silently ships PRDs missing the latest execution-discipline rules. This is exactly the
-single-source-of-truth violation the standards themselves warn against — don't let it happen to
-the standards block itself. (Incident: PRDs 467/468 authored late in a long session carried a
-standards.md snapshot from before the "You ARE the executor" guard was added earlier that same
-session, so PRD 467's headless run repeated the exact anti-pattern the guard exists to prevent.)
-Never restate or fork its content — one concept, one implementation.
+was loaded from).
+**Reference it, don't embed it.** The headless executor (`claude -p`) runs on the same
+filesystem this authoring session does, with full tool access — so a PRD only needs to name
+`standards.md`'s absolute path (resolved once, at authoring time, the same way this file already
+resolves it) and instruct the executor to `Read` it before starting. There is now exactly one
+copy of this text on disk, ever — no pasted snapshot to go stale, and nothing to re-read fresh
+before writing (an earlier version of this skill pasted the full contents into every PRD and had
+to warn authors to re-read it fresh each time to avoid shipping a stale in-context copy — PRDs
+467/468 did exactly that and repeated an anti-pattern a guard added earlier the same session was
+meant to prevent. Referencing by path removes the failure mode instead of warning against it).
+Never restate or fork its content — one concept, one implementation, one location.
 For interactive dev work, also apply the `test-driven-development` and `systematic-debugging`
 skills; the headless PRDs get the distilled core from `standards.md` instead, since they
@@ -64,21 +66,85 @@ can't load skills.
    caller is `/process-feedback`, scope is already established by its evaluation — don't
    re-ask; build from the brief it hands you.)
-2. **Explore the target repo.** Identify the absolute `cwd`, existing patterns/utilities to
-   reuse (per the API-reuse standard — search before writing new code), the test command, and
-   any constraints. Capture exact file paths and signatures; they go straight into the PRDs.
-3. **Decompose into a series of SMALL, bounded PRDs.** Split a large ask into multiple PRDs and
-   sequence them. To pick each PRD's `NN` (parallel group), **compute the highest in-use number
-   deterministically — never eyeball or narrow-grep the `ls`** (a narrowed pattern like
-   `'^10[0-9]'` silently misses `110+` and collides):
+2. **Explore the target repo — broadly, not just the obvious file.** Identify the absolute
+   `cwd`, existing patterns/utilities to reuse (per the API-reuse standard — search before
+   writing new code), the test command, and any constraints. Capture exact file paths and
+   signatures; they go straight into the PRDs. Don't stop at the first component that looks
+   relevant — check its siblings too (does the same pattern appear in 2-3 similar components?
+   do they actually share the same shape, or only look similar — confirm by reading, don't
+   assume: a wrong assumption here means an inaccurate PRD, discovered only after the executor
+   runs it), check existing tests for the area, and check whether a prior PRD already touched
+   this subsystem (`ls ~/.claude/session-manager/scheduled-plans/prds/` for related slugs) —
+   duplicating or contradicting a still-queued PRD is a real failure mode, not a hypothetical one.
+3. **Draft a candidate decomposition, then run a completeness pass before finalizing it.** This
+   step exists because small, bounded individual PRDs (step 4) are correct and non-negotiable —
+   but a *set* of small PRDs can still be incomplete if the upfront decomposition missed
+   something. Keeping PRDs small is not a substitute for getting the decomposition right; it's a
+   separate concern, and this step is where decomposition quality gets checked.
+   - For a **genuinely trivial ask** (one obvious PRD, no cross-file consequences) — skip
+     straight to step 4, no ceremony needed.
+   - For anything **larger than one or two obvious PRDs, or touching more than one
+     component/subsystem** — before finalizing, dispatch a second, independent agent (the Agent
+     tool, `subagent_type: "Explore"` or `"general-purpose"` — this is a single extra dispatch,
+     not the full multi-agent Workflow tool, and needs no special opt-in) with: the original ask
+     verbatim, your draft PRD list (titles + one-line goals), and the instruction to find what's
+     missing — uncovered edge cases, error-handling paths, tests, cross-file consequences,
+     components that share the same pattern but weren't included, anything the draft assumed
+     without verifying. Treat its findings as a second opinion to weigh, not an automatic
+     addition — fold real, concrete gaps into the PRD set (add, split, or adjust a PRD); dismiss
+     vague or speculative ones. For a large, multi-subsystem ask, it's fine to repeat this once
+     more after folding in the first round's findings (a second completeness pass on the revised
+     set) — stop once a pass turns up nothing new, don't loop indefinitely.
+   - **Check each drafted PRD against explicit concern dimensions, not just "does the feature
+     work"**: missing features/edge cases beyond the happy path, tests, security, and quality
+     (perf, error handling). This is where depth actually comes from — a decomposition that only
+     ever asks "what file does this touch" produces exactly the narrow, single-concern PRDs this
+     step exists to catch.
+     - **Tests and security are NOT separate follow-up PRDs — they are mandatory AC lines inside
+       the SAME PRD as the feature they belong to.** This is non-negotiable: `standards.md`'s TDD
+       rule requires the test before/with the implementation, not after, and a security concern
+       (input validation at a boundary, auth checks, no string-built queries) is a decision made
+       while writing the code — a later "security review PRD" would just end up re-touching the
+       same lines, doubling work and leaving the shipped code insecure in the meantime. Every
+       feature PRD's own Acceptance Criteria must include its test command AND, when it touches
+       input/auth/data, the relevant security checks — don't spin these out.
+     - **Genuinely separable work MAY become its own sibling PRD**: deeper edge-case coverage
+       beyond what the core AC needs to prove correctness, performance/observability hardening,
+       docs. Splitting these out is exactly the "more isolated, narrower PRDs" instinct — apply
+       it here, where a dedicated PRD adds real value, not to tests/security where it subtracts
+       from correctness.
+   - This is a planning-quality step, not an execution step — it happens entirely in the
+     interactive main-loop session, before anything gets written to disk or queued.
+4. **Decompose into a series of SMALL, bounded PRDs.** Split the (now completeness-checked)
+   decomposition into individually small PRDs and sequence them.
+   **Prefer creating each PRD via the `scheduler_create_prd` MCP tool**
+   (`mcp__session-manager-scheduler__scheduler_create_prd`) over hand-writing the file. Its input
+   (`title`, `cwd`, `estimateMinutes`, `goal`, `acceptanceCriteria[]`, `implementationNotes`,
+   `outOfScope[]`) maps directly onto the sections below — pass them straight through. It
+   allocates the parallel-group `NN` atomically (no read-then-write race against another
+   concurrent `/develop`/`/process-feedback` invocation), derives and collision-checks the slug,
+   and embeds the standards pointer for you. Set `parallelGroup` explicitly only when this PRD
+   must share an existing sibling's `NN` (a logically independent PRD that can run in parallel
+   with one already queued); omit it to get the next free `NN` atomically.
+   **Fallback — only when the tool errors with "app not running" / admin API unreachable**
+   (the session-manager Electron app must be running for this MCP tool to work; if it isn't,
+   don't block on it): compute the highest in-use number deterministically yourself — never
+   eyeball or narrow-grep the `ls` (a narrowed pattern like `'^10[0-9]'` silently misses `110+`
+   and collides):
    ```bash
    ls ~/.claude/session-manager/scheduled-plans/prds/ | grep -oE '^[0-9]+' | sort -n | uniq | tail -5
    ```
    The last line is the current max. Then: same `NN` as a logically independent sibling that
    can run in parallel; **next free `NN` = max+1** when this PRD hard-depends on prior work or
-   is unrelated to every existing group. Record each cross-PRD dependency in the dependent
-   PRD's notes.
+   is unrelated to every existing group. This manual path has a small, accepted race (two
+   concurrent authors could compute the same "next free" `NN`) — cosmetic (two unrelated groups
+   end up sharing a number) rather than destructive, and only reachable when the atomic tool
+   path above isn't available. Record each cross-PRD dependency in the dependent PRD's notes
+   either way.
    ### PRD structure and location
@@ -166,12 +232,24 @@ can't load skills.
    failure** — it's the scheduler's designed auto-pause; the job auto-resumes at the next
    window reset. Don't add retry logic for it.
-4. **Emit each PRD** to the canonical path and structure above, then **append `## Engineering
-   standards` and paste the full contents of `standards.md` verbatim.** This is the
-   load-bearing step — it's the only way the standards (incl. Execution discipline) reach the
-   headless run. Honor the `PRD_AUTHORING.md` §10 pre-queue checklist.
+5. **Emit each PRD.** If you used `scheduler_create_prd`, this step is already done — the tool
+   wrote the file to the canonical path with the standards pointer included; skip to step 5.
+   **Fallback path only:** write to the canonical path and structure above, then **append `##
+   Engineering standards` with a one-line pointer**, not the file's contents:
+   ```markdown
+   ## Engineering standards
+   Before writing any code, read `<absolute path to standards.md, resolved above>` — it has the
+   Performance, Debugging, API-reuse, TDD, and Execution-discipline rules that apply to this PRD.
+   Every rule in it is mandatory, especially Execution discipline (bounded commands, verify
+   before done, the finish-protocol sentinel).
+   ```
+   This is the load-bearing step — it's the only way the standards (incl. Execution discipline)
+   reach the headless run, and it now stays current automatically since the executor reads the
+   live file rather than a snapshot taken at authoring time. Honor the `PRD_AUTHORING.md` §10
+   pre-queue checklist.
-5. **Confirm to the user**, per emitted PRD: filename, chosen `NN` + rationale
+6. **Confirm to the user**, per emitted PRD: filename, chosen `NN` + rationale
    (parallel-with-X / serial-after-Y), `cwd`, and an ETA + token-cost ballpark. Note they can
    "Run now" in the SchedulePanel or wait for `when-available` polling.
@@ -181,7 +259,7 @@ The queued PRDs run headlessly and can take a while. Don't fire-and-forget, and
 hand off to a recurring check. `/process-feedback` delegates to this exact phase, so it is the
 single definition of "tracked to done" for both entry paths.
-6. **Watch the scheduler every ~30 min.** Start a 30-minute monitoring loop (`/loop 30m` over
+7. **Watch the scheduler every ~30 min.** Start a 30-minute monitoring loop (`/loop 30m` over
    this watch step, or a `ScheduleWakeup` at 1800s if self-pacing) scoped to the PRD ids you
    emitted. On each tick, read the scheduler's job status (queue + run history under
    `~/.claude/session-manager/scheduled-plans/`, or the SchedulePanel) and branch:
@@ -195,22 +273,42 @@ single definition of "tracked to done" for both entry paths.
      your report rather than re-deriving the analysis, and let `/process-feedback` fold its
      prevention hint back into future PRD authoring. A `rateLimited` exit-1 is the
      scheduler's benign auto-pause (auto-resumes next window) — keep waiting, don't escalate.
-   - **All PRDs completed successfully** — go to step 7.
+   - **All PRDs completed successfully** — go to step 8.
-7. **Gate: definition of done** (same for both entry paths). Once the code has landed:
+8. **Gate: definition of done** (same for both entry paths). Once the code has landed:
    - **Verify live against each PRD's acceptance criteria** — run the health check, hit the
      endpoint, show before/after. The headless run asserted its own test command; this is the
      interactive confirmation it actually does what was asked.
-   - For a **major feature or risky change**, dispatch a review via the
-     `requesting-code-review` skill before calling it done; fix Critical/Important findings.
-   - **Report back**: what landed, PRD/commit refs, verification result, anything left open.
+   - **Route to the specialist that actually matches what changed** — not always the generic
+     reviewer. This environment has dedicated agents that sit unused unless explicitly called;
+     match the PRD's surface to the right one before calling a major/risky change done:
+     - Touches an API's request/response shape, REST/GraphQL contract, or endpoint design →
+       dispatch `api-designer` (Agent tool).
+     - Touches auth, input handling, secrets, or data storage → dispatch `security-auditor` in
+       addition to the mandatory security AC the PRD's own execution already required — the
+       auditor catches what the executor's self-check might miss.
+     - Is a structural refactor (no behavior change intended) → dispatch `refactorer`.
+     - Is performance-sensitive or touches a hot path → dispatch `perf-profiler`.
+     - Adds or updates a dependency → dispatch `dependency-auditor`.
+     - Touches a database schema, migration, or table design → **no specialist exists for this
+       in this environment today.** Don't silently let the generic code-reviewer stand in for a
+       schema review it isn't specialized for — say so explicitly in your report ("schema change,
+       no dedicated reviewer available, manual review recommended") rather than implying coverage
+       that isn't there.
+     - Anything else, or a **major feature/risky change** not covered above — dispatch the
+       generic `requesting-code-review` skill (`code-reviewer` agent) as the default.
+     Fix Critical/Important findings from whichever specialist(s) ran before calling it done.
+   - **Report back**: what landed, PRD/commit refs, which specialist(s) reviewed it (or the
+     explicit "no specialist available" note), verification result, anything left open.
 ## References (reuse, don't duplicate)
 - `~/.claude/session-manager/scheduled-plans/PRD_AUTHORING.md` — the §1–§10 safety rules.
-- `standards.md` beside this file — the engineering + execution-discipline rules inlined into every PRD. Re-read fresh each time (see "Standards" above) — don't reuse a cached copy.
+- `standards.md` beside this file — the engineering + execution-discipline rules. Every PRD points the executor at its absolute path (see "Standards" above) rather than embedding a copy.
 - `test-driven-development`, `systematic-debugging` — interactive dev sessions.
-- `requesting-code-review` — the Phase-2 review gate.
+- `requesting-code-review` — the Phase-2 default review gate; `api-designer`, `security-auditor`,
+  `refactorer`, `perf-profiler`, `dependency-auditor` — specialist agents routed to by surface
+  area (see step 8) rather than always defaulting to the generic reviewer.
 ## Notes

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

@@ -50,6 +50,30 @@
 - (Interactive sessions: the `test-driven-development` skill has the full red-green-refactor
   workflow. Headless PRD runs can't load it — the three rules above are the load-bearing core.)
+## Visual design (UI/visual acceptance criteria)
+When a PRD's acceptance criteria touch UI or visual output and no design brief is given,
+resolve the visual direction in this priority order — never substitute a generic default when
+a higher-priority source exists:
+1. **User-supplied design.** If the PRD or the conversation that spawned it includes a design
+   brief, mockup, brand palette, or explicit visual direction, use it verbatim.
+2. **Existing project design system.** Before reaching for any external skill, check the repo
+   itself for an existing theme — CSS custom-property blocks, `tailwind.config.js`, a
+   design-tokens file, a component library already in use. Reuse and extend what's there
+   rather than introducing a second visual language into the same project.
+3. **Only if neither exists**, invoke a design-oriented skill rather than eyeballing colors
+   from memory or hand-picking hex values (e.g. the bundled `dataviz` skill for
+   chart/table/dashboard work, or a `frontend-design`-class skill for overall aesthetic
+   direction) — and **render + screenshot both light and dark color-scheme modes** before
+   calling the work done. A palette validator that checks categorical/series colors does not
+   cover surrounding chrome tokens (panel/page/border) — those need their own contrast check
+   (WCAG relative luminance) and a visual look in each mode. "I checked light mode" is not "I
+   checked dark mode"; verify both, don't assume palette-reference hex values are safe by
+   construction. (Incident: a dashboard shipped with panel/page background contrast of
+   1.12:1 and a border at 1.34:1 in dark mode — both invisible — because only light mode was
+   ever rendered before the work was marked done.)
 ## Execution discipline (headless runs)
 Data-driven from 400+ scheduler runs: long hangs (not bad code) are the dominant real failure, and "exited clean but left a red test" is the top verifier downgrade. These rules run at execution time — they are inlined into every PRD because the headless executor reads nothing else.
@@ -64,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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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.