claude-code-session-manager 0.37.1 → 0.38.0

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/plugins/session-manager-dev/skills/requesting-code-review/SKILL.md

@@ -5,7 +5,7 @@ description: Use when completing tasks, implementing major features, or before m
 
 # Requesting Code Review
 
-Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
+Dispatch the native `code-reviewer` subagent (via the Agent tool, `subagent_type: "code-reviewer"`) to catch issues before they cascade.
 
 **Core principle:** Review early, review often.
 
@@ -31,7 +31,7 @@ HEAD_SHA=$(git rev-parse HEAD)
 
 **2. Dispatch code-reviewer subagent:**
 
-Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`
+Use the Agent tool with `subagent_type: "code-reviewer"`, filling the template at `code-reviewer.md`
 
 **Placeholders:**
 - `{WHAT_WAS_IMPLEMENTED}` - What you just built
@@ -56,7 +56,7 @@ You: Let me request code review before proceeding.
 BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
 HEAD_SHA=$(git rev-parse HEAD)
 
-[Dispatch superpowers:code-reviewer subagent]
+[Dispatch code-reviewer subagent via the Agent tool]
   WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
   PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
   BASE_SHA: a7981ec
@@ -74,20 +74,23 @@ You: [Fix progress indicators]
 [Continue to Task 3]
 ```
 
-## Integration with Workflows
-
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-
-**Executing Plans:**
-- Review after each batch (3 tasks)
-- Get feedback, apply, continue
-
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
+## Integration with /develop
+
+This is the **default** reviewer at `/develop`'s Phase 2 done-gate (step 8) — but not the only
+one. `/develop` routes to a matching specialist first when a PRD's surface calls for it
+(`api-designer` for API-contract changes, `security-auditor` for auth/input/data, `refactorer`
+for structural refactors, `perf-profiler` for hot-path changes, `dependency-auditor` for
+dependency bumps) and only falls back to this generic reviewer for everything else or when no
+specialist fits. Don't treat this skill as covering ground those specialists already own.
+
+Since this project's actual unit of work is a scheduler PRD (not a live multi-task session), the
+review point is per-PRD, at its own commit range — `BASE_SHA`/`HEAD_SHA` above are that PRD's
+commit(s), not an arbitrary task boundary from a different workflow shape. Review:
+- **After a PRD completes**, as part of `/develop`'s definition-of-done gate (step 8) — every
+  major/risky PRD, before calling it done.
+- **When a PRD comes back `needs_review`** — read the scheduler's auto-filed RCA first
+  (`rcaFeedbackHook`'s `<date>-rca-<slug>-<runId>.md`), then use this review to confirm the fix
+  if one gets queued.
 
 ## Red Flags