claude-code-session-manager 0.111.0 → 0.113.0

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

@@ -1,40 +0,0 @@
----
-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

@@ -1,33 +0,0 @@
----
-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

@@ -1,40 +0,0 @@
----
-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.

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

@@ -1,120 +0,0 @@
----
-name: issue-address
-description: Take ONE GitHub issue on the current project's repo from selection (or a named issue number) to a verified, reviewed fix — orchestrates 6 nested sub-skills (issue-address:select, :confirm-open, :claim, :reproduce, :fix, :verify) plus the existing requesting-code-review skill, so each step is independently invokable and monitorable. Use when the user wants a real issue picked and actually resolved, not just triaged.
----
-
-# issue-address (orchestrator)
-
-Global, project-agnostic issue-to-fix pipeline — works against whatever repo the current
-project's `gh` remote points to. Fires exactly one issue through a fixed sequence of nested
-skills — each a real, independently-invokable `SKILL.md`, not just a section header, so the
-sequence's progress can be watched step by step instead of as one opaque pass. Codified from
-`midt-bg/sigma`'s workflow; a project's own `AGENTS.md`/`CLAUDE.local.md` may add repo-specific
-conventions (branch naming, claim-comment language, commit style) that this skill should read
-and respect if present.
-
-**Naming convention (see a project's own `AGENTS.md` if it documents one; otherwise this
-convention still applies as the plugin's own standard):** sub-skill directories are prefixed
-`0-`, `1-`, `2-`... in execution order, so a plain directory listing sorts in DAG order
-without needing to open any file. Never rely on prose order alone — a reader (or an
-alphabetically-sorted file browser) should see the sequence from the folder names
-themselves. The invocable `name:` field stays a clean colon-scoped identifier
-(`issue-address:select`) without the numeric prefix — the prefix is a filesystem/ordering
-aid, not part of the skill's name.
-
-## Pipeline DAG
-
-```
-                    ┌─────────────────────┐
-  no issue #  ──────▶ 0. issue-address:select │──▶ issue number
-                    └─────────────────────┘         │
-  issue # given ─────────────────────────────────────┘
-                                                      ▼
-                                        ┌───────────────────────────┐
-                                        │ 1. issue-address:confirm-open │
-                                        └───────────────────────────┘
-                                     GO │                    │ NO-GO
-                                        ▼                    ▼
-                          ┌─────────────────────┐    STOP — report why
-                          │ 2. issue-address:claim   │
-                          └─────────────────────┘
-                    claimed │              │ claim failed to land
-                             ▼              ▼
-                  ┌─────────────────────┐    STOP — report (don't proceed
-                  │ 3. issue-address:reproduce│    unclaimed)
-                  └─────────────────────┘
-                    reproduces │              │ doesn't reproduce
-                                ▼              ▼
-                  ┌─────────────────┐   STOP — report (valid outcome,
-                  │ 4. issue-address:fix │    not a failure)
-                  └─────────────────┘
-                                │
-                                ▼
-                  ┌────────────────────┐
-                  │ 5. issue-address:verify│──── red ────┐
-                  └────────────────────┘                 │
-                                │ green                   │
-                                ▼                          │
-                  ┌────────────────────┐                  │
-                  │ 6. requesting-code-review│             │
-                  └────────────────────┘                  │
-                                │                          │
-                                ▼                          ▼
-                       land per conventions      loop back to step 4
-```
-
-| Step | Input | Output | On failure |
-|---|---|---|---|
-| 0. `issue-address:select` | open-issue pool (implicit — repo-wide) | one issue number + justification | n/a (always produces one, or explicitly reports the pool is empty) |
-| 1. `issue-address:confirm-open` | one issue number | GO (+ title/body/repro steps) or NO-GO (+ reason) | **STOP** — do not proceed |
-| 2. `issue-address:claim` | one confirmed-open issue number | self-assignment + claim comment, re-confirmed as landed | **STOP** — report if the claim didn't actually post; don't proceed unclaimed |
-| 3. `issue-address:reproduce` | issue title/body/repro steps | failing test (file:line) + root-cause hypothesis + red-phase output | **STOP** — report "does not reproduce" (valid, not a failure) |
-| 4. `issue-address:fix` | failing test + root-cause hypothesis | diff + the one test now green | loops internally until its one test is green |
-| 5. `issue-address:verify` | diff + green reproduction test | full-suite pass counts + typecheck result | **loop back to step 4** — do not proceed to review on red |
-| 6. `requesting-code-review` | the verified diff | Critical/Important findings addressed | fix findings, do not mark resolved until clean |
-
-Called either with **no issue number** (enters at step 0) or with **one specific issue
-number already named** (enters at step 1, skipping step 0 entirely).
-
-**Why claim is its own step, not folded into confirm-open:** confirming an issue is
-open/unclaimed and actually claiming it are two different moments in time — a gap where a
-second concurrent run (or a human) could pick the same issue between the two. `select`'s
-`reject-claimed` check only catches claims that already exist (an assignee, a "working on
-this" comment); nothing marks the issue claimed *for this run* until `claim` actually
-posts one. No dedicated GitHub/issue-tracking MCP server is connected in this environment
-— `claim` uses the `gh` CLI directly (self-assign + comment), same as every other GitHub
-interaction in this skill chain.
-
-## After the sequence completes clean
-
-- Commit with a conventional-commit message (`fix(scope): subject`, no trailing period, no
-  `Co-Authored-By` trailer unless the project's own convention says otherwise), on a branch
-  following the project's own `<type>/<slug>` convention if it documents one.
-- **Only push / open a PR when explicitly asked** — per the project's own `AGENTS.md` PR
-  section if it has one, don't do it unprompted. Report the sequence as complete and ready,
-  and wait.
-- If a PR does get opened (once asked), post a short comment on the originating issue
-  linking it — closes the loop from report to fix.
-- Never contact a reviewer (no request/re-request/nudge) without the user's fresh,
-  explicit, per-instance approval — same hard constant as everywhere else in this workflow.
-
-## Why nested skills instead of one inline sequence
-
-Each step is its own file so it shows up as its own invocation in whatever surface tracks
-skill/tool calls — you can see "select ran, chose #N over 4 rejected candidates" and
-"confirm-open ran, returned GO" as distinct, inspectable events before "reproduce" even
-starts, rather than one long undifferentiated pass. If a step needs to change (e.g. the
-verify step's test-runner command, or select's ranking weights), it's a one-file edit that
-doesn't touch the others. When a step needs more depth or clarity, decompose it further
-the same way `issue-address:select` was (see `0-select/SKILL.md` for its own nested DAG)
-— continuously, wherever a single file is doing too much to inspect as one unit.
-
-## What this skill is not
-
-- Not a pure triage/backlog tool — that's `find-opportunity` (ranks what to work on next
-  without opening/fixing anything, and never opens/fixes on its own). `issue-address:select`
-  overlaps with it in spirit (both rank by impact and check for claims) but exists
-  specifically to feed straight into actually fixing one issue in the same run, not just
-  to produce a shortlist for a human to review.
-- Not for PR review comments — that's a different data source entirely (see
-  `pr-review-sweep` for the unresolved-review-thread workflow on already-open PRs).

package/plugins/session-manager-dev/skills/local-project-health/SKILL.md

@@ -1,58 +0,0 @@
----
-name: local-project-health
-description: >-
-  Run the CURRENT project's own definition of "health" and report one rollup.
-  Each project defines health differently (a trading bot tracks circuit-breakers
-  + benchmark alpha; a web app tracks uptime + error rate), so this skill runs
-  the project-supplied health entrypoint rather than imposing a generic check.
-  Use whenever the user asks "is this project healthy?", "/local-project-health",
-  "system health", "is everything running / green", or wants a one-shot status
-  rollup for the repo they're in. Keywords: health, status, healthcheck, is it
-  up, are we green, rollup, system health, project health.
----
-
-# Local project health
-
-Report a single health verdict for the project in the current working directory
-by running **that project's own** health definition. Health is project-specific
-by design — do not invent generic checks.
-
-## Procedure
-
-1. **Find the project's health entrypoint**, checking these paths in order
-   (first hit wins):
-   - `scripts/health.sh`
-   - `.claude/health.sh`
-   - `bin/health.sh`
-   - `Makefile` / `justfile` target named `health`
-
-2. **If an entrypoint exists**, run it from the repo root and relay its output:
-   - `bash scripts/health.sh` (or the path found / `make health` / `just health`).
-   - These scripts are designed to print a human rollup and exit 0/1/2
-     (GREEN/YELLOW-or-UNKNOWN/RED). Show the user the rollup verbatim, then add a
-     one-line plain-English verdict leading with the overall color and the worst
-     layer (e.g. "🟡 YELLOW — performance is the drag: −3 pts vs SPY").
-   - If the script persists a structured artifact (e.g.
-     `data/system_health.json`), mention where it landed.
-   - If it exits non-zero, that is expected for YELLOW/RED — it is NOT a skill
-     failure. Only treat a *crash* (missing interpreter, traceback, unbound var)
-     as a failure to debug.
-
-3. **If NO entrypoint exists**, do not guess at health with ad-hoc commands.
-   Instead:
-   - Read `CLAUDE.md`, `README*`, and skim the repo to infer what "health" means
-     for THIS project (what it monitors, what would constitute degraded/broken).
-   - Propose a concrete `scripts/health.sh` that collapses those project-specific
-     layers into one GREEN/YELLOW/RED rollup (terminal output + a persisted
-     `*.json` artifact), reusing the project's existing CLIs/artifacts rather
-     than re-deriving thresholds.
-   - Offer to create it. Once created, it becomes the convention this skill runs
-     on every future invocation.
-
-## Notes
-
-- The contract is the **convention path**, not a shared implementation: every
-  project owns its own `scripts/health.sh`. This skill is just the launcher +
-  interpreter of the result.
-- Keep the relayed summary tight: overall color first, then the offending
-  layer(s), then where the full report is. Lead with the answer.

package/plugins/session-manager-dev/skills/memory-sanitation/SKILL.md

@@ -1,147 +0,0 @@
----
-name: memory-sanitation
-description: >-
-  Audit every memory in the current project's auto-memory store, fold anything now
-  duplicated in an always-loaded instruction file (global CLAUDE.md, project CLAUDE.md,
-  or a plugin skill's SKILL.md) into that file and delete the memory, verify and delete
-  memories whose tracked PRD/incident has since landed or expired, trim memories that are
-  part-stale, and leave genuinely current non-duplicated memories alone. Ends with a
-  structured summary (counts + per-memory outcome) suitable for display in a UI. Use
-  whenever the user says "/memory-sanitation", "clean up memory", "sanitize memory",
-  "audit my memories", "combine and remove memories", or asks what should move from
-  memory into system instructions. Keywords: memory, sanitation, sanitize, cleanup, audit,
-  dedupe, prune, CLAUDE.md, instructions, stale memory.
----
-
-# /memory-sanitation — audit → fold/delete/trim/keep → report
-
-**Role:** a periodic hygiene pass over `<memory-dir>/*.md` (the auto-memory store described
-in the top-level system instructions — one file per memory, indexed by `MEMORY.md`). Memory
-exists to recall things NOT already guaranteed to reach the assistant another way. Once a
-memory's content is baked into something always-loaded (CLAUDE.md, a skill's SKILL.md) or the
-event it tracked has resolved (a PRD landed, an incident closed, a pause expired), it is dead
-weight: it costs retrieval relevance and maintenance, and duplicated content risks drifting out
-of sync with the authoritative copy.
-
-**Never** delete a memory just because it's old — staleness is about resolution, not age. A
-memory describing a standing architecture fact that's still true and still nowhere else stays,
-no matter how old.
-
-## Procedure
-
-1. **Locate the memory dir** — the path in the system instructions'
-   `auto memory` section (`~/.claude/projects/<encoded-cwd>/memory/`). List every `*.md` file
-   except `MEMORY.md` itself.
-
-2. **Read every memory file in full**, plus `MEMORY.md`'s index, plus the project's own
-   `CLAUDE.md` (and the global `~/.claude/CLAUDE.md`) and the skill files under
-   `plugins/*/skills/*/SKILL.md` if the project ships a dev-skill plugin. You need all of
-   these loaded to judge duplication.
-
-3. **Classify each memory** into exactly one bucket:
-   - **DELETE — baked in.** The memory's content (a process rule, a behavioral preference, a
-     standing architecture fact) is now verbatim or near-verbatim present in an always-loaded
-     instruction file. Confirm with a direct text comparison, not a vibe check, before deleting.
-   - **DELETE — resolved/expired.** The memory tracks a PRD, incident, or temporary state
-     (a dev pause, a "queued as PRD NN" note, a "bug found, not yet fixed" note) whose tracked
-     event has since concluded. Verify before deleting — don't assume from the memory's own
-     text that something landed:
-     - PRD status: check `~/.claude/session-manager/scheduled-plans/queue.json` (or the
-       project's own scheduler queue file) for the PRD slug's `status` field, or
-       `prds-archived/` for a withdrawn/archived one.
-     - Code claims: `grep`/`ls` the file(s) and line(s) the memory cites — confirm the
-       described function/constant/behavior still exists as described (or confirm it's gone,
-       which is its own signal the memory is obsolete).
-     - Git history: `git log --oneline --all | grep <PRD-or-feature-slug>` when queue.json
-       doesn't resolve it.
-   - **FOLD then DELETE.** The memory is a durable, project-wide rule that belongs in an
-     instruction file but isn't there yet (a cross-project rule → global `~/.claude/CLAUDE.md`;
-     a this-project convention → project `CLAUDE.md`'s `## Conventions`/`## Avoid`; a
-     process/routing rule for a specific skill → that skill's `SKILL.md`). Write it into the
-     target file first, in that file's own voice and section, then delete the memory. Two
-     overlapping memories covering the same territory fold into ONE rule, not two.
-
-     **FOLD MUST NOT GROW AN ALWAYS-LOADED FILE.** A `CLAUDE.md` is read on every turn of every
-     session; this skill is the only process that routinely writes *into* one, which makes it a
-     one-way ratchet — memory gets a sanitation pass, `CLAUDE.md` becomes its landfill, and nothing
-     ever evicts from the landfill. So:
-     - If the target `CLAUDE.md` declares a **size budget**, honour it. Check `wc -c` first. If the
-       fold would breach it, fold the *rule* into `CLAUDE.md` as one line and its rationale into
-       whichever linked reference doc that file points at — never append the full memory body.
-     - Prefer the **narrowest** always-loaded target: a specific `SKILL.md` over project
-       `CLAUDE.md`, and project over global. Only a genuinely cross-project rule earns the global file.
-     - A fold that adds more than ~2 lines to a `CLAUDE.md` is a signal you're moving narrative, not
-       a law. Compress to the imperative rule and drop the history.
-     - Report the net char delta per instruction file you touched in the step-7 summary, so a run
-       that quietly added 3k to an always-loaded file is visible rather than counted as "cleanup".
-   - **TRIM.** The memory mixes durable facts with dated, closed narrative (a deploy log, a
-     PRD-tracking blow-by-blow, "verified live" status updates). Keep only what's still true
-     and not written down elsewhere; cut the rest. Re-verify any code claim you keep (grep it).
-   - **KEEP.** Genuinely current, non-duplicated, still load-bearing. Leave it — don't rewrite
-     for style.
-
-4. **Fix cross-references.** Any memory you delete or fold may be `[[wikilinked]]` from a
-   surviving memory. Grep `<memory-dir>/*.md` for the deleted memory's `name:` slug and update
-   the reference — point it at the new location (an instruction-file section) or drop the link
-   if nothing replaces it. A dangling `[[link]]` to a file that no longer exists is a bug.
-
-5. **Rewrite `MEMORY.md`'s index** to match exactly what's on disk after steps 3–4. Re-read the
-   directory listing immediately before writing — another session or a background job may have
-   added a memory mid-run (this has happened in practice); never clobber a concurrent addition
-   with a stale full-file overwrite. Prefer `Edit` for point changes; only rewrite the whole
-   index when you've just re-confirmed the current file list.
-
-6. **Collision safety for instruction-file edits.** Before editing `CLAUDE.md` or any
-   `SKILL.md`, `git status --short` that specific file. If it's already dirty from unrelated
-   concurrent work, use small targeted `Edit`s (never a full-file `Write`) so you can't discard
-   someone else's in-flight change.
-
-7. **Report a structured summary**, both as your end-of-turn text and in a form a UI can render
-   directly (a JSON object is fine when invoked programmatically — see Output shape below):
-   counts per bucket, and for each memory: its name, the bucket, and a one-line reason. If
-   invoked from a UI trigger (see `## UI trigger` below), keep the summary tight enough to
-   render in a side panel — lead with the counts, then a short list, not full memory bodies.
-
-## Output shape (for programmatic/UI invocations)
-
-When this skill is invoked non-interactively (e.g. from the Memory tab's Sanitize button), end
-the run by printing a single fenced JSON block as the last thing in the transcript, so the
-caller can parse it without scraping prose:
-
-```json
-{
-  "totalBefore": 26,
-  "totalAfter": 9,
-  "deleted": [{ "name": "feedback_fix_dont_ask", "reason": "baked into CLAUDE.md + develop/SKILL.md" }],
-  "folded": [{ "name": "feedback_nav_microservices", "into": "CLAUDE.md ## Avoid", "reason": "merged with feedback_extend_dont_add_tabs" }],
-  "trimmed": [{ "name": "web_remote_v2_mobile", "reason": "PRDs landed; cut deploy-log narrative" }],
-  "kept": [{ "name": "no_schedule_self_e2e", "reason": "active, tracks open PRD" }],
-  "instructionFileDelta": [{ "file": "CLAUDE.md", "charsBefore": 11576, "charsAfter": 11702, "delta": 126, "withinBudget": true }]
-}
-```
-
-`instructionFileDelta` is required whenever the run wrote to any always-loaded instruction file
-(`CLAUDE.md`, a `SKILL.md`). It is what makes a FOLD-heavy run that grew an always-loaded file by
-3k visible instead of counted as "cleanup" — see the FOLD rule above. Set `withinBudget: false`
-(and say so in the prose summary) if the file declares a size budget and the run breached it.
-
-Still print the normal human-readable summary too — the JSON block is additive, not a
-replacement.
-
-## UI trigger
-
-The Memory tab (`src/renderer/components/tabs/Memory.tsx`) has (or will have, per the queued
-PRD) a "Sanitize memory" button that fires this skill as a headless run and renders the JSON
-summary above. When authoring or reviewing that wiring, this skill is the contract: the button
-sends a prompt that invokes `/memory-sanitation`, and the tab parses the trailing JSON block
-from the run's final message. Don't hand-roll a second summary shape in the renderer — parse
-this skill's own output shape.
-
-## Notes
-
-- This is a hygiene pass, not a content-authoring pass — don't use it to write NEW memories,
-  only to reconcile existing ones against instruction files and resolved state.
-- Don't delete a memory solely because it's short, or solely because it's old. Staleness is
-  "the thing it tracked resolved" or "it's now duplicated elsewhere" — not age or length.
-- Don't run this against another project's memory store without being asked — memory dirs are
-  per-project (`~/.claude/projects/<encoded-cwd>/memory/`); stay scoped to the current cwd.

package/plugins/session-manager-dev/skills/ops-sweep/SKILL.md

@@ -1,137 +0,0 @@
----
-name: ops-sweep
-description: >-
-  Run the operations-folder maintenance protocol (see
-  session-manager-operations/architecture/ops-maintenance-protocol.md) against
-  ANY project's session-manager-operations/ folder — including a project with
-  a different OWNERS vocabulary than session-manager's own, or no CLAUDE.md at
-  all. Diffs declared-vs-actual namespace ownership, flags doc contradictions
-  (one doc says retired, another says still owned), and flags archived content
-  with no stated retention policy. Never deletes or migrates anything itself —
-  findings are reported to the human, or queued as PRDs in the current session
-  when the user asks for that. Use whenever the user says "/ops-sweep", "sweep the
-  ops folder", "audit operations hygiene", "check for ops drift", or wants the
-  maintenance protocol run against a project (this one or another). Keywords:
-  ops sweep, operations hygiene, namespace drift, OWNERS audit, retention
-  policy, doc contradiction.
----
-
-# ops-sweep
-
-**Role:** the automated, portable version of
-`session-manager-operations/architecture/ops-maintenance-protocol.md`'s Pattern F —
-a *finder*, never an *actor*. It reports drift between a project's declared
-architecture and what's actually on disk; a human (via a proposed Epic)
-decides what to do about it.
-
-Read the protocol doc in full before running this the first time, especially
-Pattern F ("generalizing to other projects") — this skill is that
-generalization.
-
-## What it does NOT assume
-
-Unlike this project's own `scripts/audit-ops-hygiene.cjs` (which hardcodes
-session-manager's OWNERS vocabulary — `feedback`, `scheduler`, `prompt-sessions`,
-etc.), this skill makes **no assumption about the target project's namespace
-names, its OWNERS table shape, or whether it has a CLAUDE.md at all**. It
-re-derives the source-of-truth hierarchy from what that specific project has:
-
-**Hand-authored-PRD detection stays out of this generic script on purpose.**
-`audit-ops-hygiene.cjs`'s Pattern E (cross-referencing a live PRD `.md` file
-against the machine-wide `prd_create` audit log to flag a PRD that bypassed
-`scheduler_create_prd`) requires session-manager's own scheduler/PRD/audit-log
-concepts, which a swept project may not even have — adding it here would break
-the "no assumption about vocabulary" guarantee above. When sweeping
-session-manager's own repo, run `node scripts/audit-ops-hygiene.cjs` alongside
-this skill and fold its Pattern C/D/E findings into the same report; when
-sweeping a different project, Pattern E simply doesn't apply.
-
-1. That project's own `CLAUDE.md` (if present) — the declared architecture.
-2. Each namespace's own `README.md` under its `session-manager-operations/<namespace>/`.
-3. On-disk content — folder names, and archived/processed subfolders.
-
-A project with no `CLAUDE.md` still gets a useful sweep: every namespace is
-reported `mentionedInClaudeMd: false` (nothing to compare against), so
-`MISSING_README` and `NO_RETENTION_POLICY` findings still fire; contradiction
-detection is simply skipped since there's no second doc layer to disagree.
-
-## How to run it
-
-```bash
-node "$SM_ROOT/scripts/ops-sweep.cjs" <target-project-cwd>
-```
-
-`$SM_ROOT` is `.` when you're already working inside the session-manager repo,
-otherwise four directories up from this file's own path (the installed package
-root).
-
-`<target-project-cwd>` is the project to sweep — it does **not** need to be
-the project you're currently working in. Sweeping session-manager's own repo
-(`.`) is a valid, common case (that's how the maintenance protocol doc itself
-was written), but so is sweeping a different project this machine has opened
-a TAB on.
-
-The script prints a JSON report to stdout:
-
-```jsonc
-{
-  "targetCwd": "...",
-  "opsRoot": "<cwd>/session-manager-operations",
-  "hasClaudeMd": true,
-  "namespaceCount": 12,
-  "namespaces": [ { "name": "...", "findings": [ { "type": "...", "detail": "..." } ] }, ... ],
-  "findings": [ { "namespace": "...", "type": "...", "detail": "..." }, ... ]
-}
-```
-
-Finding `type`s:
-- **MISSING_README** — namespace dir has no `README.md`.
-- **UNDOCUMENTED** — namespace name never appears anywhere in the target's
-  `CLAUDE.md` (no declared ownership, no explicit non-owned mention either).
-- **CONTRADICTION** — either (a) the same clause of `CLAUDE.md` uses both
-  "retired/gone" language and "owner/owns" language about this namespace, or
-  (b) the namespace's own README and `CLAUDE.md` disagree on whether it's
-  retired.
-- **NO_RETENTION_POLICY** — namespace has files under an archived/processed
-  subfolder but its README says nothing about how long they're kept or who
-  prunes them.
-
-## Text-heuristic findings need a sanity check before filing
-
-Detecting "the same clause talks about both retirement and ownership" is a
-regex heuristic over prose, not a parser — it can flag a namespace whose
-CLAUDE.md text legitimately describes a partial retirement (e.g. "the old
-flat layout under this namespace is retired" while the namespace itself is
-still owned) as a false-positive CONTRADICTION. Before filing each finding,
-read the actual CLAUDE.md clause and README the script points at and confirm
-the drift is real. Don't file findings you can see are heuristic noise.
-
-## Routing findings — never act directly
-
-This skill (and the script it runs) never deletes, moves, or archives
-anything. Once you've sanity-checked the findings:
-
-- **Default**: report the findings to the human, grouped by namespace (one
-  block per namespace, not one per finding line — mirrors how Pattern A in the
-  protocol doc was resolved as a single unit). State the namespace, the doc
-  locations that disagree, and what decision needs to be made. Do NOT open an
-  Epic anywhere: an Epic is created only by a human pressing New Epic, and that
-  is doubly true across a project boundary.
-- **If the user asks for PRDs in this session** (e.g. "just queue it here",
-  "PRDs on this session" — the mode used when this protocol doc's own findings
-  were resolved) — queue the work as PRDs in the *current* Epic's scheduler via
-  `/develop`. Only when the sweep target IS the current project; never author
-  PRDs into another project.
-
-Report back: namespace count swept, finding count by type, and the Epic
-id(s) or PRD(s) filed.
-
-## When NOT to use this
-
-- The user wants a one-off answer about a single namespace they already named
-  → just read that namespace's README and the relevant CLAUDE.md section
-  directly; don't run the full sweep for a question with a known answer.
-- Cron/scheduled sweeping across every active project cwd is an explicit
-  stretch goal, not implemented here — this skill is manual, single-project,
-  invoked per run. `src/main/lib/watchdogHelpers.cjs`'s `activeProjectCwds()`
-  is the reusable piece if that's ever built.

package/plugins/session-manager-dev/skills/pr-review-sweep/0-fetch/SKILL.md

@@ -1,41 +0,0 @@
----
-name: pr-review-sweep:fetch
-description: Step 0 of pr-review-sweep — fetch every unresolved review thread on one or more of the current project's PRs, fully paginated. Never trust file names, a prior status report, or a reply's own claim about what's outstanding.
----
-
-# pr-review-sweep:fetch
-
-Query GitHub's GraphQL API directly for each PR. Resolve `$owner`/`$name` from the current
-project's own remote — `gh repo view --json owner,name -q '.owner.login,.name'` — never
-hardcode a repo.
-
-```graphql
-query($owner: String!, $name: String!, $n: Int!) {
-  repository(owner: $owner, name: $name) {
-    pullRequest(number: $n) {
-      reviewThreads(first: 100) {
-        totalCount
-        nodes {
-          isResolved
-          path
-          line
-          comments(first: 3) { nodes { author { login } body createdAt } }
-        }
-      }
-    }
-  }
-}
-```
-
-Filter to `isResolved: false`. **`first: 100` is load-bearing** — `first: 50` silently
-truncates on any PR that has grown past 50 threads (two real PRs hit this: one had 64
-threads, another had 55; the truncated queries under-reported unresolved counts and caused
-genuinely-missed comments). Always compare `totalCount` to how many nodes you actually
-paged through, and keep paginating (`after:` cursor) until they match — never report a
-count you haven't verified is complete.
-
-## Output
-
-One unresolved-thread list per PR, each entry carrying: the PR number, thread id, file
-path + line, and full comment text/author/timestamp — everything `pr-review-sweep:classify`
-needs to decide disposition and type without a second round-trip to GitHub.