claude-code-session-manager 0.110.0 → 0.112.0

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.

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

@@ -1,243 +0,0 @@
----
-name: project-status
-model: opus
-description: >-
-  GLOBAL FRAMEWORK for one operational status rollup of the project in the
-  current working directory — defines the contract (what a status report must
-  contain, in what order, on which model) and DELEGATES the project-specific
-  measurement to that project's own `project-status-local` skill. Use whenever
-  the user asks "what's the project status", "/project-status", "how is this
-  project doing", "are the jobs healthy", or wants a one-shot status rollup for
-  the repo they're in. Keywords: project status, KPI, north-star, crons, jobs,
-  last run, health, rollup, ops.
----
-
-# project-status — global framework
-
-This is the **global framework**, not an implementation. It owns the *contract*
-(what a status rollup must contain, the order, the presentation, the model
-expectation) and **delegates** the project-specific *how* to the project's own
-`project-status-local` skill.
-
-> **Two skills, no name collision (by design).**
-> `project-status` (this, global) = the framework/expectations.
-> `project-status-local` (per project) = the implementation.
-> They have **different names on purpose** — a project must NOT ship a second
-> skill also named `project-status`, because a same-name skill silently shadows
-> this one and drops everything it defines (that is exactly how the model
-> fallback got lost once). Each project ships exactly one `project-status-local`.
-
-## What to do when invoked
-
-First decide **scope**: one project (the current repo) or several (the user named
-multiple repos, said "all my projects", or wants a cross-project board).
-
-### Single project (the cwd)
-
-1. **Delegate if a local exists.** If a `project-status-local` skill is available
-   in the current project (it appears in the available-skills list), **invoke it**
-   (Skill tool, `skill: project-status-local`). It owns the specifics — which KPI
-   command to run, which crons are this project's, which health entrypoint to
-   call. Present its output; if it omits an element of the contract below, fill
-   the gap or note it.
-2. **Otherwise run the generic fallback inline** (the flow at the bottom) and, at
-   the end, **offer to scaffold a `project-status-local`** for this repo so the
-   next run is project-aware.
-
-Do not re-implement a project's specifics here — that belongs in its
-`project-status-local`.
-
-### Multiple projects (parallel fan-out)
-
-The whole point of the framework/`-local` split: the per-project work is
-**independent**, so run it **concurrently** — one project's KPI/crons/health
-never depends on another's.
-
-1. **Resolve the project list.** Use the repos the user named; for "all", or to
-   discover them, enumerate every repo that ships a local skill:
-   ```bash
-   for d in ~/Projects/*/.claude/skills/project-status-local/SKILL.md; do
-     [ -f "$d" ] && echo "${d%/.claude/skills/project-status-local/SKILL.md}"
-   done
-   ```
-2. **Fan out one agent per project — in a SINGLE message with multiple `Agent`
-   tool calls** so they run in parallel (sequential calls would defeat the
-   purpose). Each agent (`subagent_type: general-purpose`) gets a prompt like:
-   > `cd <ABS_REPO_PATH>`. Produce this repo's status rollup by executing its
-   > own `project-status-local`: **read** `.claude/skills/project-status-local/SKILL.md`
-   > and run its steps (they are deterministic — a `brief.py`/analyzer call, a
-   > `crontab -l | grep` for its crons, its `scripts/health.sh`). If the repo has
-   > no `project-status-local`, follow the generic contract (KPI→chores→health)
-   > using its `CLAUDE.md` + crontab + health entrypoint. Return a **compact**
-   > rollup (≤12 lines): the project name, the 7d North-Star line (KPI vs
-   > benchmark → alpha), the health color, and the single worst ❌/⚠️ chore.
-   Let each agent **inherit the model** (omit `model`) — it just runs the repo's
-   commands; this framework's `model: opus` governs *this* turn.
-3. **Aggregate** the returned rollups into one board: a lead table
-   (Project · 7d KPI · Health · Worst signal), RED/❌ projects first, then each
-   project's detail block beneath. Note any agent that failed to produce a rollup
-   (missing repo, broken local) rather than dropping it silently.
-
-Why agents, not the Skill tool, for the others: skill availability is bound to
-the launch repo, so `project-status-local` is only directly invokable for the
-**current** project. For other repos the agent reproduces the local by reading +
-running it (it is deterministic bash), which works from any cwd.
-
-## The contract (what every report must satisfy)
-
-Order — **1. North-Star KPI (last 7d) → 2. Chores (crons) → 3. Logs & usage
-patterns → 4. Health verdict.** Lead with the KPI line and the single worst
-❌/⚠️ chore or health signal; detail after. Keep it tight; relay engine/analyzer
-output rather than re-deriving numbers by hand.
-
-A status check is an **audit**, not just a liveness ping — it reads the project's
-*operational logs* (are the runs clean or throwing?) and its *usage/consumption
-patterns* (who consumes the product's outputs, how often, which surfaces are hot
-vs dead) alongside the KPI and crons. The KPI says "is the output valuable," the
-logs+usage say "is the machine actually being used, and is it healthy under that
-use." Both dimensions belong in every report.
-
-- **KPI (the intro):** the metric the project's `CLAUDE.md` mission statement
-  names as optimized (a `## North-Star KPI` / `## Objective` section, usually
-  linking a definition doc or a measurement command). Measure it over a trailing
-  7-day window with the project's own command; state it with the
-  benchmark/target the section defines. If `CLAUDE.md` declares no KPI, say so
-  plainly (it belongs in the mission statement) and use a git/activity summary
-  for the intro — never invent a metric.
-- **Chores:** only THIS project's cron jobs (match by repo name / absolute path),
-  each with last-run time, recent result, and an error count, in a table:
-  Job · Schedule · Purpose · Last run · Errors · Last result. Staleness: newest
-  log line older than ~2× cadence ⇒ ⚠️ overdue; an installed cron with an
-  empty/missing log ⇒ ❌ (often a Vixie-cron `TZ=` inline-prefix drop — fix with a
-  standalone `TZ=` line). Market-hours-only jobs stale overnight is expected.
-- **Logs & usage patterns:** two sub-parts, both delegated to the `-local` for
-  *where the data lives*, but expected in every report:
-  - **Logs** — scan the recent operational logs for error/warning rates,
-    tracebacks, timeouts, and silent-stall signatures (a job that "ran ok" but
-    did no work). Surface counts + the worst recent line, not just last-exit.
-  - **Usage / consumption** — how the project's *outputs* are actually consumed:
-    per-endpoint/-tool invocation counts, the consumer/tenant breakdown, and
-    hot-vs-cold surfaces over a trailing window. This answers "is what we built
-    being used, and by whom" — the dimension a KPI alone misses. The `-local`
-    names the source (a usage/metering store, an access log, or a proxy like a
-    panel/history table); if no usage source exists yet, say so and recommend
-    standing one up rather than inventing numbers.
-- **Health verdict:** run the project's own health entrypoint (first hit wins:
-  `scripts/health.sh` · `.claude/health.sh` · `bin/health.sh` · a `health`
-  Make/just target) and relay its GREEN/YELLOW/RED rollup. A non-zero exit for
-  YELLOW/RED is expected, not a skill failure; only a crash is.
-
-## After the audit — route findings, then improve (the loop)
-
-A status check shouldn't dead-end at a report. Once the four dimensions are in,
-**act on what the audit surfaced** — this is what makes `/project-status` a
-self-contained *bootstrap → evaluate → improve* loop, usable even on a brand-new
-project.
-
-**First, work the pending proposals — decide before generating new work.** Right
-after the audit, look at the project's **proposed Epics** (status `proposed` in
-`session-manager-operations/prompt-sessions/active-index.json`): these are the
-items agents filed for a human decision. Report them so the user can approve
-or discard; do not
-approve them yourself, and do not stack new levers on top of an undecided
-backlog. (If there are none, say so and move on.)
-
-There is no inbox to reconcile and no archive convention to keep in step: an
-approved proposal becomes an active Epic whose PRDs and runs are already visible
-in the Scheduler, so its status is read from the queue directly rather than
-tracked in a parallel status log.
-
-Then route **this audit's own findings**, by ownership:
-
-1. **A finding that belongs to another project** (an upstream/downstream service
-   in the stack — e.g. the data source is stale, a contract drifted): do NOT
-   reach across the boundary and do NOT open an Epic there — nothing but a human
-   pressing New Epic creates one. Report it, clearly enough that the human can
-   act on it. (Same rule as everywhere: service boundaries outrank convenience.)
-2. **A finding that belongs to THIS project** (a real bug, a missing guard, an
-   enhancement the audit revealed — a cold sold-surface, a recurring error in the
-   logs, a usage gap): queue it as a scheduled PRD via **`/develop`** — never
-   implement it inline here. Record the queued PRD id in the report.
-3. **Nothing actionable** — just report.
-
-Then stop. There is no automatic improvement gate: findings are routed as
-PRDs or reported above, and the user decides what gets worked on next.
-
-This sequence — audit → route findings (develop / report) — is enough to
-bootstrap and evaluate a project from a single `/project-status` invocation. The `-local` owns the *specifics* of each
-step; this framework owns the *loop*.
-
-## Model expectation (every local must mirror this)
-
-This framework runs on **`model: opus`** (Opus 4.8) — a status check is reasoning
-work that should run on the strongest model. **Every `project-status-local` MUST
-carry the same single-value `model: opus` frontmatter line**, so a direct
-`/project-status-local` invocation runs on Opus too. A local that omits it loses
-the override and runs on whatever the session model happens to be.
-
-> **Syntax matters — this is a real, documented field.** Skill frontmatter
-> `model:` takes a **single** value (the same aliases as `/model`: `opus`,
-> `sonnet`, `haiku`, `fable`, or a full id like `claude-opus-4-8`). It does NOT
-> accept a comma-separated fallback chain — `model: opus,sonnet` is an invalid
-> value and silently fails to apply (the skill then runs on the session model,
-> not Opus). Graceful failover to Sonnet is configured **at the session level**,
-> not per-skill, via `fallbackModel` in settings:
-> `"fallbackModel": ["opus", "sonnet"]` in `~/.claude/settings.json`. Per the
-> Claude Code docs, a skill's `model:` override applies for the rest of the
-> current turn and reverts to the session model on the next prompt.
-
-## Scaffolding a new `project-status-local` — establish the framework with the user
-
-When a project has none, **do not silently guess the implementation.** The whole
-point of the framework/`-local` split is that every project's report covers the
-**same four dimensions** (KPI · chores · logs+usage · health) — so the parent's job
-on a missing `-local` is to *establish those expectations with the user*, then
-write a complete local. Run a short **Q&A** (use `AskUserQuestion`, batching the
-gaps you couldn't auto-detect) to pin down each contract dimension:
-
-1. **Probe first, ask only the gaps.** Read `CLAUDE.md` (KPI section?), the
-   crontab (this repo's jobs + their log paths?), the repo for a health entrypoint
-   (`scripts/health.sh` etc.), and for a usage source (a metering/access-log store,
-   or a proxy table). Auto-fill what you can find.
-2. **Ask the user to confirm/supply the rest**, one question per unresolved
-   dimension:
-   - **KPI** — what is this project's North-Star metric + the command that measures
-     it over 7d? (If `CLAUDE.md` has no `## North-Star KPI` section, offer to add
-     one — the KPI belongs in the mission statement, not only the skill.)
-   - **Chores** — which crons are this project's, and where do their logs live?
-   - **Logs & usage** — which logs carry the operational signal, and **what is the
-     usage/consumption source** (a metering store / access log / proxy)? If none
-     exists, flag it and offer to stand one up — a project with no usage telemetry
-     can't answer "is what we built being used."
-   - **Health** — the health entrypoint + how to read its verdict.
-3. **Write the local** `<repo>/.claude/skills/project-status-local/SKILL.md` with
-   frontmatter `name: project-status-local`, `model: opus` (single value — see the
-   syntax note above; `fallbackModel` owns failover), a project-specific
-   `description`, and a body implementing **all four** contract dimensions against
-   the answers — so the next `/project-status` here is project-aware and consistent
-   with every other project's report.
-
-This Q&A is the deliberate "pain" that makes cross-project reports comparable:
-each `-local` is the *same contract*, filled with that project's specifics.
-
-## Generic fallback flow (no local present)
-
-Run inline only when the project ships no `project-status-local`:
-
-1. **Current time:** `date '+%Y-%m-%d %H:%M %Z'` (for staleness judgment).
-2. **KPI:** read `./CLAUDE.md`, find the North-Star section, run its measurement
-   command over 7 days, and state the headline. No KPI section ⇒ say so + git
-   summary.
-3. **Chores:** `crontab -l | grep -F "$(basename "$PWD")" | grep -v '^\s*#'`
-   (widen/narrow if the cron path differs from the dir name); for each job
-   `ls -la <log>` + `tail -n 8 <log>` + an `ERROR|Traceback|failed|exception`
-   count; render the chores table.
-4. **Logs & usage:** scan recent logs for error/warning rates + silent stalls;
-   look for a usage/consumption source (a metering store, an access log, or a
-   request/history table) and summarize per-surface invocation + consumer
-   patterns over a trailing window. If none exists, say so and recommend standing
-   one up — don't invent usage numbers.
-5. **Health:** run the project's health entrypoint and relay the rollup; if none
-   exists, infer from KPI + chores and offer to create `scripts/health.sh`.
-6. Lead with the 7d KPI line and the worst chore/health/usage signal. Then offer
-   to scaffold a `project-status-local` (Q&A above) so the next run is consistent.

package/plugins/session-manager-dev/skills/requesting-code-review/SKILL.md

@@ -1,98 +0,0 @@
----
-name: requesting-code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
----
-
-# Requesting Code Review
-
-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.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Dispatch code-reviewer subagent:**
-
-Use the Agent tool with `subagent_type: "code-reviewer"`, filling the template at `code-reviewer.md`
-
-**Placeholders:**
-- `{WHAT_WAS_IMPLEMENTED}` - What you just built
-- `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
-- `{DESCRIPTION}` - Brief summary
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-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 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
-  HEAD_SHA: 3df7661
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with /develop
-
-For scheduled work, review happens once per plan in the trailing `validate` PRD (persona
-`validator`), which runs `/code-review` and `/security-review` over the plan's combined diff and
-reports per-PRD VERIFIED/REFUTED verdicts. This skill is for an interactive session reviewing its
-own inline work. Never dispatch a `code-reviewer` subagent from a headless run — it has no next
-turn to collect the result.
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: requesting-code-review/code-reviewer.md