claude-code-session-manager 0.37.2 → 0.38.0

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

@@ -0,0 +1,120 @@
+---
+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/pr-review-sweep/0-fetch/SKILL.md

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

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

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

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

@@ -0,0 +1,50 @@
+---
+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.
+- **`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

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

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

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

package/src/main/__tests__/chat-cancel-terminal.test.cjs

@@ -75,6 +75,37 @@ test('cancelling an ACTIVE run broadcasts a terminal event (unsticks the UI)', a
   assert.match(terminal[0].payload.message, /cancel/i, 'message names the cancellation');
 });
 
+test('cancel() resolves only AFTER the terminal broadcast fires, not immediately on SIGTERM (PRD 718)', async () => {
+  // Order-of-events assertion (not timing-based — a real SIGTERM can be fast
+  // enough on a lightweight stub child that a fixed-delay race would flake).
+  const order = [];
+  cr.attachWindow({
+    isDestroyed: () => false,
+    webContents: {
+      isDestroyed: () => false,
+      send: (channel, payload) => {
+        if (isTerminal(channel) && payload.tabId === 'T2') order.push('terminal');
+      },
+    },
+  });
+
+  cr.run({ tabId: 'T2', sessionId: 'S2', prompt: 'hello', cwd: process.cwd(), resume: false });
+
+  for (let i = 0; i < 6; i++) await tick();
+
+  await cr.cancel('T2').then(() => order.push('resolved'));
+
+  assert.deepEqual(order, ['terminal', 'resolved'], 'cancel() resolves strictly after the terminal broadcast');
+});
+
+test('cancel() on a tab with no in-flight or waiting run resolves immediately (no-op)', async () => {
+  cr.attachWindow({
+    isDestroyed: () => false,
+    webContents: { isDestroyed: () => false, send: () => {} },
+  });
+  await cr.cancel('no-such-tab'); // must resolve, not hang
+});
+
 function isTerminal(channel) {
   return (
     channel === 'chat:run:complete' ||