claude-code-session-manager 0.111.0 → 0.113.0

package/plugins/session-manager-dev/skills/pr-review-sweep/1-classify/SKILL.md

@@ -1,56 +0,0 @@
----
-name: pr-review-sweep:classify
-description: Step 1 of pr-review-sweep — classify each unresolved review thread on two independent axes — disposition (accept-as-is / policy-override / needs-my-decision) and type (bug / feature) — so downstream steps can route and template correctly.
----
-
-# pr-review-sweep:classify
-
-Decided per-thread, never per-PR — a single PR routinely mixes threads that need very
-different handling.
-
-## Axis 1 — disposition
-
-- **Accept-as-is** — the reviewer's ask is valid, no repo-policy reason not to do it. The
-  default bucket.
-- **Policy-override** — the comment conflicts with something the repo's own `AGENTS.md` /
-  `CLAUDE.local.md` already decided (a staged-rollout convention, an intentional
-  trade-off). Policy wins silently — no need to escalate to the user — but still reply
-  explaining why, so the reviewer isn't left wondering. Verify the policy text actually
-  says what you think it says before invoking this bucket; don't assume.
-- **Needs-my-decision** — a genuine judgment call with no clear answer from repo policy
-  alone. Stop, surface the question verbatim to the user, never guess. This bucket blocks
-  only that one thread — every other thread on the PR keeps moving. A needs-my-decision
-  thread never gets a type tag (axis 2 is moot until it's decided to do the work at all).
-
-## Axis 2 — type (accept-as-is and policy-override threads only)
-
-- **Bug** — the reviewer flagged something objectively broken: wrong output, a crash, a
-  security issue, an off-by-one, a missed edge case. Anything where "what should happen
-  instead" is unambiguous from the current code being wrong.
-- **Feature** — the reviewer asked for additional behavior, a refactor, or a
-  consistency/style improvement that isn't fixing broken behavior. If the current code does
-  what it currently does *on purpose* and the ask is to make it do something more or
-  different, it's a feature, not a bug — even when phrased urgently.
-
-When genuinely ambiguous between the two (e.g. "this should also handle nulls" — is null
-input a bug the code should already handle, or new scope?), default to **bug** only if
-there's a concrete failing case (a real input that breaks today); otherwise **feature**.
-Record the reasoning either way — `pr-review-sweep:queue` uses it to pick the PRD template,
-and a future reader should be able to see why a borderline call went the way it did.
-
-## Known-pattern check (if the project curates one)
-
-Before finalizing type/reasoning, check whether the thread matches an already-documented
-recurring pattern. Some projects keep a curated, evolving corpus of past review findings
-(commonly `docs/review-*.md`, indexed from `docs/README.md`, fed by a project-local
-`project-status-local` mining step — sigma is the reference example). If such docs exist in
-this repo and the thread matches a named pattern there, say so in the reasoning and cite the
-doc/section — it strengthens the bug-vs-feature call (a documented recurring bug is bug,
-full stop) and carries forward to `:queue`. If no such docs exist, or the thread doesn't
-match anything in them, this is a no-op — don't go hunting for docs a project doesn't have.
-
-## Output
-
-Per thread: `{disposition, type | null, reasoning}`. Needs-my-decision threads carry the
-open question verbatim, collected for the final report rather than blocking the other
-threads.

package/plugins/session-manager-dev/skills/pr-review-sweep/2-check-fixed/SKILL.md

@@ -1,49 +0,0 @@
----
-name: pr-review-sweep:check-fixed
-description: Step 2 of pr-review-sweep — before queuing anything, triage every accept-as-is / policy-override thread into already-fixed, reply-only (no code change needed), or genuinely-open. Mandatory for every survivor, including policy-override threads — skipping it on the assumption "policy-override never needs a code check" is what caused a real wrong reply (see below).
----
-
-# pr-review-sweep:check-fixed
-
-Read the current file content at the cited location, and check recent git log/commits on
-the PR's actual branch, for **every** accept-as-is/policy-override thread — no exceptions
-for threads that look like a pure confirmation ask. **This step is mandatory before posting
-any reply, not optional for policy-override threads.**
-
-**Incident that made this mandatory:** on sigma PR #206, a policy-override thread (empty-
-string EIK display) was replied to with "leaving as-is, test locks in current behavior"
-without re-checking the code first — but the thread had *already been fixed* two commits
-earlier by a different session. The wrong reply had to be corrected with a follow-up
-comment. The cause wasn't a broken tool, it was skipping this step because the thread's
-disposition (policy-override) felt like it obviously needed no verification. It didn't
-obviously need verification — but it needed it anyway, and every thread does.
-
-## Triage into three outcomes, not two
-
-1. **Already-fixed** — the code (or a recent commit on the PR's branch) already does what
-   the thread asks. Routes straight to `pr-review-sweep:land-and-resolve`, citing the
-   fixing commit SHA. Skips `:queue` entirely.
-2. **Reply-only, no code change needed** — the thread is fully answered by information
-   that already exists (a repo convention, an intentional design documented elsewhere, a
-   fact about the code the reviewer didn't have) and genuinely requires zero code change to
-   resolve — not "a trivial one-line fix," but literally nothing to write. Common for
-   policy-override threads whose reviewer ask was really a question ("confirm X is
-   intentional") rather than a change request. Routes straight to
-   `pr-review-sweep:land-and-resolve`, citing the evidence/reasoning instead of a SHA.
-   **Do not send these to `:queue`** — queuing a PRD to "fix" a thread that needs no fix
-   wastes a scheduler run and produces a PRD with no real acceptance criteria to execute.
-3. **Genuinely open** — needs an actual code change that doesn't exist yet. Goes to
-   `pr-review-sweep:queue` as before, carrying its `{disposition, type}` tags.
-
-The dividing line between outcomes 2 and 3: if you can point to the exact existing
-line/paragraph that answers the reviewer's ask, it's outcome 2. If satisfying the ask
-requires writing or changing any code, however small, it's outcome 3 — don't downgrade a
-real fix to "reply-only" just because it's tiny; that's what `:queue`'s bug/feature
-templates are for, sized appropriately.
-
-## Output
-
-Three lists per PR:
-- **already-fixed** (thread id + the commit/line that fixed it) → `:land-and-resolve`
-- **reply-only** (thread id + the evidence/reasoning to cite) → `:land-and-resolve`
-- **survives** (thread id, disposition, type) → `:queue`

package/plugins/session-manager-dev/skills/pr-review-sweep/3-queue/SKILL.md

@@ -1,57 +0,0 @@
----
-name: pr-review-sweep:queue
-description: Step 3 of pr-review-sweep — bundle surviving accept-as-is/policy-override threads by (PR, type) and queue one /develop PRD per bundle. Never fixes inline; the scheduler is the only place code changes happen.
----
-
-# pr-review-sweep:queue
-
-Only ever receives the **survives** list from `pr-review-sweep:check-fixed` — threads that
-genuinely need a code change that doesn't exist yet. `check-fixed` has already routed
-already-fixed and reply-only threads straight to `land-and-resolve`, so if you're looking
-at a thread here, it needs real code written; don't second-guess that by trying to answer
-it with a reply instead of a PRD.
-
-Group `survives` threads by **(PR number, type)** — up to two bundles per PR, one `bug` and
-one `feature`. Queue each bundle as its own `/develop` PRD. Never write the fix in this
-session; this step's own actions are read-only except for the act of queuing.
-
-## Duplicate-PRD guard (idempotency)
-
-Before queuing a bundle, check the scheduler queue for an existing queued/in-flight PRD for
-that same (PR, type). If one exists, skip queuing and report the existing PRD id instead —
-re-running `pr-review-sweep` must never double-queue the same bundle. If a thread newly
-qualifies for a bundle that already has an in-flight PRD (e.g. a fresh review comment
-landed after the PRD was queued but before it completed), do not silently fold it in —
-queue a follow-up PRD once the first completes, so each PRD's diff stays traceable to a
-known snapshot of threads.
-
-## PRD acceptance criteria, by type
-
-Every PRD, regardless of type, ends with: commit + push to the fork branch that owns the
-PR (never `origin`, never force-push, never a new PR to carry a review fix — land on the
-existing PR's branch), and the standard two independent verification passes before commit.
-
-- **`bug` bundle** — additionally require: reproduce each defect described in the bundled
-  threads, write a regression test per defect that fails before the fix and passes after,
-  then fix. The PRD body should quote the reviewer's exact wording per thread so the
-  executor root-causes the actual reported defect, not a guessed one. If `:classify` flagged
-  a thread as matching a known documented pattern (see its "Known-pattern check"), the PRD
-  must say so explicitly and instruct the executor to **grep the rest of the codebase for
-  the same pattern, not just fix the one flagged instance** — several of sigma's own
-  documented patterns (e.g. an SSR-unsafe `useLayoutEffect`, an un-deduped array into a D1
-  `IN (...)`) turned out to be the exact same bug copy-pasted across 5+ sibling files, each
-  caught as a separate review comment on a separate PR because the first fix never swept the
-  rest. One PRD closing all occurrences beats N PRDs closing them one review cycle at a time.
-- **`feature` bundle** — additionally require: scope the change to exactly what each
-  bundled thread asked for (no piggybacked scope creep across threads even though they're
-  bundled together), match existing patterns/conventions in the touched files, and add a
-  test only if the ask itself introduces new testable behavior.
-
-Neither template authorizes a description edit or a reviewer request — those stay
-`pr-review-sweep:land-and-resolve`'s and `pr-signal`'s jobs respectively, so a PR's
-description reflects the *final* landed state, not a snapshot mid-fix.
-
-## Output
-
-Per (PR, type) bundle: a queued PRD id (new or pre-existing), or — if `survives` was empty
-for that PR — nothing to queue, reported as such rather than silently skipped.

package/plugins/session-manager-dev/skills/pr-review-sweep/4-land-and-resolve/SKILL.md

@@ -1,60 +0,0 @@
----
-name: pr-review-sweep:land-and-resolve
-description: Step 4 of pr-review-sweep — reply on the GitHub thread and resolve it, via one of three entry points from check-fixed/queue (already-fixed, reply-only, or a completed PRD). Runs async relative to steps 0-3 for the PRD path, typically triggered by a later project-status-local pass noticing a completed PRD.
----
-
-# pr-review-sweep:land-and-resolve
-
-Three entry points:
-
-1. **Already-fixed threads** from `pr-review-sweep:check-fixed` — no PRD to wait on, act
-   immediately, citing the commit that step already identified.
-2. **Reply-only threads** from `pr-review-sweep:check-fixed` — no PRD, no commit; act
-   immediately, citing the evidence/reasoning `check-fixed` already worked out (a repo
-   convention, an intentional-design confirmation, a fact about the code the reviewer
-   didn't have). **Re-verify that reasoning is still accurate right now, not just at
-   classify time** — code moves between when a thread was classified and when you're about
-   to reply; don't post a stale "confirmed" against code that's since changed.
-3. **Queued PRDs** from `pr-review-sweep:queue` that the scheduler now reports
-   `completed` — this is where this step actually waits on external state; a fresh
-   `/project-status` (or manual) run is what notices the PRD finished and re-enters here.
-
-## Steps
-
-1. **For the PRD entry point only:** confirm the PRD actually ran its required
-   verification — both independent passes, and (for a `bug` bundle) that the regression
-   test genuinely exists and is green, not just claimed in the PRD's own summary. A PRD
-   marked `completed` without evidence of the ACs having run is `needs_review`, not landed —
-   report it as stuck, don't proceed to reply/resolve. (Already-fixed and reply-only
-   entries have no PRD to verify — skip to step 2.)
-2. **Confirm CI is green** on the PR (for the PRD entry point, after the PRD's commit
-   landed; for already-fixed/reply-only, CI state is whatever it already is).
-3. **Reply** on each thread — naming the specific fixing commit SHA for already-fixed/PRD
-   entries, or the evidence/reasoning for reply-only entries — so the reviewer can verify
-   without re-reading the whole diff or re-asking the question.
-4. **Resolve** the thread via GraphQL `resolveReviewThread`. Order matters: reply first,
-   resolve second, so there's a paper trail explaining why a thread closed before it drops
-   off the unresolved list.
-
-Needs-my-decision threads (set aside back in `pr-review-sweep:classify`), and any
-policy-override thread where convention says the reviewer should be the one to close it,
-are deliberately left unresolved after the reply — that is correct behavior, not an
-oversight.
-
-## Stuck PRDs
-
-A `failed` or `needs_review` PRD is reported to the user as a stuck bundle, never silently
-retried and never silently downgraded to an inline fix — re-queuing or fixing it directly
-both require the user's decision, since either implies the original PRD's scope or ACs
-were wrong.
-
-## Hard constant
-
-**Never contact a reviewer** at any point in this step — replying to a thread and
-resolving it are not reviewer contact; requesting/re-requesting one is `pr-signal`'s job
-alone, gated separately.
-
-## Output
-
-Per thread: resolved (+ the SHA it was resolved against), or reported as blocked (PRD
-still in flight, or stuck) — loops back to `project-status-local`'s rollup either way.

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

@@ -1,124 +0,0 @@
----
-name: pr-review-sweep
-description: Sweep one or more of the current project's PRs' unresolved review comments end-to-end — fetch (paginated), classify by disposition AND bug-vs-feature type, check-if-already-fixed, queue a scheduler PRD per (PR, type), then land-and-resolve once it completes. Orchestrates 5 nested sub-skills (pr-review-sweep:fetch, :classify, :check-fixed, :queue, :land-and-resolve). Never fixes inline, never contacts reviewers. Use when a PR has open review feedback that needs triaging and landing.
----
-
-# pr-review-sweep (orchestrator)
-
-Global, project-agnostic PR-review-clearing pipeline — works against whatever repo the
-current project's `gh` remote points to. Run this per-PR whenever `/project-status` (or a
-manual check) surfaces unresolved review threads. Codified from the process used to clear
-review rounds on `midt-bg/sigma` PRs; a project's own `AGENTS.md`/`CLAUDE.local.md` may add
-repo-specific policy notes (e.g. which threads are auto-accept vs. needs-decision, house
-style for reply text) 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-`, ... in execution order, so a plain directory listing sorts in DAG order without
-opening any file. The invocable `name:` field stays a clean colon-scoped identifier
-(`pr-review-sweep:fetch`) without the numeric prefix.
-
-**Always via the scheduler.** Every genuinely-unfixed thread is fixed by a `/develop` PRD,
-never inline in this session — no "fast path" for small mechanical fixes. The scheduler is
-the one place real code changes happen (global CLAUDE.md model-economics rule: interactive
-sessions run an expensive planner-tier model; execution belongs on the cheap executor
-tier). If a fast lane for small review fixes turns out to be worth having, that's a
-scheduler-level feature (a priority/fast queue lane) to build later — not a reason for this
-skill to bypass the scheduler now.
-
-## Pipeline DAG
-
-```
-PR number(s)
-      │
-      ▼
-┌───────────────────────────┐
-│ 0. pr-review-sweep:fetch       │  paginated GraphQL, reviewThreads.isResolved ground truth
-└───────────────────────────┘
-      │ every unresolved thread, full text + location
-      ▼
-┌───────────────────────────┐
-│ 1. pr-review-sweep:classify    │  disposition (accept/policy-override/needs-decision)
-└───────────────────────────┘     × type (bug/feature) — two independent axes
-      │ per thread: {disposition, type}, needs-decision threads set aside
-      ▼
-┌───────────────────────────┐
-│ 2. pr-review-sweep:check-fixed │  MANDATORY for every survivor — triage into 3 outcomes
-└───────────────────────────┘     before queuing or replying to anything
-      │              │                      │
-      │ already-fixed│ reply-only            │ survives (genuinely needs new code)
-      ▼              ▼                      ▼
-      └──────┬───────┘          ┌───────────────────────────┐
-             │                  │ 3. pr-review-sweep:queue       │  one /develop PRD per
-             │                  └───────────────────────────┘  (PR, type) bundle,
-             │                        │ queued PRD id, or         duplicate-guarded
-             │                        │ "already queued"
-             │                        ▼
-             │                  ... async, on scheduler ...
-             │                        │
-             ▼                        ▼
-       ┌───────────────────────────────────┐
-       │ 4. pr-review-sweep:land-and-resolve    │  cite SHA (already-fixed/PRD) or
-       └───────────────────────────────────┘  reasoning (reply-only); reply; resolve
-                     │
-                     ▼
-       thread resolved, or reported stuck (failed/needs_review PRD)
-```
-
-| Step | Input | Output | On failure/empty |
-|---|---|---|---|
-| 0. `pr-review-sweep:fetch` | one or more PR numbers | every unresolved review thread, verified-complete (paginated) | n/a — loops its own fetch until `totalCount` matches nodes paged |
-| 1. `pr-review-sweep:classify` | unresolved threads | each thread tagged `{disposition, type}` | needs-decision threads are set aside, surfaced to the user, never guessed |
-| 2. `pr-review-sweep:check-fixed` | accept/policy-override threads — **every one, no shortcuts** | `already-fixed` (w/ commit) + `reply-only` (w/ reasoning) + `survives` | never skip this because a thread's disposition "obviously" needs no code check — see the incident documented in that step's own file |
-| 3. `pr-review-sweep:queue` | `survives` only, grouped by (PR, type) | one queued `/develop` PRD id per bundle | if a PRD for that (PR, type) is already queued/in-flight, skip and report its id — never double-queue |
-| 4. `pr-review-sweep:land-and-resolve` | already-fixed / reply-only (immediate) or a PRD reported `completed` by the scheduler | thread replied (SHA or reasoning) + resolved | `failed`/`needs_review`/stuck PRDs are reported, never silently retried |
-
-## Why two independent classification axes (step 1)
-
-**Disposition** (accept-as-is / policy-override / needs-my-decision) answers "should this
-be done at all, and does it need a human." **Type** (bug / feature) answers "what shape of
-change is this, once we've decided to do it" — and drives which PRD template/acceptance
-criteria `pr-review-sweep:queue` writes:
-
-- **Bug** — the reviewer flagged something objectively broken (wrong output, crash,
-  security issue, off-by-one, missed edge case). The PRD's ACs require: a reproduction of
-  the defect, a regression test that fails before the fix and passes after, then the fix
-  itself.
-- **Feature** — the reviewer asked for additional behavior, a refactor, or a
-  consistency/style improvement that isn't fixing broken behavior. The PRD's ACs require
-  scoping tightly to exactly what was asked (no piggybacked scope creep) and consistency
-  with existing patterns in the touched file; a regression test is only required if the ask
-  itself adds testable behavior.
-
-Splitting by type — rather than one undifferentiated "fix it" PRD per PR — is what lets each
-bundle get acceptance criteria actually suited to the kind of work it is, and is the reason
-this classification exists as its own step rather than being folded into disposition.
-
-## Hard constants across all five steps
-
-- **Ground truth for "unresolved" is GraphQL `reviewThreads.isResolved`**, fully paginated
-  (`first: 100` — smaller page sizes have silently truncated on real PRs; always compare
-  `totalCount` to nodes actually paged through). Never a last-reply/last-push heuristic.
-- **Never contact a reviewer** — no request, re-request, or nudge, at any point in this
-  process. Reviewer contact is `pr-signal`'s job alone, gated behind the user's explicit,
-  per-PR, freshly-given approval every time. A prior approval never carries forward.
-- **Never fix inline.** Every genuinely-unfixed thread goes through `/develop`, no
-  exceptions — see the scheduler note above.
-- **Idempotent re-runs.** One queued/in-flight PRD per (PR, type) bundle; replies aren't
-  re-posted; resolving an already-resolved thread is a no-op.
-
-## 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, and so a step can be changed (a new PRD template for a third `type`
-bucket, a different fetch page size) without touching the others. `classify` is the step
-most likely to grow — if a third type axis value earns its own PRD template later (e.g.
-`docs`, `perf`), or `queue` needs different bundling logic per type, decompose that step
-further the same way `issue-address:select` was, rather than growing this file.
-
-## What this skill is not
-
-- Not for GitHub issues — that's `issue-address` (a different data source: issues, not
-  open-PR review threads).
-- Not a decision on whether to contact a reviewer — that's `pr-signal`, invoked separately
-  and rarely.

package/plugins/session-manager-dev/skills/pr-signal/SKILL.md

@@ -1,67 +0,0 @@
----
-name: pr-signal
-description: >-
-  Request or re-request a reviewer on one PR on the current project's repo — the ONLY
-  step in the PR flow that contacts a person. Deliberately separate from pr-review-sweep
-  and meant to be invoked rarely — most projects don't tag reviewers often. Requires the
-  user's explicit, fresh, per-PR approval every time — a prior approval never carries
-  forward, and CI must be green at the moment of signaling, not just when approval was
-  given. Use only when the user explicitly names a PR number and says to
-  request/ping/notify the reviewer, or approves signaling in response to a
-  pr-review-sweep report.
----
-
-# pr-signal — the one step that contacts a reviewer (rare, gated)
-
-Global, project-agnostic — works against whatever repo the current project's `gh` remote
-points to. Input: a PR whose queued PRDs have all landed and whose threads
-`pr-review-sweep:land-and-resolve` has replied to and resolved (CI green) — plus the user's
-explicit approval for this specific PR number, given in this conversation, not inherited
-from an earlier one. If the project has its own reviewer-contact policy doc (e.g. sigma's
-`docs/pr-review-workflow.local.md`), read it for repo-specific nuance — reviewer identity,
-cadence norms — but the approval-per-PR and CI-green-at-signal-time gates below are hard
-constants regardless of what a project's doc says.
-
-**This skill runs far less often than the rest of the flow.** Most PRs on this repo don't need
-an explicit re-request — a push alone re-triggers review for an already-requested reviewer, and
-this team doesn't like being tagged unnecessarily. Only invoke this when the user actually asks
-for it, by PR number.
-
-## Steps
-
-1. **Verify the gate, don't assume it from a report given earlier in the conversation:**
-   - The PR is still open (`gh pr view <n> --json state,mergedAt`) — a merged/closed PR gets
-     no signal; report the state change instead.
-   - Every review thread is resolved (re-check now via GraphQL `reviewThreads.isResolved` — a
-     `pr-review-sweep:land-and-resolve` report from even a few minutes ago can be stale if
-     anything else touched the PR, and a new comment that arrived since means the PR goes back
-     through `pr-review-sweep:classify`, not to a signal).
-   - CI is green **right now** — re-run `gh pr checks <n> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)"` immediately
-     before acting. An approval given while CI was green does not survive CI going red in
-     between (a later push, a flaky rerun). If CI is red at signal-time, stop and report it —
-     never signal on a stale approval, and never solicit approval on a PR that's currently
-     CI-red in the first place.
-   - No review is already outstanding (requested, not yet dismissed by a later push) — if one
-     is, the push itself was already the signal; do not re-request
-     ([[no-reviewer-ping-without-approval]] / [[reviewers-dont-spam]]).
-   - The user's approval is for **this PR number, in this conversation** — a blanket "yes,
-     signal when ready" said about a different PR, or said before this session, does not count.
-
-2. **If any gate check fails**, stop and report exactly which one — don't ask "should I signal
-   now?" as a throwaway line and proceed anyway.
-
-3. **If every gate check passes**, request the reviewer:
-   ```bash
-   gh pr edit <number> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --add-reviewer <reviewer>
-   ```
-   If `gh pr edit` fails with the known "Projects (classic)" GraphQL deprecation error on this
-   repo, fall back to
-   `gh api repos/$(gh repo view --json nameWithOwner -q .nameWithOwner)/pulls/<n>/requested_reviewers -f "reviewers[]=<reviewer>"` —
-   and send it exactly once; verify via `gh pr view <n> --json reviewRequests` rather than
-   retrying blind (a retry after an ambiguous failure is how a double-ping happens).
-   Do not add a "ready for re-review" comment or @-mention on top of the request — the request
-   itself is the signal; a comment on top of it is the over-notification this skill exists to
-   avoid.
-
-4. **Report** the PR as signaled, and loop back to `project-status-local` to pick up the new
-   state on its next run.