claude-code-session-manager 0.38.3 → 0.38.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (10) hide show
  1. package/dist/assets/{TiptapBody-R9igz9Iz.js → TiptapBody-D1ufJtTb.js} +1 -1
  2. package/dist/assets/index-CZrfXQpq.css +32 -0
  3. package/dist/assets/index-DwjviHVo.js +3501 -0
  4. package/dist/index.html +2 -2
  5. package/package.json +1 -1
  6. package/plugins/session-manager-dev/skills/blog-for-project-feature/SKILL.md +6 -2
  7. package/plugins/session-manager-dev/skills/blog-for-project-feature/feature.config.yaml +12 -5
  8. package/plugins/session-manager-dev/skills/develop/SKILL.md +96 -28
  9. package/dist/assets/index-BJRUaZ96.js +0 -3504
  10. package/dist/assets/index-DyOGjslF.css +0 -32
package/dist/index.html CHANGED
@@ -7,10 +7,10 @@
7
7
  <link rel="preconnect" href="https://fonts.googleapis.com">
8
8
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
9
9
  <link href="https://fonts.googleapis.com/css2?family=Newsreader:ital,opsz,wght@0,6..72,400;0,6..72,500;0,6..72,600;0,6..72,700;1,6..72,400&family=Geist:wght@300;400;500;600;700&family=IBM+Plex+Mono:wght@400;500;600&display=swap" rel="stylesheet">
10
- <script type="module" crossorigin src="./assets/index-BJRUaZ96.js"></script>
10
+ <script type="module" crossorigin src="./assets/index-DwjviHVo.js"></script>
11
11
  <link rel="modulepreload" crossorigin href="./assets/monaco-editor-BW5C4Iv1.js">
12
12
  <link rel="stylesheet" crossorigin href="./assets/monaco-editor-BTnBOi8r.css">
13
- <link rel="stylesheet" crossorigin href="./assets/index-DyOGjslF.css">
13
+ <link rel="stylesheet" crossorigin href="./assets/index-CZrfXQpq.css">
14
14
  </head>
15
15
  <body class="bg-bg text-fg font-sans antialiased">
16
16
  <div id="root"></div>
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "claude-code-session-manager",
3
- "version": "0.38.3",
3
+ "version": "0.38.5",
4
4
  "description": "Local cockpit for the Claude Code CLI — multi-tab terminal, full config surface, scheduler, voice dictation, and live observability.",
5
5
  "type": "module",
6
6
  "main": "src/main/index.cjs",
package/plugins/session-manager-dev/skills/blog-for-project-feature/SKILL.md CHANGED
@@ -93,8 +93,12 @@ step is dropped and reported, not faked.** A shorter, honest demo beats a comple
93
93
  ## Output
94
94
 
95
95
  Default: one self-contained `.html` file (inline CSS/JS, base64-embedded images) written to
96
- `docs/feature-showcase/<feature-slug>.html` inside the target project — see
97
- `feature.config.yaml` for the exact path convention, size ceiling, and the single-file vs.
96
+ `docs/feature-showcase/<project-slug>-<feature-slug>.html` inside **`~/Projects/Bilko`** —
97
+ never inside the showcased project's own repo, even when the feature being showcased belongs
98
+ to a different project entirely. Bilko is the author/publisher of every showcase (same as
99
+ `blog-from-git`'s posts), is guaranteed to be locally writable across sessions, and these pages
100
+ are destined to eventually post to bilko.run — so output collects in one place from the start.
101
+ See `feature.config.yaml` for the exact path convention, size ceiling, and the single-file vs.
98
102
  folder fallback (used when embedded images would blow past the size ceiling). This is what
99
103
  "uploadable anywhere" means: no server, no relative asset paths, no build step — open the file
100
104
  or drop it on any static host and it works.
package/plugins/session-manager-dev/skills/blog-for-project-feature/feature.config.yaml CHANGED
@@ -2,16 +2,23 @@
2
2
  # If prose in a SKILL.md ever disagrees with this file, this file wins.
3
3
 
4
4
  output:
5
- # Path is relative to the TARGET project's repo root (the project being showcased),
6
- # not this plugin's own repo.
7
- path_template: "docs/feature-showcase/{feature-slug}.html"
5
+ # Path is relative to ~/Projects/Bilko (the Bilko repo) — ALWAYS, regardless of which
6
+ # project the showcased feature lives in. Bilko is the author/publisher of every showcase
7
+ # (same reason blog-from-git's posts live in Bilko, not in the project they're about) and
8
+ # these pages are destined to eventually be posted on bilko.run — Bilko is the one repo
9
+ # guaranteed to be locally writable across every session this skill runs in, and keeping
10
+ # output there means all showcases accumulate in one place instead of scattering across
11
+ # sibling repos. Never write the HTML into the target project's own repo.
12
+ base_repo: "~/Projects/Bilko"
13
+ path_template: "docs/feature-showcase/{project-slug}-{feature-slug}.html"
14
+ project_slug_rule: "kebab-case, the showcased project's own repo/registry slug (e.g. session-manager, signal-builder) — always prefixed so multi-project output never collides"
8
15
  feature_slug_rule: "kebab-case, derived from the confirmed feature name in :select"
9
16
  # Prefer one self-contained file. Only fall back to a folder when the size ceiling
10
17
  # below would be exceeded by inlining images.
11
18
  default_mode: single_file # single_file | folder
12
19
  folder_fallback_layout:
13
- html: "docs/feature-showcase/{feature-slug}/index.html"
14
- images: "docs/feature-showcase/{feature-slug}/screenshots/"
20
+ html: "docs/feature-showcase/{project-slug}-{feature-slug}/index.html"
21
+ images: "docs/feature-showcase/{project-slug}-{feature-slug}/screenshots/"
15
22
  single_file_size_ceiling_mb: 8 # switch to folder_fallback_layout above this
16
23
  never_upload_or_deploy_without_explicit_ask: true
17
24
 
package/plugins/session-manager-dev/skills/develop/SKILL.md CHANGED
@@ -1,15 +1,18 @@
1
1
  ---
2
2
  name: develop
3
3
  description: >-
4
- Lead a software-development task by decomposing a feature/refactor/bugfix prompt into a
5
- series of self-contained PRDs queued for the session-manager scheduler, each pointing the
6
- headless executor at the engineering standards file to read at runtime — then track those
7
- PRDs to completion, verify them against their acceptance criteria, and report back. Use whenever
8
- the user says "/develop", "develop X", "build me X", "implement X", "let's code X", or
9
- otherwise starts dev work that should run as scheduled PRDs rather than inline now. This
10
- skill is the home for the developer-only guidance (performance, debugging, API-reuse, TDD)
11
- that was removed from the always-on global CLAUDE.md. Keywords: develop, build, implement,
12
- code, feature, refactor, bugfix, queue dev work, PRDs.
4
+ Lead a software-development task by analyzing it from multiple angles (positive path, edge
5
+ cases, interaction effects, integration, UI validation) and decomposing it into a series of
6
+ self-contained PRDs — either a handful of independent small PRDs, or a 3-5 PRD evolving chain
7
+ with sub-tasked acceptance criteria for larger asks — queued for the session-manager
8
+ scheduler, each pointing the headless executor at the engineering standards file to read at
9
+ runtime — then track those PRDs to completion, verify them against their acceptance criteria,
10
+ and report back. Use whenever the user says "/develop", "develop X", "build me X", "implement
11
+ X", "let's code X", or otherwise starts dev work that should run as scheduled PRDs rather than
12
+ inline now. This skill is the home for the developer-only guidance (performance, debugging,
13
+ API-reuse, TDD) that was removed from the always-on global CLAUDE.md. Keywords: develop,
14
+ build, implement, code, feature, refactor, bugfix, queue dev work, PRDs, PRD chain, multi-angle
15
+ analysis.
13
16
  ---
14
17
 
15
18
  # /develop — prompt → scheduled PRDs → tracked to done
@@ -77,30 +80,60 @@ can't load skills.
77
80
  this subsystem (`ls ~/.claude/session-manager/scheduled-plans/prds/` for related slugs) —
78
81
  duplicating or contradicting a still-queued PRD is a real failure mode, not a hypothetical one.
79
82
 
80
- 3. **Draft a candidate decomposition, then run a completeness pass before finalizing it.** This
81
- step exists because small, bounded individual PRDs (step 4) are correct and non-negotiable —
82
- but a *set* of small PRDs can still be incomplete if the upfront decomposition missed
83
- something. Keeping PRDs small is not a substitute for getting the decomposition right; it's a
84
- separate concern, and this step is where decomposition quality gets checked.
85
- - For a **genuinely trivial ask** (one obvious PRD, no cross-file consequences) — skip
86
- straight to step 4, no ceremony needed.
83
+ 3. **Analyze the request through five named lenses, draft a candidate decomposition, then run
84
+ a completeness pass before finalizing it.** This step exists because small, bounded individual
85
+ PRDs (step 4) are correct and non-negotiable — but a *set* of small PRDs can still be
86
+ incomplete if the upfront decomposition missed something. Keeping PRDs small is not a
87
+ substitute for getting the decomposition right; it's a separate concern, and this step is
88
+ where decomposition depth and breadth get checked.
89
+
90
+ **The five lenses.** Before drafting the PRD list, look at the request through each of these
91
+ explicitly — not as a vague "think it through" gesture, but as five concrete questions you can
92
+ answer in a sentence each. Skipping a lens silently is how a decomposition ships narrow:
93
+ - **Positive path.** What does the request look like when everything goes right? Name the
94
+ concrete user-visible or system-visible outcome — this anchors the core PRD(s).
95
+ - **Edge cases.** What inputs/states break the happy-path assumption? Empty/zero/max states,
96
+ concurrent access, malformed input, permission boundaries, network/process failure.
97
+ - **Interaction effects.** Does this change anything that another feature, panel, store, or
98
+ in-flight state already depends on? A layout change can break a responsive breakpoint; a
99
+ new field can desync two stores that used to agree; a UI merge can silently drop a
100
+ conditional-render gate another feature relied on. Naming this explicitly is what catches
101
+ the "it works in isolation but breaks its neighbor" class of bug.
102
+ - **Integration.** Does this correctly compose with the existing architecture at its
103
+ boundaries — the IPC schema, the shared store, an existing API contract, an established
104
+ design-primitive file — rather than reimplementing a parallel path? This is the API-reuse
105
+ standard (`standards.md`) applied at the planning stage, before code exists to duplicate.
106
+ - **Validation (UI/visual, planned up front — not just checked at the end).** For any ask
107
+ that touches UI or visual output, decide *now*, while drafting, exactly how it will be
108
+ confirmed working before it's called done: what screenshot/state to capture, light AND dark
109
+ mode if the project has both, and which specific acceptance line will prove it (not "looks
110
+ right" — a concrete, checkable claim). Bake that plan into the PRD's own Acceptance
111
+ Criteria (see step 4's sub-tasked AC) rather than leaving visual confirmation as an
112
+ afterthought bolted on at the step 8 gate — deciding the validation method during design
113
+ surfaces gaps (e.g. "there's no existing screenshot tooling for this surface") while there's
114
+ still time to plan around them, instead of discovering it mid-execution.
115
+
116
+ - For a **genuinely trivial ask** (one obvious PRD, no cross-file consequences, all five
117
+ lenses come back empty) — skip straight to step 4, no ceremony needed.
87
118
  - For anything **larger than one or two obvious PRDs, or touching more than one
88
119
  component/subsystem** — before finalizing, dispatch a second, independent agent (the Agent
89
120
  tool, `subagent_type: "Explore"` or `"general-purpose"` — this is a single extra dispatch,
90
121
  not the full multi-agent Workflow tool, and needs no special opt-in) with: the original ask
91
- verbatim, your draft PRD list (titles + one-line goals), and the instruction to find what's
92
- missing — uncovered edge cases, error-handling paths, tests, cross-file consequences,
93
- components that share the same pattern but weren't included, anything the draft assumed
94
- without verifying. Treat its findings as a second opinion to weigh, not an automatic
95
- addition — fold real, concrete gaps into the PRD set (add, split, or adjust a PRD); dismiss
96
- vague or speculative ones. For a large, multi-subsystem ask, it's fine to repeat this once
97
- more after folding in the first round's findings (a second completeness pass on the revised
98
- set) — stop once a pass turns up nothing new, don't loop indefinitely.
122
+ verbatim, your draft PRD list (titles + one-line goals), and the five lenses above by name,
123
+ instructing it to find what's missing under each one — uncovered edge cases, error-handling
124
+ paths, tests, cross-feature/cross-state interaction effects, integration points that would
125
+ be reimplemented instead of reused, components that share the same pattern but weren't
126
+ included, anything the draft assumed without verifying. Treat its findings as a second
127
+ opinion to weigh, not an automatic addition — fold real, concrete gaps into the PRD set (add,
128
+ split, or adjust a PRD); dismiss vague or speculative ones. For a large, multi-subsystem ask,
129
+ it's fine to repeat this once more after folding in the first round's findings (a second
130
+ completeness pass on the revised set) — stop once a pass turns up nothing new, don't loop
131
+ indefinitely.
99
132
  - **Check each drafted PRD against explicit concern dimensions, not just "does the feature
100
- work"**: missing features/edge cases beyond the happy path, tests, security, and quality
101
- (perf, error handling). This is where depth actually comes from — a decomposition that only
102
- ever asks "what file does this touch" produces exactly the narrow, single-concern PRDs this
103
- step exists to catch.
133
+ work"**: missing features/edge cases beyond the happy path, interaction effects, integration,
134
+ tests, security, and quality (perf, error handling). This is where depth actually comes
135
+ from — a decomposition that only ever asks "what file does this touch" produces exactly the
136
+ narrow, single-concern PRDs this step exists to catch.
104
137
  - **Tests and security are NOT separate follow-up PRDs — they are mandatory AC lines inside
105
138
  the SAME PRD as the feature they belong to.** This is non-negotiable: `standards.md`'s TDD
106
139
  rule requires the test before/with the implementation, not after, and a security concern
@@ -120,6 +153,32 @@ can't load skills.
120
153
  4. **Decompose into a series of SMALL, bounded PRDs.** Split the (now completeness-checked)
121
154
  decomposition into individually small PRDs and sequence them.
122
155
 
156
+ **Two shapes — pick per request, don't default to one:**
157
+ - **Independent set.** Most requests: a handful of small PRDs that can mostly run in
158
+ parallel, each a self-contained unit (this is what "genuinely separable work" in step 3
159
+ produces).
160
+ - **Evolving chain (3-5 PRDs).** Use this shape when the request is naturally a sequence of
161
+ stages that build on each other rather than independent units — e.g. scaffold → core
162
+ behavior → edge-case/interaction hardening → integration wiring → UI validation pass. Each
163
+ PRD in the chain: gets the **next sequential `NN`** (never the same `NN` as the PRD it
164
+ depends on — same-`NN` means "can run in parallel," which a chain link cannot), and its
165
+ `# Implementation notes` states in one line what the *previous* link actually delivered
166
+ (file paths/functions it added, referencing its real landed state — not the plan for it,
167
+ since PRDs 1..k-1 may have adjusted scope during execution) and what this link is expected
168
+ to build on top of. Do not chain more than 5 deep — beyond that, re-run step 3's
169
+ completeness pass instead of extending the chain further; a chain that long is a sign the
170
+ original decomposition was wrong, not that it needs one more link. A chain does not relax
171
+ the ~15-min/30-min-ceiling sizing below — each link is still individually small.
172
+ - **Sub-tasked Acceptance Criteria** (either shape, when a single PRD legitimately spans more
173
+ than one concern dimension from step 3 — e.g. it has both core-functionality and
174
+ edge-case/interaction-effect checks): group the `# Acceptance criteria` checklist under
175
+ sub-headings instead of one flat list, e.g. `## Core functionality`, `## Edge cases`,
176
+ `## Interaction / integration`, `## Tests`. This is additive structure only — it does not
177
+ change what step 4's "Required body sections" template requires (still exactly one
178
+ `# Acceptance criteria` section overall), and it does not license combining what should be
179
+ separate PRDs into one oversized one; if the sub-task groups would each take real time on
180
+ their own, that's a signal to split into a chain link instead of one bloated PRD.
181
+
123
182
  **Prefer creating each PRD via the `scheduler_create_prd` MCP tool**
124
183
  (`mcp__session-manager-scheduler__scheduler_create_prd`) over hand-writing the file. Its input
125
184
  (`title`, `cwd`, `estimateMinutes`, `goal`, `acceptanceCriteria[]`, `implementationNotes`,
@@ -211,6 +270,11 @@ can't load skills.
211
270
 
212
271
  <short bulleted list of what NOT to build, to prevent scope creep>
213
272
  ```
273
+ (When a PRD spans multiple step-3 concern dimensions, replace the flat `# Acceptance criteria`
274
+ list above with sub-headings — `## Core functionality`, `## Edge cases`,
275
+ `## Interaction / integration`, `## Tests` — each still a checklist of verifiable lines. See
276
+ step 4's "Sub-tasked Acceptance Criteria" note. This is the only body section that may gain
277
+ sub-headings; Goal, Implementation notes, and Out of scope stay flat.)
214
278
 
215
279
  **Self-containment is load-bearing.** The executor (`claude -p`) starts with NO conversation
216
280
  context — only the PRD body and the project files. So: include exact file paths (e.g.
@@ -318,3 +382,7 @@ single definition of "tracked to done" for both entry paths.
318
382
  - Don't write a PRD to `data/prds/`, `docs/prds/`, the project's own folder, or anywhere outside
319
383
  the canonical path. The user has explicitly flagged this as a recurring problem.
320
384
  - Don't leave `cwd` unset hoping for the default. Be explicit.
385
+ - Don't skip a step-3 lens silently and don't force every request into a chain — most asks are
386
+ still an independent set of small PRDs; reach for the 3-5-PRD evolving chain only when the
387
+ work is genuinely sequential (each link depends on the previous one's landed state), and never
388
+ chain past 5 links.