claude-code-session-manager 0.110.0 → 0.112.0

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

@@ -1,71 +0,0 @@
----
-name: issue-address:select:reject-claimed
-description: Reject candidates already covered by a PR (open, OR closed-but-superseded-by-a-merged-successor) or already claimed by an assignee/comment/supersede-note — with every text-search hit manually confirmed before being trusted. Third sub-step of issue-address:select.
----
-
-# issue-address:select:reject-claimed
-
-## Steps
-
-1. **Search for a PR that might already cover each surviving candidate — open AND
-   closed, not just open:**
-   ```bash
-   gh pr list --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --state all --search "<N> in:body"
-   gh api search/issues -f q='repo:$(gh repo view --json nameWithOwner -q .nameWithOwner) is:pr <N>'
-   ```
-   Also skim PR titles for matching subject matter (same file area, same symptom) — a PR
-   can fix an issue's bug without a formal `Closes #N` link. Searching only `state:open`
-   misses the real case found live: `#194` had two closed (not merged) PRs, `#203`/`#215`,
-   each superseded — but the actual fix landed in a *third*, later PR (`#251`) that neither
-   text-search-by-issue-number pass would find unless the closed ones are read first and
-   followed to what replaced them (step 3).
-
-2. **Never trust a text-search hit without reading it.** This already produced a false
-   positive once: searching `"180 in:body"` matched PR #239 ("add automated price-anomaly
-   screen"), which had nothing to do with issue #180 — the digit string almost certainly
-   matched a line number or unrelated number elsewhere in that PR's body. For every
-   text-search hit:
-   - Open the matched PR's actual title + description.
-   - Confirm it genuinely addresses the same file area / same symptom the issue describes
-     — not just that the issue number appears somewhere in the text.
-   - If it's a false positive (number coincidence, unrelated context), **discard the match
-     and keep the candidate as unclaimed** — don't reject on a search artifact.
-
-3. **For every closed-but-not-merged PR found in step 1, read its closing comment before
-   deciding the candidate survives.** A PR closed without merging is not automatically
-   "unclaimed again" — read why it closed:
-   ```bash
-   gh pr view <PR#> --repo "$(gh repo view --json nameWithOwner -q .nameWithOwner)" --json state,mergedAt,closedAt,comments
-   ```
-   - If the closing comment says the work was split/replaced ("затварям... но не защото
-     работата е отпаднала", "closing in favor of #N", "superseded by #N", "merged into
-     #N"), **follow the chain to whatever PR(s) it names**, and check *their* merge state
-     the same way. Keep following until you reach a terminal state (merged = reject as
-     already-fixed; still open = reject as already-covered; abandoned with no successor =
-     candidate survives).
-   - This chain can be more than one hop deep (found live: `#194`'s PR `#203` was split
-     into `#251`/`#252`/`#253`; a sibling PR `#215` was independently closed in favor of
-     the same `#251`) — don't stop at the first successor if its own comments point
-     further.
-
-4. **Reject candidates already claimed by a person, or already noted as superseded in the
-   issue's OWN comments** (not just a linked PR's). Check `assignees` (non-empty =
-   explicit claim) and skim the issue's `comments` for:
-   - Claim language: "работя по това", "assigned to me", "I'll pick this up".
-   - Supersede/decompose language: "предлагам да се затвори в полза на", "closing in
-     favor of", "split into #N / #M / #P", "superseded by". (Found live: `#154`'s own
-     comment thread explicitly proposed closing it in favor of child issues `#156`/`#158`/
-     `#163` — a signal that lives in the issue's comments, not in any PR search at all.)
-   Reject on either signal — don't take work someone else already started or already
-   restructured, even informally.
-
-5. **Search for a duplicate open issue** describing the same underlying bug under a
-   different number — `gh issue list --state open --search "<keywords>"`, same
-   confirm-before-trusting rule as step 2 applies here too. If a better-established
-   duplicate exists, flag it rather than silently picking one.
-
-## Output
-
-`survives` list (candidates cleared of PR/claim/supersede/duplicate overlap — including
-resolved multi-hop PR chains — with any false-positive search hits explicitly noted as
-discarded) handed to `issue-address:select:rank-impact`.

package/plugins/session-manager-dev/skills/issue-address/0-select/3-rank-impact/SKILL.md

@@ -1,39 +0,0 @@
----
-name: issue-address:select:rank-impact
-description: Rank surviving candidates by a composite impact signal (priority label + community reactions + cross-references + repro quality), not label text alone, and output exactly one issue number. Final sub-step of issue-address:select.
----
-
-# issue-address:select:rank-impact
-
-## Steps
-
-1. **Score each surviving candidate on multiple signals, not just its `priority:` label**
-   (a label-only heuristic silently mis-ranks an unlabeled-but-severe issue below a
-   labeled-but-minor one):
-   - **Priority label**: `high` > `medium` > `low` > none (weakest single signal alone).
-   - **Category label**: `bug`/`security`/`data-quality` outrank `enhancement`/
-     `discussion`/`docs` for this skill's purpose (fixing something broken, not building
-     something new).
-   - **Community reaction count** (from `fetch-pool`'s `reactionGroups`) — more 👍 reactions
-     is a real signal of user-felt impact independent of whatever label was applied at
-     triage time.
-   - **Cross-references** — check `gh issue view <N> --json timelineItems` (or equivalent)
-     for how many other issues/PRs reference this one; a heavily-cross-referenced issue is
-     blocking or informing other work, raising its effective priority above its label.
-   - **Repro quality** — concrete repro steps / cited file-line locations beat a vague
-     report; cheaper to reproduce reliably, lower risk of another #180-style dead end.
-
-2. **Combine into a ranked order** — no single signal should override all others (e.g.
-   don't let one 👍 reaction alone outrank an explicit `priority: high` label; use
-   priority + category as the primary sort, reaction count + cross-references as
-   tie-breakers within a tier, repro quality as the final tie-breaker).
-
-3. **Output exactly one issue number** — the top of the ranked list — with a one-line
-   justification citing which signals won, plus the full ranked list (not just the
-   winner) and the rejected list from the earlier two sub-steps, so the whole selection
-   is auditable, not just its conclusion.
-
-## Output
-
-Hand off the single selected issue number to `issue-address:confirm-open`, which
-re-verifies it fresh (state, PR/duplicate claims) immediately before work starts.

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

@@ -1,75 +0,0 @@
----
-name: issue-address:select
-description: Step 0 of issue-address — select exactly ONE open issue on the current project's repo to work, by orchestrating 4 nested sub-skills (fetch-pool, reject-fixed, reject-claimed, rank-impact) in sequence. Only invoked when the caller hasn't already named a specific issue number.
----
-
-# issue-address:select (sub-orchestrator)
-
-Only runs when `issue-address` is invoked without a specific issue number already named
-(if the caller already has one, skip straight to `issue-address:confirm-open` — that step
-re-verifies the single chosen issue right before work starts, as a freshness guard; this
-skill's job is choosing which issue out of many, cheaply and verifiably, across the whole
-pool).
-
-Exists because of a real incident: issue #180 was picked by title/label alone, and 2 full
-`issue-address` steps ran before discovering — only once `issue-address:reproduce`
-actually tried to reproduce it — that the fix had already shipped a day before the issue
-was even filed. The information needed to catch that (the issue's own cited file/line + a
-grep of current code) was available for free at selection time and simply wasn't checked.
-
-This skill is itself further decomposed into 4 nested sub-skills, for the same reason
-`issue-address` is decomposed: so each check is independently invokable and its result
-inspectable, instead of one opaque scan-and-pick pass. It also closes two gaps found after
-the first version shipped: an unverified fetch limit (the same class of silent-truncation
-bug that hit `pr-review-sweep`), and an unconfirmed PR-search false positive (seen live in
-the #180 trial — a text search on "180" matched an unrelated PR by number coincidence).
-
-**Naming convention:** sub-directories are prefixed `0-`, `1-`, `2-`, `3-` in execution
-order (see `issue-address/SKILL.md` for the repo-wide rule) — a plain directory listing of
-this folder sorts in DAG order without opening any file.
-
-## Pipeline DAG
-
-```
-open-issue pool
-      │
-      ▼
-┌─────────────────────────────┐
-│ 0. select:fetch-pool         │  verified-complete fetch (no silent truncation)
-└─────────────────────────────┘
-      │ full pool w/ bodies, labels, assignees, comments, reactions
-      ▼
-┌─────────────────────────────┐
-│ 1. select:reject-fixed       │  grep current code at each cited file/line
-└─────────────────────────────┘
-      │ survives (already-fixed candidates dropped, evidence logged)
-      ▼
-┌─────────────────────────────┐
-│ 2. select:reject-claimed     │  PR-search hits confirmed, not trusted blind
-└─────────────────────────────┘
-      │ survives (PR'd/claimed/duplicate candidates dropped, evidence logged)
-      ▼
-┌─────────────────────────────┐
-│ 3. select:rank-impact        │  composite score, not label text alone
-└─────────────────────────────┘
-      │
-      ▼
-one issue number + full audit trail (ranked list, rejected list, why)
-      │
-      ▼
-issue-address:confirm-open  (next skill up the chain, outside this sub-orchestrator)
-```
-
-| Step | Input | Output | On failure/empty |
-|---|---|---|---|
-| 0. `select:fetch-pool` | none (repo-wide `gh issue list`) | full open-issue pool, verified-complete | n/a — loops its own fetch until verified complete |
-| 1. `select:reject-fixed` | full pool | `already-fixed` list (w/ evidence) + `survives` list | if pool empties out here, report "no candidates, all already fixed" |
-| 2. `select:reject-claimed` | `survives` from step 1 | `already-claimed` list (w/ evidence) + `survives` list | if pool empties out here, report "no candidates, all claimed/PR'd" |
-| 3. `select:rank-impact` | `survives` from step 2 | one issue number + ranked list + justification | if `survives` was already empty, report the empty pool rather than fabricating a pick |
-
-## Output
-
-Hand off the single selected issue number to `issue-address:confirm-open`, which
-re-verifies it fresh (state, PR/duplicate claims) immediately before work starts — this
-skill's checks are about narrowing a big pool cheaply and verifiably; confirm-open's
-checks are about not acting on stale information for the one issue actually chosen.

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

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

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

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

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

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

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

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

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

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

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

@@ -1,120 +0,0 @@
----
-name: issue-address
-description: Take ONE GitHub issue on the current project's repo from selection (or a named issue number) to a verified, reviewed fix — orchestrates 6 nested sub-skills (issue-address:select, :confirm-open, :claim, :reproduce, :fix, :verify) plus the existing requesting-code-review skill, so each step is independently invokable and monitorable. Use when the user wants a real issue picked and actually resolved, not just triaged.
----
-
-# issue-address (orchestrator)
-
-Global, project-agnostic issue-to-fix pipeline — works against whatever repo the current
-project's `gh` remote points to. Fires exactly one issue through a fixed sequence of nested
-skills — each a real, independently-invokable `SKILL.md`, not just a section header, so the
-sequence's progress can be watched step by step instead of as one opaque pass. Codified from
-`midt-bg/sigma`'s workflow; a project's own `AGENTS.md`/`CLAUDE.local.md` may add repo-specific
-conventions (branch naming, claim-comment language, commit style) that this skill should read
-and respect if present.
-
-**Naming convention (see a project's own `AGENTS.md` if it documents one; otherwise this
-convention still applies as the plugin's own standard):** sub-skill directories are prefixed
-`0-`, `1-`, `2-`... in execution order, so a plain directory listing sorts in DAG order
-without needing to open any file. Never rely on prose order alone — a reader (or an
-alphabetically-sorted file browser) should see the sequence from the folder names
-themselves. The invocable `name:` field stays a clean colon-scoped identifier
-(`issue-address:select`) without the numeric prefix — the prefix is a filesystem/ordering
-aid, not part of the skill's name.
-
-## Pipeline DAG
-
-```
-                    ┌─────────────────────┐
-  no issue #  ──────▶ 0. issue-address:select │──▶ issue number
-                    └─────────────────────┘         │
-  issue # given ─────────────────────────────────────┘
-                                                      ▼
-                                        ┌───────────────────────────┐
-                                        │ 1. issue-address:confirm-open │
-                                        └───────────────────────────┘
-                                     GO │                    │ NO-GO
-                                        ▼                    ▼
-                          ┌─────────────────────┐    STOP — report why
-                          │ 2. issue-address:claim   │
-                          └─────────────────────┘
-                    claimed │              │ claim failed to land
-                             ▼              ▼
-                  ┌─────────────────────┐    STOP — report (don't proceed
-                  │ 3. issue-address:reproduce│    unclaimed)
-                  └─────────────────────┘
-                    reproduces │              │ doesn't reproduce
-                                ▼              ▼
-                  ┌─────────────────┐   STOP — report (valid outcome,
-                  │ 4. issue-address:fix │    not a failure)
-                  └─────────────────┘
-                                │
-                                ▼
-                  ┌────────────────────┐
-                  │ 5. issue-address:verify│──── red ────┐
-                  └────────────────────┘                 │
-                                │ green                   │
-                                ▼                          │
-                  ┌────────────────────┐                  │
-                  │ 6. requesting-code-review│             │
-                  └────────────────────┘                  │
-                                │                          │
-                                ▼                          ▼
-                       land per conventions      loop back to step 4
-```
-
-| Step | Input | Output | On failure |
-|---|---|---|---|
-| 0. `issue-address:select` | open-issue pool (implicit — repo-wide) | one issue number + justification | n/a (always produces one, or explicitly reports the pool is empty) |
-| 1. `issue-address:confirm-open` | one issue number | GO (+ title/body/repro steps) or NO-GO (+ reason) | **STOP** — do not proceed |
-| 2. `issue-address:claim` | one confirmed-open issue number | self-assignment + claim comment, re-confirmed as landed | **STOP** — report if the claim didn't actually post; don't proceed unclaimed |
-| 3. `issue-address:reproduce` | issue title/body/repro steps | failing test (file:line) + root-cause hypothesis + red-phase output | **STOP** — report "does not reproduce" (valid, not a failure) |
-| 4. `issue-address:fix` | failing test + root-cause hypothesis | diff + the one test now green | loops internally until its one test is green |
-| 5. `issue-address:verify` | diff + green reproduction test | full-suite pass counts + typecheck result | **loop back to step 4** — do not proceed to review on red |
-| 6. `requesting-code-review` | the verified diff | Critical/Important findings addressed | fix findings, do not mark resolved until clean |
-
-Called either with **no issue number** (enters at step 0) or with **one specific issue
-number already named** (enters at step 1, skipping step 0 entirely).
-
-**Why claim is its own step, not folded into confirm-open:** confirming an issue is
-open/unclaimed and actually claiming it are two different moments in time — a gap where a
-second concurrent run (or a human) could pick the same issue between the two. `select`'s
-`reject-claimed` check only catches claims that already exist (an assignee, a "working on
-this" comment); nothing marks the issue claimed *for this run* until `claim` actually
-posts one. No dedicated GitHub/issue-tracking MCP server is connected in this environment
-— `claim` uses the `gh` CLI directly (self-assign + comment), same as every other GitHub
-interaction in this skill chain.
-
-## After the sequence completes clean
-
-- Commit with a conventional-commit message (`fix(scope): subject`, no trailing period, no
-  `Co-Authored-By` trailer unless the project's own convention says otherwise), on a branch
-  following the project's own `<type>/<slug>` convention if it documents one.
-- **Only push / open a PR when explicitly asked** — per the project's own `AGENTS.md` PR
-  section if it has one, don't do it unprompted. Report the sequence as complete and ready,
-  and wait.
-- If a PR does get opened (once asked), post a short comment on the originating issue
-  linking it — closes the loop from report to fix.
-- Never contact a reviewer (no request/re-request/nudge) without the user's fresh,
-  explicit, per-instance approval — same hard constant as everywhere else in this workflow.
-
-## Why nested skills instead of one inline sequence
-
-Each step is its own file so it shows up as its own invocation in whatever surface tracks
-skill/tool calls — you can see "select ran, chose #N over 4 rejected candidates" and
-"confirm-open ran, returned GO" as distinct, inspectable events before "reproduce" even
-starts, rather than one long undifferentiated pass. If a step needs to change (e.g. the
-verify step's test-runner command, or select's ranking weights), it's a one-file edit that
-doesn't touch the others. When a step needs more depth or clarity, decompose it further
-the same way `issue-address:select` was (see `0-select/SKILL.md` for its own nested DAG)
-— continuously, wherever a single file is doing too much to inspect as one unit.
-
-## What this skill is not
-
-- Not a pure triage/backlog tool — that's `find-opportunity` (ranks what to work on next
-  without opening/fixing anything, and never opens/fixes on its own). `issue-address:select`
-  overlaps with it in spirit (both rank by impact and check for claims) but exists
-  specifically to feed straight into actually fixing one issue in the same run, not just
-  to produce a shortlist for a human to review.
-- Not for PR review comments — that's a different data source entirely (see
-  `pr-review-sweep` for the unresolved-review-thread workflow on already-open PRs).

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

@@ -1,58 +0,0 @@
----
-name: local-project-health
-description: >-
-  Run the CURRENT project's own definition of "health" and report one rollup.
-  Each project defines health differently (a trading bot tracks circuit-breakers
-  + benchmark alpha; a web app tracks uptime + error rate), so this skill runs
-  the project-supplied health entrypoint rather than imposing a generic check.
-  Use whenever the user asks "is this project healthy?", "/local-project-health",
-  "system health", "is everything running / green", or wants a one-shot status
-  rollup for the repo they're in. Keywords: health, status, healthcheck, is it
-  up, are we green, rollup, system health, project health.
----
-
-# Local project health
-
-Report a single health verdict for the project in the current working directory
-by running **that project's own** health definition. Health is project-specific
-by design — do not invent generic checks.
-
-## Procedure
-
-1. **Find the project's health entrypoint**, checking these paths in order
-   (first hit wins):
-   - `scripts/health.sh`
-   - `.claude/health.sh`
-   - `bin/health.sh`
-   - `Makefile` / `justfile` target named `health`
-
-2. **If an entrypoint exists**, run it from the repo root and relay its output:
-   - `bash scripts/health.sh` (or the path found / `make health` / `just health`).
-   - These scripts are designed to print a human rollup and exit 0/1/2
-     (GREEN/YELLOW-or-UNKNOWN/RED). Show the user the rollup verbatim, then add a
-     one-line plain-English verdict leading with the overall color and the worst
-     layer (e.g. "🟡 YELLOW — performance is the drag: −3 pts vs SPY").
-   - If the script persists a structured artifact (e.g.
-     `data/system_health.json`), mention where it landed.
-   - If it exits non-zero, that is expected for YELLOW/RED — it is NOT a skill
-     failure. Only treat a *crash* (missing interpreter, traceback, unbound var)
-     as a failure to debug.
-
-3. **If NO entrypoint exists**, do not guess at health with ad-hoc commands.
-   Instead:
-   - Read `CLAUDE.md`, `README*`, and skim the repo to infer what "health" means
-     for THIS project (what it monitors, what would constitute degraded/broken).
-   - Propose a concrete `scripts/health.sh` that collapses those project-specific
-     layers into one GREEN/YELLOW/RED rollup (terminal output + a persisted
-     `*.json` artifact), reusing the project's existing CLIs/artifacts rather
-     than re-deriving thresholds.
-   - Offer to create it. Once created, it becomes the convention this skill runs
-     on every future invocation.
-
-## Notes
-
-- The contract is the **convention path**, not a shared implementation: every
-  project owns its own `scripts/health.sh`. This skill is just the launcher +
-  interpreter of the result.
-- Keep the relayed summary tight: overall color first, then the offending
-  layer(s), then where the full report is. Lead with the answer.