claude-code-session-manager 0.37.1 → 0.38.0

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

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

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

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

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

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

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

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

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

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

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.