claude-code-session-manager 0.110.0 → 0.112.0

package/plugins/session-manager-dev/skills/discover-features/SKILL.md

@@ -1,95 +0,0 @@
----
-name: discover-features
-description: >-
-  Propose and prototype NEW features for the current project. Reads the project's issues, PRs,
-  `main`, and md/docs to learn its objectives, then runs THREE independent discovery sessions
-  (each may also web-search for ideas) that every one proposes 5 high-level feature ideas best
-  fitting the project's goals — 15 total. Synthesises and ranks them, picks the top 3, and runs a
-  high-quality `/develop` build for each. Delivers a deployed URL per feature plus a validation
-  checklist so the human can try them — and NEVER opens a PR or a GitHub issue from a proposed
-  feature (the human validates first, then decides). Use when the user says "/discover-features",
-  "propose features", "discover feature opportunities", "what should we build next", "prototype
-  some new features for me to try". Keywords: discover, propose, feature, opportunity, ideation,
-  prototype, what's next, roadmap.
----
-
-# /discover-features — propose → prototype → hand over URLs (no PRs)
-
-**Role:** the *generative* counterpart to `/find-opportunity`. `/find-opportunity` triages the
-*existing* backlog to pick the next issue to resolve; `/discover-features` *invents* net-new
-features the backlog doesn't contain yet, prototypes the best ones, and hands the human running
-URLs to validate. It is for "what should we build next?", not "which open issue next?".
-
-**Hard rules (do not violate):**
-- **Never open a PR or a GitHub issue** from a proposed feature. The deliverable is a *running,
-  validatable prototype on a branch* + a URL + a validation checklist — the human decides what
-  (if anything) becomes a PR. (See the `solve-dont-open-issues` principle.)
-- **No fabricated data.** Prototypes run on the project's real data layer / real queries. If a
-  feature needs data that doesn't exist, it shows an honest empty state — never seeded fakes.
-- **Don't touch `main`.** Build on a fresh branch (or worktrees) off the latest `main`.
-- **Respect the conflict-skip sense** (from `/find-opportunity`): don't prototype something an
-  open PR is already building.
-
-## Phase 0 — Ground in the project's objectives
-
-Before ideating, learn what the project is *for* (so ideas fit, not just dazzle):
-```bash
-gh issue list --state open --limit 100 --json number,title,labels
-gh pr list   --state all  --limit 60  --json number,title,headRefName,state
-ls docs/ README.md AGENTS.md CLAUDE.md 2>/dev/null
-```
-Read the design docs / README / AGENTS for the mission, the north-star, the explicit
-non-goals/constraints, and the data model. Extract a short **objectives + constraints** brief —
-this is the anchor every discovery session and the ranking use.
-
-## Phase 1 — THREE independent discovery sessions (fan-out)
-
-Spawn **3 independent agents in parallel**. Each gets the objectives brief and is told to think
-differently from the others (assign distinct stances, e.g. *user-value first* / *data-leverage
-first* / *differentiation-&-novelty first*). Each agent:
-- Re-reads the issues / PRs / `main` / docs itself (independent grounding, not just your brief).
-- **May web-search** for ideas — comparable products, domain best-practice, what peer
-  civic/▢-tech projects ship — and bring back what genuinely fits.
-- Returns **exactly 5 high-level feature ideas**, each with: one-line pitch; which project
-  objective it advances; the data/infra it leans on (must already exist or be honestly stubbable);
-  rough surface (new route/page is preferred so it's independently deployable + validatable); a
-  novelty/effort/impact read. Be creative — no artificial limits.
-
-15 ideas total. Keep each agent blind to the others (diversity > consensus).
-
-## Phase 2 — Synthesise & rank → top 3
-
-Merge the 15. De-dupe near-identicals (keep the sharpest framing). Drop anything that: an open PR
-already builds, needs data the project doesn't have, or is a multi-week epic that can't reach a
-*validatable* prototype in one build. Rank the survivors by **objective-fit × user-value ×
-prototype-feasibility**. Pick the **top 3**. State *why* each won and what you dropped (no silent
-cuts). Prefer 3 that are independently deployable (separate routes) so the human can validate each
-in isolation.
-
-## Phase 3 — High-quality build of each top-3 feature
-
-For each of the 3, run a `/develop` `quality: high`-style build (deep-check → plan → implement →
-tests → self-validate). Build all three on **one branch** (or worktrees) so a single running app
-serves all three. Wire each as its own route/page where possible. Real data via real queries;
-honest empty states. Typecheck + the project's tests must pass before you call a feature done.
-
-## Phase 4 — Deploy locally & hand over (NO PR)
-
-Launch the project's dev server (or preview) so the features are reachable. Deliver, per feature:
-- **The URL** it's live at (e.g. `http://localhost:<port>/<route>`).
-- **What it does** in two lines + which objective it serves.
-- **A validation checklist** — concrete things for the human to click/observe to judge it
-  ("filter to sector X, confirm the sparkline matches the table total", "open on mobile width",
-  "try an entity with no data → honest empty state").
-- Note any assumptions or stubs.
-
-End with: the branch name (un-pushed), the 3 URLs, and "say which to keep → I'll turn those into
-PRs." **Do not push or PR anything yourself.**
-
-## Notes
-- This skill is token-intensive by design (3 discovery sessions + 3 builds). Run it when the user
-  has explicitly asked for a feature-ideation+prototype round, typically as an overnight batch.
-- If the dev server can only serve one branch at a time, that's fine — all three features share
-  the one branch and one server; give three routes/URLs on it.
-- Keep ideas anchored to the project's actual objectives — a brilliant idea that fights the
-  mission is noise. Creativity in service of the goal, not despite it.

package/plugins/session-manager-dev/skills/explain-to-me/SKILL.md

@@ -1,205 +0,0 @@
----
-name: explain-to-me
-description: >-
-  Build and maintain session-manager-operations/HUMAN_LEARN/ — a human-readable,
-  visually-rich HTML knowledge base at the repo root that explains how this
-  project actually works. Deep-probes the codebase for a given topic/component
-  (real file:line refs, real constants, real on-disk state — never invented),
-  then writes or updates a clean, self-contained HTML — one combined component
-  page (session-manager-operations/HUMAN_LEARN/index.html) plus a separate
-  skill-chain map (session-manager-operations/HUMAN_LEARN/SKILL_MAP.html) for
-  the local-dev workflow — with advanced CSS, flow diagrams, sticky nav,
-  collapsible tables. Use whenever the user says "/explain-to-me X", "explain X
-  to me", "explain how X works", "document X for me", "add X to HUMAN_LEARN",
-  "make me a human-readable page for X", or "update the skill map". Keywords:
-  explain, explain-to-me, human-learn, HUMAN_LEARN, skill map, document,
-  one-pager, how does X work, visual explainer, knowledge base.
-model: opus
----
-
-# explain-to-me
-
-Turn a question about this codebase ("explain how the scheduler works") into a
-**clean, visually-rich HTML one-pager** in `session-manager-operations/HUMAN_LEARN/`
-at the repo root, and keep that folder's index coherent as it grows. The output
-is for a *human* catching up on the project — not for the model. It is the
-human-facing complement to the Memory tab (which is Claude's own terse recall
-store). All session-manager per-project operations live under
-`session-manager-operations/`.
-
-The bar: **clean, explanatory, visually rich, self-contained** (opens directly in
-a browser — no build, no external network deps). Every claim grounded in the
-actual code.
-
-**Document the CURRENT state, present-tense — never the journey.** A reader wants
-to know *what the project is and how it works right now*, not how it got there.
-This is a snapshot of the system as it stands today, not a changelog. So:
-
-- **No PRD numbers, ticket ids, or commit refs** ("added in PRD 66", "schema
-  bumped to v3"). State the field/behavior as it simply *is* — `panels.ticker_metrics`
-  *carries* an `as_of` freshness field; don't say when or why it was added.
-- **No evolution or "was X → now Y"** ("grew from 2 to 5 tools", "migrated off the
-  local cache", "reborn processed"). Describe the 5 tools that exist; the prior
-  count is irrelevant to someone reading today.
-- **No incident/history narrative** ("the 06-10 churn incident", "the outage that
-  shaped this", "the bug we fixed"). If a guard exists, describe *what it guards*
-  in the present, not the failure that motivated it.
-- **No migration tiers / in-flight roadmap / "gated" future work.** Document what
-  is true now; a thing that's being retired is just "internal, not on the public
-  surface" today.
-
-Present-tense **design rationale is fine and useful** — *why the system is shaped
-this way as it stands* (a tradeoff, a complexity bound, a boundary rule). That is
-not history. The line is: explain the *standing* reason, never the *chronology*.
-If you can't state it in the present tense without a date or a PRD, cut it.
-
-## Where things live
-
-- Repo root: `git rev-parse --show-toplevel` (fall back to cwd if not a git repo).
-- Knowledge base: `<root>/session-manager-operations/HUMAN_LEARN/`. Create it
-  (and `session-manager-operations/` if needed) if missing.
-- **One combined page** — `session-manager-operations/HUMAN_LEARN/index.html`.
-  Every component explainer is a `<section>` in this single file, under a sticky
-  section-nav, ordered so the page reads top-to-bottom as one narrative. A new
-  topic becomes a **new `<section>`**, never a new file. One navigable page that
-  logically follows itself beats a folder of thin pages; do not re-introduce
-  per-topic `.html` files.
-- **The Skill Map** — `session-manager-operations/HUMAN_LEARN/SKILL_MAP.html`, a
-  **separate, dedicated** page (NOT a section of index.html) that visualizes the
-  *local-development skill chain*: the two intakes (interactive human prompt;
-  human-opened Epics in the app) converging on `/develop`, which owns
-  PRD authoring + reads `standards.md`, queues onto the scheduler, and gates with
-  review/verify. It is the "how I build on this
-  project" companion to index.html's "how this project works." index.html links
-  to it from the nav; it links back.
-
-## Workflow
-
-0. **Self-migrate a legacy root-level folder first.** If `HUMAN_LEARN/` exists
-   at the repo root **and** `session-manager-operations/HUMAN_LEARN/` does not,
-   relocate it now — `mkdir -p session-manager-operations` (if needed), then
-   `git mv HUMAN_LEARN session-manager-operations/HUMAN_LEARN` when the repo is
-   git-tracked, else a plain `mv`. This converges any project this skill runs
-   in to the new layout even if its bulk-relocation PRD hasn't landed yet.
-1. **Locate & survey.** Find the repo root + `session-manager-operations/HUMAN_LEARN/`.
-   If `index.html` exists, read it to see what's already documented — you are
-   *maintaining* a knowledge base, not starting fresh. If the topic already has
-   a page/section, you are updating it, not duplicating it.
-2. **Deep-probe the topic.** Read the real code. Gather exact `file:line`
-   references, real constant names + values, and real on-disk state where it
-   matters (run `ls`/`cat`/`jq` to ground claims in what actually exists). For a
-   broad topic, fan out parallel `Explore` subagents over the relevant
-   subsystems and collect the conclusions. **Never invent** a path, constant, or
-   behavior — if you can't verify it, don't write it.
-3. **Decide placement.** A component/subsystem topic → a new (or edited) `<section>`
-   in `index.html`, slotted into the narrative order. The dev skill chain → it's in
-   `SKILL_MAP.html`. Re-explaining an existing topic → edit that section in place,
-   refresh the "generated" date. Never spin up a new per-topic `.html`.
-4. **Write the HTML.** Use the design system below — both pages share the same tokens
-   and components so they read as one product. A page must be self-contained (inline
-   `<style>`, no external fonts/scripts/CDNs). Lead with what the thing *is* and *when
-   it runs*, then the step-by-step flow with `file:line` tags, then the knobs (a
-   collapsible constants table), then the present-tense design rationale ("why
-   it's shaped this way" as it *stands* — a standing tradeoff/bound, never a dated
-   history or a PRD).
-5. **Wire the navigation.** Add/refresh the topic's pill in `index.html`'s sticky
-   section-nav (and the footer's source-file list). Keep the nav and `SKILL_MAP.html`
-   cross-links intact: index.html's nav has a "⛓ Skill Map ↗" link, SKILL_MAP.html's
-   nav links back to "📖 HUMAN_LEARN".
-6. **Maintain the Skill Map.** When the local-dev skills/commands change — a new skill
-   in `~/.claude/skills/`, a changed Role/Never contract, a re-routed step in the
-   chain — refresh `SKILL_MAP.html` (its chain diagram + the role-contract table +
-   the two walkthroughs) so it stays a faithful map of the actual files on disk.
-7. **Tell the user the path** to open (`session-manager-operations/HUMAN_LEARN/index.html`
-   or `session-manager-operations/HUMAN_LEARN/SKILL_MAP.html`, optionally with a
-   `#anchor`). Do not commit unless asked.
-
-## Grounding rules (non-negotiable)
-
-- Every behavioral claim cites a real `file:line`. Spot-check by reading the
-  cited line before writing it.
-- Constants show their real values from the source, not approximations.
-- "On disk" claims are verified with a real command first.
-- If two sources disagree (e.g. a stale CLAUDE.md vs the code), trust the code
-  and note the discrepancy.
-
-## Maintenance
-
-- Idempotent: re-running for the same topic updates that `<section>` (and its nav
-  pill) in place — it never appends a duplicate or spawns a new file.
-- Never clobber unrelated sections. Edit the one section the topic owns.
-- Refresh the footer "generated <date>" and the source-file list on each update.
-- HUMAN_LEARN holds exactly two pages: `index.html` (components, one combined page)
-  and `SKILL_MAP.html` (the dev skill chain). They cross-link via their navs. Don't
-  add a third page.
-
-## Design system
-
-Reuse these tokens and patterns verbatim so every page looks like one product.
-A complete, copy-ready exemplar lives at `assets/style-reference.html` next to
-this file — **read it and mirror its structure/CSS** for any new page. The
-essentials:
-
-**Palette + base** (inline `<style>`, dark theme):
-
-```css
-:root{
-  --bg:#0d1117; --panel:#161b22; --panel2:#1c2330; --line:#2d333b;
-  --fg:#e6edf3; --dim:#9da7b3; --faint:#6e7681;
-  --blue:#60a5fa; --green:#34d399; --amber:#fbbf24; --violet:#a78bfa;
-  --pink:#f472b6; --red:#f87171; --cyan:#22d3ee;
-  --mono:ui-monospace,'SF Mono',Menlo,Consolas,monospace;
-}
-*{box-sizing:border-box;margin:0;padding:0}
-html{scroll-behavior:smooth}
-body{background:var(--bg);color:var(--fg);
-  font:15px/1.6 ui-sans-serif,system-ui,sans-serif;padding:0 20px 80px}
-.wrap{max-width:980px;margin:0 auto}
-code{font-family:var(--mono);font-size:12.5px;background:var(--panel2);
-  border:1px solid var(--line);border-radius:4px;padding:1px 5px}
-pre{font-family:var(--mono);font-size:12px;background:var(--panel);
-  border:1px solid var(--line);border-radius:8px;padding:14px 16px;overflow-x:auto}
-```
-
-**Component patterns** (use the ones the topic needs — don't force all of them):
-
-- **`.loc` chip** — a cyan monospace pill for every `file:line` reference. This is
-  the signature element: claims are traceable.
-  `font:11px var(--mono);color:var(--cyan);background:rgba(34,211,238,.08);
-  border:1px solid rgba(34,211,238,.25);border-radius:99px;padding:1px 9px`
-- **`.proc` badge** — colored uppercase pill marking *where* a step runs
-  (e.g. shell hook / main process / subprocess / renderer / disk / network). One
-  color per layer; show a legend once near the top.
-- **Sticky section nav** — for multi-section pages: a `position:sticky;top:0`
-  bar with `backdrop-filter:blur(6px)` and pill links to each `#section`.
-- **Flow diagram** — a horizontal row of `.box` cards joined by `→` arrows for a
-  pipeline, OR a numbered vertical "stage" stack for a deeper step-by-step. Each
-  box: a title, a one-line what, and a `.where` `file:line`. Color the top border
-  by the layer it runs in.
-- **Stat strip** — a row of big-number cards for the load-bearing figures
-  (counts, caps, sizes) pulled from real state.
-- **Callout** — left-border tinted block for "the key insight" / "the caveat"
-  (`.ok` green, `.bad` red, default amber).
-- **Collapsible constants table** — `<details><summary>` wrapping a table of
-  `constant · value · file:line · what it bounds`. Keeps the page scannable.
-- **Two-column rationale** — a `grid-template-columns:1fr 1fr` "why it's shaped
-  this way" section, collapsing to one column under `@media(max-width:760px)`.
-- **Footer** — muted, lists the exact source files the page was distilled from +
-  "generated <date>".
-
-**Advanced techniques to deploy** (tasteful, not gratuitous): CSS grid layouts,
-`position:sticky` nav, `scroll-behavior:smooth` + anchor links, `backdrop-filter`,
-`<details>`/`<summary>` for progressive disclosure, responsive `@media`
-breakpoints, CSS-only flow diagrams (borders + flex, no images), subtle
-`transition`/`:hover` affordances on cards. **No** external fonts, scripts, CDNs,
-or build step — every page is one self-contained `.html` file.
-
-## What good looks like
-
-Lead with the outcome (what the thing *is*, when it runs). Make the flow the
-centerpiece. Tag everything with `file:line`. Surface the real numbers. Give the
-present-tense design rationale where it helps (the *standing* tradeoff or
-constraint that makes the shape make sense) — but **no chronology**: no PRD
-numbers, no "was X → now Y", no incident/migration history, no roadmap. A reader
-should learn what the project *is* today, not how it got here. Keep prose tight
-and in complete sentences — visually rich, not noisy.

package/plugins/session-manager-dev/skills/explain-to-me/assets/style-reference.html

@@ -1,163 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="UTF-8">
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>explain-to-me · style reference (copy this)</title>
-<!--
-  STYLE REFERENCE for the /explain-to-me skill.
-  This is a complete, self-contained exemplar page. When writing a HUMAN_LEARN
-  page, mirror this structure and CSS. Replace the placeholder "Widget Pipeline"
-  content with the real, file:line-grounded explanation of the user's topic.
-  Every component below is optional — use the ones the topic needs.
--->
-<style>
-  :root{
-    --bg:#0d1117; --panel:#161b22; --panel2:#1c2330; --line:#2d333b;
-    --fg:#e6edf3; --dim:#9da7b3; --faint:#6e7681;
-    --blue:#60a5fa; --green:#34d399; --amber:#fbbf24; --violet:#a78bfa;
-    --pink:#f472b6; --red:#f87171; --cyan:#22d3ee;
-    --mono:ui-monospace,'SF Mono',Menlo,Consolas,monospace;
-  }
-  *{box-sizing:border-box;margin:0;padding:0}
-  html{scroll-behavior:smooth}
-  body{background:var(--bg);color:var(--fg);font:15px/1.6 ui-sans-serif,system-ui,sans-serif;padding:0 20px 80px}
-  .wrap{max-width:980px;margin:0 auto}
-  a{color:var(--blue);text-decoration:none} a:hover{text-decoration:underline}
-  .crumb{font-size:12px;color:var(--faint);margin:24px 0 14px}
-  h1{font-size:28px;letter-spacing:-.5px;margin-top:26px}
-  .sub{color:var(--dim);margin:8px 0 6px;max-width:780px}
-  h2{font-size:22px;margin:44px 0 12px;padding-top:18px;border-top:1px solid var(--line)}
-  h3{font-size:16px;margin:24px 0 8px}
-  p{margin:8px 0;color:var(--dim)} p strong,li strong{color:var(--fg)}
-  ul.tight{margin:6px 0 6px 20px;color:var(--dim);font-size:13.5px} ul.tight li{margin:4px 0}
-  code{font-family:var(--mono);font-size:12.5px;background:var(--panel2);border:1px solid var(--line);border-radius:4px;padding:1px 5px;color:var(--fg);white-space:nowrap}
-  pre{font-family:var(--mono);font-size:12px;background:var(--panel);border:1px solid var(--line);border-radius:8px;padding:14px 16px;overflow-x:auto;margin:10px 0;line-height:1.55}
-  pre code{background:none;border:none;padding:0;white-space:pre}
-
-  /* signature element: every file:line reference is a traceable chip */
-  .loc{font-family:var(--mono);font-size:11px;color:var(--cyan);background:rgba(34,211,238,.08);border:1px solid rgba(34,211,238,.25);border-radius:99px;padding:1px 9px;white-space:nowrap}
-
-  /* layer badges — one color per place a step runs */
-  .proc{font-size:11px;text-transform:uppercase;letter-spacing:.08em;padding:1px 8px;border-radius:99px;border:1px solid}
-  .proc.hook{color:var(--amber);border-color:rgba(251,191,36,.4);background:rgba(251,191,36,.07)}
-  .proc.main{color:var(--green);border-color:rgba(52,211,153,.4);background:rgba(52,211,153,.07)}
-  .proc.sub{color:var(--violet);border-color:rgba(167,139,250,.4);background:rgba(167,139,250,.07)}
-  .proc.rend{color:var(--pink);border-color:rgba(244,114,182,.4);background:rgba(244,114,182,.07)}
-  .proc.disk{color:var(--cyan);border-color:rgba(34,211,238,.4);background:rgba(34,211,238,.07)}
-  .legend{display:flex;flex-wrap:wrap;gap:14px;margin:10px 0;font-size:12px;color:var(--dim)}
-
-  /* sticky in-page nav */
-  nav.toc{position:sticky;top:0;z-index:10;background:rgba(13,17,23,.92);backdrop-filter:blur(6px);border-bottom:1px solid var(--line);margin:0 -20px;padding:10px 20px}
-  nav.toc .row{max-width:980px;margin:0 auto;display:flex;gap:8px;flex-wrap:wrap}
-  nav.toc a{font-size:13px;padding:4px 14px;border-radius:99px;border:1px solid var(--line);color:var(--dim)}
-  nav.toc a:hover{color:var(--fg);border-color:var(--faint);text-decoration:none}
-
-  /* stat strip */
-  .statline{display:flex;gap:18px;flex-wrap:wrap;margin:16px 0}
-  .stat{background:var(--panel);border:1px solid var(--line);border-radius:8px;padding:10px 18px}
-  .stat .v{font-size:22px;font-weight:700} .stat .k{font-size:11px;text-transform:uppercase;letter-spacing:.07em;color:var(--faint)}
-
-  /* horizontal flow diagram */
-  .flow{display:flex;flex-wrap:wrap;gap:8px;align-items:stretch;margin:16px 0}
-  .flow .box{flex:1 1 150px;min-width:150px;background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:10px 12px}
-  .flow .box .bt{font-weight:700;font-size:13px;margin-bottom:2px}
-  .flow .box .bd{font-size:12px;color:var(--dim)}
-  .flow .box .where{font-family:var(--mono);font-size:10px;color:var(--cyan);margin-top:6px}
-  .flow .arrow{align-self:center;color:var(--faint);font-size:18px;flex:0 0 auto}
-  .box.b-amber{border-top:3px solid var(--amber)} .box.b-green{border-top:3px solid var(--green)}
-  .box.b-violet{border-top:3px solid var(--violet)} .box.b-cyan{border-top:3px solid var(--cyan)}
-  .box.b-pink{border-top:3px solid var(--pink)}
-
-  /* callouts */
-  .callout{border-left:3px solid var(--amber);background:rgba(251,191,36,.06);border-radius:0 8px 8px 0;padding:12px 16px;margin:14px 0;font-size:14px;color:var(--dim)}
-  .callout.ok{border-color:var(--green);background:rgba(52,211,153,.06)}
-  .callout.bad{border-color:var(--red);background:rgba(248,113,113,.06)}
-  .callout strong{color:var(--fg)}
-
-  /* tables + collapsible knobs */
-  table{border-collapse:collapse;width:100%;margin:12px 0;font-size:13px}
-  th,td{text-align:left;padding:6px 11px;border:1px solid var(--line)}
-  th{background:var(--panel2);font-size:11.5px;text-transform:uppercase;letter-spacing:.05em;color:var(--dim)}
-  td{background:var(--panel);color:var(--dim)} td code{white-space:nowrap}
-  details.consts summary{cursor:pointer;font-size:13px;color:var(--blue);margin:10px 0}
-
-  /* two-column rationale */
-  .twocol{display:grid;grid-template-columns:1fr 1fr;gap:16px}
-  @media(max-width:760px){.twocol{grid-template-columns:1fr}.flow .box{flex-basis:100%}}
-
-  footer{margin-top:60px;padding-top:16px;border-top:1px solid var(--line);font-size:12px;color:var(--faint)}
-</style>
-</head>
-<body>
-
-<nav class="toc"><div class="row">
-  <a href="index.html">📖 HOME</a>
-  <a href="#flow">Flow</a>
-  <a href="#knobs">Knobs</a>
-  <a href="#why">Why</a>
-</div></nav>
-
-<div class="wrap">
-  <div class="crumb"><a href="index.html">HUMAN_LEARN</a> / Widget Pipeline</div>
-  <h1>⚙️ Widget Pipeline — how a request becomes a widget</h1>
-  <p class="sub">
-    One-sentence lead: what this is and when it runs. (Replace this whole page with the
-    real, <code>file:line</code>-grounded explanation of the user's topic — this file is only the
-    visual template.)
-  </p>
-  <div class="legend">
-    <span><span class="proc hook">trigger</span> what kicks it off</span>
-    <span><span class="proc main">core</span> main logic</span>
-    <span><span class="proc sub">worker</span> spawned work</span>
-    <span><span class="proc disk">store</span> persistence</span>
-  </div>
-
-  <div class="statline">
-    <div class="stat"><div class="v">5</div><div class="k">stages</div></div>
-    <div class="stat"><div class="v">20</div><div class="k">batch cap</div></div>
-    <div class="stat"><div class="v">8&nbsp;MB</div><div class="k">read window</div></div>
-  </div>
-
-  <h2 id="flow">The flow, step by step</h2>
-  <div class="flow">
-    <div class="box b-amber"><div class="bt">1 · Trigger</div><div class="bd">what starts it</div><div class="where">file.ext:NN</div></div>
-    <div class="arrow">→</div>
-    <div class="box b-green"><div class="bt">2 · Read</div><div class="bd">bounded input read</div><div class="where">file.ext:NN</div></div>
-    <div class="arrow">→</div>
-    <div class="box b-green"><div class="bt">3 · Transform</div><div class="bd">the core step</div><div class="where">file.ext:NN</div></div>
-    <div class="arrow">→</div>
-    <div class="box b-sub b-violet"><div class="bt">4 · Work</div><div class="bd">spawned subprocess</div><div class="where">file.ext:NN</div></div>
-    <div class="arrow">→</div>
-    <div class="box b-cyan"><div class="bt">5 · Persist</div><div class="bd">atomic write</div><div class="where">file.ext:NN</div></div>
-  </div>
-
-  <h3>3 · Transform <span class="proc main">core</span> <span class="loc">file.ext:120-148</span></h3>
-  <p>Prose explaining the step, with inline <code>constants</code> and a <span class="loc">file.ext:NN</span> for
-  each claim. Show a real snippet when it clarifies:</p>
-  <pre><code>doThing(input, { cap: 20, windowBytes: 8 * 1024 * 1024 })</code></pre>
-
-  <div class="callout ok"><strong>Key insight.</strong> The one thing a reader must take away —
-  e.g. why the design is correct, or the invariant it preserves.</div>
-
-  <h2 id="knobs">The knobs</h2>
-  <details class="consts" open><summary>All constants (real names + values)</summary>
-  <table>
-    <tr><th>Constant</th><th>Value</th><th>Where</th><th>Bounds</th></tr>
-    <tr><td><code>BATCH</code></td><td>20</td><td><span class="loc">file.ext:50</span></td><td>items per unit of work</td></tr>
-    <tr><td><code>MAX_BYTES</code></td><td>8 MB</td><td><span class="loc">file.ext:52</span></td><td>read window per run</td></tr>
-  </table>
-  </details>
-
-  <h2 id="why">Why it's shaped this way</h2>
-  <div class="twocol">
-    <div><h3>Constraint A</h3><p>The real reason — an incident, a platform limit, a cost guard.</p></div>
-    <div><h3>Constraint B</h3><p>Another forcing function that explains a non-obvious choice.</p></div>
-  </div>
-
-  <footer>
-    HUMAN_LEARN · &lt;project&gt; · generated &lt;date&gt; from <code>file.ext</code> + live on-disk state.
-  </footer>
-</div>
-</body>
-</html>

package/plugins/session-manager-dev/skills/find-opportunity/SKILL.md

@@ -1,83 +0,0 @@
----
-name: find-opportunity
-description: >-
-  Triage a shared repo's open issues against open PRs and main to produce a ranked
-  shortlist of what to work on next, PLUS an explicit, reasoned skip-list of what NOT to
-  pick (already claimed by a PR — even one only referenced via the PR's title, not a
-  "Closes #" line — or would conflict with an open PR's diff, or is blocked/needs-decision).
-  Recommendation only; the human picks. Never opens or files anything. Use whenever the
-  user says "/find-opportunity", "what should I work on next", "pick the next issue", or
-  wants a ranked backlog triage for a repo with multiple contributors/open PRs. Keywords:
-  triage, backlog, next issue, opportunity, ranked shortlist, skip list, PR conflict,
-  issue claimed.
----
-
-# /find-opportunity — rank what to work on next, and say what NOT to touch
-
-**Role:** the *triage* front-half of a "work the backlog well" loop
-(`find-opportunity → develop → repeat`). It answers "what should I pick up next in this
-repo" for a shared/multi-contributor project where picking wrong (a duplicate, a merge
-fight) wastes real work. It never implements — that's `/develop`'s job once a human
-approves a pick.
-
-**The skip-list is the point, not a footnote.** Knowing what *not* to pick is as
-important as ranking what to pick. Every skip gets a reason and, where applicable, the
-blocking PR number — never a silent omission.
-
-## Procedure
-
-1. **Gather.** For the target repo (current cwd unless the user names another):
-   - Open issues: `gh issue list --state open --json number,title,labels,assignees,body`
-     (or the project's own issue tracker if it doesn't use GitHub issues — ask if unclear).
-   - Open PRs: `gh pr list --state open --json number,title,body,headRefName,files`.
-   - `main`'s current state (`git log --oneline -20`, `git status`) for recency context.
-
-2. **Claim-match each issue against open PRs — match aggressively, not just `Closes #`.**
-   An issue is CLAIMED when any of these link it to an open PR:
-   - The PR body has `Closes #N` / `Fixes #N` / `Resolves #N` (the obvious case).
-   - The PR **title** references the issue number (`(#N)`, `#N:`, etc.) — don't rely on
-     body-only scanning; a title-only reference is real and easy to miss with a naive
-     `Closes #` grep.
-   - The PR's branch name encodes the issue number or a close paraphrase of its title.
-   - A linked-PR field the tracker itself exposes (GitHub's "Development" issue↔PR link,
-     if the API surfaces it).
-
-3. **Conflict-match each remaining issue against open PRs' diffs.** For an issue not
-   already claimed, check whether fixing it would likely touch files an open PR is
-   actively rewriting (`gh pr list --json files` per PR, cross-referenced against the
-   issue's likely target files — infer from the issue body/title, or a quick grep for the
-   feature area named). High churn overlap on shared/hot files (a core module, a global
-   stylesheet several PRs touch) → SKIP or DEFER. Cold files (isolated tests, an
-   untouched route) → safe to proceed even if some other PR is open elsewhere in the repo.
-
-4. **Skip anything blocked or owned.** `status: needs-decision`, an assignee already set,
-   or a "discussion"/"blocked" label → SKIP, not ranked. Not actionable solo.
-
-5. **Rank what survives** by impact ÷ conflict-risk. Impact from priority/severity labels,
-   blast radius (how many surfaces/users it affects), and staleness (an old high-severity
-   bug outranks a new low one). Conflict-risk from step 3's file-overlap check (even a
-   non-blocking overlap lowers rank — prefer the fully-cold pick when impact is close).
-
-6. **Report both lists, every entry reasoned:**
-   - **Shortlist** (ranked): issue #, title, one-line reasoning (why this rank), impact
-     signal, conflict-risk signal.
-   - **Skip list** (unranked, exhaustive over everything considered): issue #, title,
-     reason (claimed by PR #N via <title/body/branch> / conflicts with PR #M's diff on
-     `<file>` / blocked-status / needs-decision / assignee set). Never drop an item
-     silently — if it was considered, it's in one list or the other.
-
-7. **Recommend, don't act.** End with the top pick and why, but the human chooses. Do not
-   open an issue, start work, or file a PR from this skill — that's `/develop`'s job,
-   invoked separately once a pick is approved.
-
-## Notes
-
-- This skill only *reads* the tracker (issues/PRs) and git state — it makes no commits,
-  opens nothing, and files nothing. If the loop surfaces a genuine follow-up that can't be
-  picked now, note it in the report; do not auto-file a new issue or open an Epic
-  for it. Filing anything public/outward is a human decision, not this skill's default.
-- Don't rank an item you couldn't verify is actually unclaimed and non-conflicting — when
-  in doubt, put it in the skip list with the uncertainty stated, rather than ranking a
-  risky guess highly.
-- Standalone-useful on its own (triage without ever running `quality: high` on the pick) —
-  don't assume this skill is only ever the front-half of a longer loop.

package/plugins/session-manager-dev/skills/issue-address/0-select/0-fetch-pool/SKILL.md

@@ -1,38 +0,0 @@
----
-name: issue-address:select:fetch-pool
-description: Fetch the FULL open-issue pool on the current project's repo with bodies, with verified completeness (not just a fixed --limit guess). First sub-step of issue-address:select.
----
-
-# issue-address:select:fetch-pool
-
-## Steps
-
-1. **Fetch with a generous limit, then verify nothing was truncated** — don't trust a
-   single fixed `--limit` the way an earlier version of this skill (and, separately,
-   `pr-review-sweep`'s original GraphQL query) did; both silently truncated real data on
-   this repo before. Converge instead of guessing:
-   ```bash
-   LIMIT=100
-   while true; do
-     COUNT=$(gh issue list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --limit "$LIMIT" --json number --jq 'length')
-     if [ "$COUNT" -lt "$LIMIT" ]; then break; fi   # got everything — count came in under the cap
-     LIMIT=$((LIMIT * 2))                            # cap was hit exactly — double and re-check
-   done
-   gh issue list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state open --limit "$LIMIT" \
-     --json number,title,body,labels,assignees,comments,createdAt,reactionGroups
-   ```
-   `COUNT == LIMIT` is the tell that you hit the ceiling, not the true end of the list —
-   never treat that as "done." Only stop once a fetch returns fewer results than it was
-   capped at.
-
-2. **Fetch bodies, not just titles.** Title-only scanning is what let issue #180 get
-   picked without anyone reading its file/line citations first. `body` and `comments` are
-   required output fields, not optional — the next sub-steps depend on them.
-
-3. **Also fetch `reactionGroups`** (👍/👎 counts) — a real, if imperfect, community-signal
-   input for `issue-address:select:rank-impact` later, beyond just label text.
-
-## Output
-
-The full, verified-complete list of open issues with bodies, labels, assignees, comments,
-and reaction counts — handed to `issue-address:select:reject-fixed` next.

package/plugins/session-manager-dev/skills/issue-address/0-select/1-reject-fixed/SKILL.md

@@ -1,64 +0,0 @@
----
-name: issue-address:select:reject-fixed
-description: Reject candidates from issue-address:select:fetch-pool's pool that are already fixed in current code, by checking the actual file/behavior each issue cites against a freshly-fetched origin/main — semantically, not just a literal string grep. Second sub-step of issue-address:select.
----
-
-# issue-address:select:reject-fixed
-
-The check that would have caught issue #180 before any other work started — its body
-cited `apps/web/app/app.css` around specific line numbers, and the current code already
-had the exact fix (`min-width: 0`) the issue was reporting the absence of.
-
-## Steps
-
-0. **Fetch fresh before checking anything.** `git fetch origin main` first, and read
-   against `origin/main`, not a local branch — a local checkout can be stale or on an
-   unrelated feature branch, and a stale read produces a false "still broken" verdict.
-   (Found live: `#194` looked unfixed against a stale local branch, but `origin/main` had
-   merged the fix days earlier.)
-
-1. **For each candidate whose body cites a specific file, line, function, or CSS
-   selector/rule**, read the actual current code at that location:
-   ```bash
-   git show origin/main:<cited-path> | sed -n '<start>,<end>p'
-   ```
-   or grep for the cited selector/function name if line numbers have drifted (files get
-   reorganized — issue #180's citation was for `apps/web/app/app.css`, which had since
-   been split into `apps/web/app/styles/*.css`; searching by class/function name across
-   the styles directory found the real current location).
-
-2. **Check the behavior semantically, not just for the literal string the issue used.** A
-   fix can land in a different code *shape* than the issue's own words. (Found live: `#57`
-   asked for a `<link rel="canonical">` tag; a literal grep for `rel="canonical"` found
-   nothing, so the naive check would have called it unfixed — but the actual fix was a
-   data-driven React Router `meta()` descriptor, `{ tagName: 'link', rel: 'canonical', href
-   }`, which produces the same tag at render time without ever containing that literal
-   string in source.) Before concluding "not fixed" on a bare grep miss:
-   - Search one level broader — the surrounding directory/module, a shared
-     helper/util file, a `meta.ts`/`config.ts`-style indirection layer — for the *behavior*
-     the issue describes, not just its exact wording.
-   - If the issue names a concrete symptom (a missing tag, a wrong computed value, a
-     missing gate), look for whatever code *produces* that output, however it's
-     structured, before deciding the symptom is still present.
-
-3. **Compare what the issue describes as broken against what the code currently does.**
-   If the issue's own hypothesized fix (or an equivalent one, per step 2) is already
-   present — reject, log as `already-fixed`, cite the exact current file:line as evidence.
-   Don't spend a full `issue-address:reproduce` pass confirming what a direct code read
-   already answered.
-
-4. **If the citation is vague, or the file has moved/renamed and a reasonably broadened
-   search (step 2) still finds nothing**, don't reject on inconclusive evidence — mark the
-   candidate `unconfirmed` and let it pass through to the next sub-step. This step only
-   rejects on positive evidence of an existing fix, never on failure-to-locate.
-
-5. **If the git history around that file shows the fix landed suspiciously close to the
-   issue's `createdAt`** (within a day or two, either direction), note that explicitly —
-   it's a strong signal the report and the fix crossed in flight (exactly what happened
-   with #180: fix committed 2026-06-29, issue filed 2026-06-30).
-
-## Output
-
-Two lists: `already-fixed` (rejected, with evidence) and `survives` (candidates to pass to
-`issue-address:select:reject-claimed` next, tagged `unconfirmed` where this step couldn't
-conclusively check).