claude-code-session-manager 0.111.0 → 0.113.0

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

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

@@ -1,146 +0,0 @@
-# Code Review Agent
-
-You are reviewing code changes for production readiness.
-
-**Your task:**
-1. Review {WHAT_WAS_IMPLEMENTED}
-2. Compare against {PLAN_OR_REQUIREMENTS}
-3. Check code quality, architecture, testing
-4. Categorize issues by severity
-5. Assess production readiness
-
-## What Was Implemented
-
-{DESCRIPTION}
-
-## Requirements/Plan
-
-{PLAN_REFERENCE}
-
-## Git Range to Review
-
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
-
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
-
-## Review Checklist
-
-**Code Quality:**
-- Clean separation of concerns?
-- Proper error handling?
-- Type safety (if applicable)?
-- DRY principle followed?
-- Edge cases handled?
-
-**Architecture:**
-- Sound design decisions?
-- Scalability considerations?
-- Performance implications?
-- Security concerns?
-
-**Testing:**
-- Tests actually test logic (not mocks)?
-- Edge cases covered?
-- Integration tests where needed?
-- All tests passing?
-
-**Requirements:**
-- All plan requirements met?
-- Implementation matches spec?
-- No scope creep?
-- Breaking changes documented?
-
-**Production Readiness:**
-- Migration strategy (if schema changes)?
-- Backward compatibility considered?
-- Documentation complete?
-- No obvious bugs?
-
-## Output Format
-
-### Strengths
-[What's well done? Be specific.]
-
-### Issues
-
-#### Critical (Must Fix)
-[Bugs, security issues, data loss risks, broken functionality]
-
-#### Important (Should Fix)
-[Architecture problems, missing features, poor error handling, test gaps]
-
-#### Minor (Nice to Have)
-[Code style, optimization opportunities, documentation improvements]
-
-**For each issue:**
-- File:line reference
-- What's wrong
-- Why it matters
-- How to fix (if not obvious)
-
-### Recommendations
-[Improvements for code quality, architecture, or process]
-
-### Assessment
-
-**Ready to merge?** [Yes/No/With fixes]
-
-**Reasoning:** [Technical assessment in 1-2 sentences]
-
-## Critical Rules
-
-**DO:**
-- Categorize by actual severity (not everything is Critical)
-- Be specific (file:line, not vague)
-- Explain WHY issues matter
-- Acknowledge strengths
-- Give clear verdict
-
-**DON'T:**
-- Say "looks good" without checking
-- Mark nitpicks as Critical
-- Give feedback on code you didn't review
-- Be vague ("improve error handling")
-- Avoid giving a clear verdict
-
-## Example Output
-
-```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42)
-- Comprehensive test coverage (18 tests, all edge cases)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-1. **Missing help text in CLI wrapper**
-   - File: index-conversations:1-31
-   - Issue: No --help flag, users won't discover --concurrency
-   - Fix: Add --help case with usage examples
-
-2. **Date validation missing**
-   - File: search.ts:25-27
-   - Issue: Invalid dates silently return no results
-   - Fix: Validate ISO format, throw error with example
-
-#### Minor
-1. **Progress indicators**
-   - File: indexer.ts:130
-   - Issue: No "X of Y" counter for long operations
-   - Impact: Users don't know how long to wait
-
-### Recommendations
-- Add progress reporting for user experience
-- Consider config file for excluded projects (portability)
-
-### Assessment
-
-**Ready to merge: With fixes**
-
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
-```

package/src/main/lib/rateLimitDetect.cjs

@@ -1,35 +0,0 @@
-'use strict';
-
-/**
- * rateLimitDetect.cjs — the single source of truth for "did this claude -p
- * log tail show a rate-limit death". Shared by spawnJob() (a still-running
- * process that just exited) and reapDeadRunningJobs()/classifyRunOutcome()
- * (a process the reaper found already dead) — see PRD 1117. Before this,
- * only spawnJob checked this; the reaper had no rate-limit branch at all,
- * so a rate-limited exit that the reaper won the race to finalize got
- * stamped terminal 'failed' instead of retryable 'pending'. There must
- * never be a second, independently-drifting regex set at either call site.
- */
-
-const { readTail } = require('./fileTail.cjs');
-
-/** Scan the tail of a job's log for the canonical rate-limit signal. We look
- *  at the last 16 KB — final result event always lands at the end. Covers
- *  both unified-window rate-limit types (five_hour, seven_day), the raw
- *  429 status, and the two human-readable limit-message phrasings the CLI
- *  emits ("You've hit your limit" / "You've reached your <model> limit"). */
-function detectRateLimitInLog(logPath) {
-  try {
-    const text = readTail(logPath, 16384);
-    if (!text) return false;
-    return /"rateLimitType":"five_hour"/.test(text)
-      || /"rateLimitType":"seven_day"/.test(text)
-      || /"api_error_status":429/.test(text)
-      || /You'?ve hit your limit/.test(text)
-      || /You'?ve reached your .* limit/.test(text);
-  } catch {
-    return false;
-  }
-}
-
-module.exports = { detectRateLimitInLog };