claude-code-session-manager 0.110.0 → 0.112.0

package/plugins/session-manager-dev/skills/blog-for-project-feature/0-select/SKILL.md

@@ -1,39 +0,0 @@
----
-name: blog-for-project-feature:select
-description: Step 0 of blog-for-project-feature — confirm exactly ONE project and ONE feature to showcase. Only asks the user when the feature genuinely can't be inferred; otherwise picks the most demo-worthy recently-shipped feature and states why.
----
-
-# blog-for-project-feature:select
-
-## Input
-- The project: current working directory's repo, or a project name/path explicitly given by
-  the caller.
-- Optional: a feature name or hint from the caller ("showcase the click-run screen", "the new
-  ticker-tracker queue").
-
-## Steps
-
-1. **Confirm the project.** Read its root `CLAUDE.md`/`README.md`/`AGENTS.md` (whichever
-   exists) to confirm you're pointed at a real, buildable/runnable project — not an empty or
-   scaffold-only repo.
-
-2. **If a feature was named**, confirm it exists: grep for it in code, routes, or docs. If it
-   doesn't resolve to anything real, say so and stop rather than guessing at a nearby feature.
-
-3. **If no feature was named**, pick one:
-   - Prefer something with a real UI surface (a screen, a flow, a page) — this skill's whole
-     value is a click-through demo, so a pure-backend/CLI-only feature is a weak fit unless the
-     project exposes it through a dashboard.
-   - Prefer recently shipped (`git log --oneline -20` on the relevant paths) over long-stable —
-     showcases are most useful for things a reader hasn't seen yet.
-   - Prefer one coherent flow over a grab-bag of unrelated changes — this produces ONE feature
-     page, not a changelog.
-
-4. **State the justification** in one or two sentences: what the feature is, why it's the right
-   one to demo right now.
-
-## Output
-
-Hand off to `:research`: confirmed project (path/repo), confirmed feature name, one-line
-justification. If no confirmable feature exists, **STOP** and report why instead of forcing a
-pick.

package/plugins/session-manager-dev/skills/blog-for-project-feature/1-research/SKILL.md

@@ -1,37 +0,0 @@
----
-name: blog-for-project-feature:research
-description: Step 1 of blog-for-project-feature — ground the project's mission/description and the confirmed feature's description in real docs and code, before any HTML gets written. Flags gaps explicitly instead of inventing claims.
----
-
-# blog-for-project-feature:research
-
-## Input
-Confirmed project + confirmed feature name + justification, from `:select`.
-
-## Steps
-
-1. **Project mission & description.** Pull from the project's own root docs (`README.md`,
-   `CLAUDE.md`'s "What this project is" section if it has one, `package.json`/`pyproject.toml`
-   description field as a fallback). 2-4 sentences, in the project's own words where possible —
-   don't invent a mission statement it doesn't already have.
-
-2. **Feature description.** Locate the actual entry point(s) — route, component, CLI command,
-   pipeline — and read enough of the real implementation to describe, in plain language:
-   - what it does (user-facing behavior, not implementation detail)
-   - why it matters (what it replaces, what it makes possible)
-   - any real constraint worth knowing (auth required, feature-flagged, still in beta) — surface
-     these rather than smoothing them over
-
-3. **Identify the demo surface.** Note exact URLs/routes, the commands needed to run the app
-   locally, any seed data / login required to reach the feature — `:storyboard` and `:capture`
-   need this to actually drive the app.
-
-4. **Flag gaps.** If the mission statement doesn't exist, or the feature's purpose isn't
-   evident from code/docs, say so explicitly in the output rather than filling it in with
-   plausible-sounding marketing language.
-
-## Output
-
-Hand off to `:storyboard`: mission/description (2-4 sentences), feature description (what/why/
-constraints), demo surface (routes, run command, any setup needed to reach the feature), and any
-flagged gaps.

package/plugins/session-manager-dev/skills/blog-for-project-feature/2-storyboard/SKILL.md

@@ -1,64 +0,0 @@
----
-name: blog-for-project-feature:storyboard
-description: Step 2 of blog-for-project-feature — turn the feature notes into an ordered, one-aspect-at-a-time sequence of demo steps, each with a planned action, expected screen, and caption. A draft for :capture to execute and correct against reality.
----
-
-# blog-for-project-feature:storyboard
-
-## Input
-Mission/description + feature description + demo surface (routes, run command, setup), from
-`:research`.
-
-## Steps
-
-1. **Break the feature into aspects**, not just clicks. Each storyboard step should reveal ONE
-   idea — a screen, a state change, a result — not an arbitrary UI action. **5-10 steps** ("swipes")
-   is the target range; fewer feels thin, more starts diluting the "one aspect at a time" promise.
-
-2. **For each step, define:**
-   - `step`: index + short name (e.g. `2-queue-populated`)
-   - `action`: the exact interaction to perform to reach this state (navigate to X, click Y,
-     submit form with Z) — precise enough that `:capture` can execute it without re-deciding
-   - `expected_screen`: what should be visible when the action completes — this is the
-     hypothesis `:capture` verifies against the real app
-   - `capture_scope`: `full_page` or `component` (see the composition recipe below) — plus, when
-     `component`, which element/region to frame (a CSS selector, ARIA role+name, or plain
-     description precise enough for `:capture` to target a single element screenshot instead of
-     the whole viewport)
-   - `caption`: one sentence, written for the reader of the final page, naming what changed on
-     screen (not internal mechanics)
-
-3. **Compose the sequence with this recipe — authoritative, not a suggestion.** A full-page shot
-   every step is disorienting (the reader has to re-find the relevant thing each time); an
-   all-component sequence loses context (the reader forgets where they are in the app). Mix them
-   deliberately in this arc:
-   - **Orientation (1 step, `full_page`).** Where the feature lives in the real product — the
-     screen the reader would actually land on. Establishes context before zooming in.
-   - **Mechanism (2-5 steps, `component`).** The actual control, interaction, or state change,
-     cropped/framed to just that component so the reader's eye isn't hunting across a full
-     screen for what changed. This is the bulk of the demo — most features are *shown* here.
-   - **Variation or depth (0-2 steps, mixed).** Secondary states, options, or edge cases worth
-     surfacing. Default to `component`; use `full_page` only if the variation reshapes the whole
-     screen (a new page, a full dashboard swap) rather than one region of it.
-   - **Outcome (1-2 steps, `full_page`).** The result landing back in the real product, in
-     context — proof the feature actually changed something the user will encounter, not just a
-     component in isolation.
-
-   Decision rule when a step doesn't obviously fit: default to `component` — it isolates the
-   thing being demonstrated and reads more clearly at small size. Only use `full_page` for
-   orientation/outcome steps, or when the change genuinely spans the whole viewport (new page,
-   layout shift, multi-panel result) and a cropped shot would lose the point.
-
-4. **Order for narrative sense**: entry point → mechanism → variation → outcome, per the recipe
-   above. Match `content.demo_interaction` in `feature.config.yaml` (one-step reveal, not a
-   scroll dump) — so the order IS the reveal sequence.
-
-5. **Note any setup steps** needed before step 1 is reachable (login, seed data, feature flag)
-   — hand these to `:capture` explicitly so it isn't guessing at prerequisites.
-
-## Output
-
-Hand off to `:capture`: the ordered step list (`step`, `action`, `expected_screen`,
-`capture_scope`, `caption`) plus any setup/prerequisite steps. This is a draft — `:capture` is
-expected to correct captions, adjust `capture_scope` if the planned framing doesn't hold up
-against the real screen, or drop steps that don't match what the real app actually shows.

package/plugins/session-manager-dev/skills/blog-for-project-feature/3-capture/SKILL.md

@@ -1,52 +0,0 @@
----
-name: blog-for-project-feature:capture
-description: Step 3 of blog-for-project-feature — drive the REAL running app and take a real screenshot per storyboard step. Never fabricates or mocks an image; drops and reports any step it can't actually reach.
----
-
-# blog-for-project-feature:capture
-
-## Input
-Ordered storyboard steps (`step`, `action`, `expected_screen`, `capture_scope`, `caption`) +
-setup steps, from `:storyboard`.
-
-## Steps
-
-1. **Get the app running for real.** Check for an existing project skill that already knows how
-   to launch it (e.g. a `run` skill) before improvising. If none exists, use the project's own
-   documented run command from `:research`'s demo surface notes.
-
-2. **Execute setup steps first** (login, seed data, navigation to the feature's entry point) —
-   exactly as specified by `:storyboard`, adjusting only if the real app's actual flow differs
-   (e.g. a login form field is named differently than assumed).
-
-3. **For each storyboard step, in order:**
-   - Perform the `action` using `mcp__playwright__browser_navigate` /
-     `browser_click` / `browser_type` / etc.
-   - Take the screenshot per the step's `capture_scope`:
-     - `full_page`: `mcp__playwright__browser_take_screenshot` for the full viewport/page.
-     - `component`: use a `ref`/element target (via `browser_snapshot` to locate the element,
-       then an element-scoped `browser_take_screenshot`) framed to the specific control or
-       region the step calls out — not the whole viewport. If the described element can't be
-       resolved to a single clean region, fall back to `full_page` for that step rather than
-       guessing at a crop.
-   - Compare what actually rendered against `expected_screen`. If it matches: keep the step,
-     correct the caption only if something material differs (a number, a label). If the planned
-     `capture_scope` doesn't hold up (the "component" is actually two disconnected regions, or a
-     "full_page" shot is so busy the point gets lost), correct `capture_scope` for that step
-     before saving. If the step doesn't match `expected_screen` at all (error state, feature not
-     reachable, requires access you don't have): **drop this step and record why** — do not
-     screenshot an error page and caption around it, and never substitute a mockup, wireframe, or
-     hand-drawn image for a missing real one.
-
-4. **Save images** per `feature.config.yaml`'s `images` block (format, max width, compression) —
-   downscale before handing to `:compose`, don't pass raw multi-MB captures through.
-
-5. **If a majority of steps drop**, stop and report — the feature isn't in a demoable state
-   right now; that's a valid outcome to surface to the user, not something to force through with
-   a thin 1-2 step demo.
-
-## Output
-
-Hand off to `:compose`: for each surviving step, the real image file + final caption; plus an
-explicit list of any dropped steps and why. `:compose` must never receive more steps than were
-actually captured.

package/plugins/session-manager-dev/skills/blog-for-project-feature/4-draft-copy/SKILL.md

@@ -1,37 +0,0 @@
----
-name: blog-for-project-feature:draft-copy
-description: Step 4 of blog-for-project-feature — write the FINAL prose for the Mission and Feature Description sections from research notes + captured steps. This finalized text is what :illustrate reads to generate the companion image, and what :compose drops into the page verbatim.
----
-
-# blog-for-project-feature:draft-copy
-
-## Input
-Mission/description + feature description + any flagged gaps (from `:research`), captured
-steps with real captions (from `:capture`).
-
-## Steps
-
-1. **Write the final Mission & Description** (2-4 sentences) from `:research`'s notes — tighten
-   for the reader of a feature page, but do not add any claim not already in the notes.
-
-2. **Write the final Feature Description** (1-2 short paragraphs) — what it does, why it
-   matters, any real constraint — grounded the same way.
-
-3. **Write one "essence" line** (1 sentence, separate from the two sections above): the single
-   idea this feature page should leave someone with if they read nothing else. This is not
-   rendered directly on the page — it's the brief `:illustrate` uses to generate a companion
-   image, so it should be concrete and visual (name the object/action, not an abstract benefit).
-   Example: not "streamlines developer workflow" but "a terminal tab holding a live Claude Code
-   session, sitting next to its sibling tabs."
-
-4. **Respect `content.tone`** in `feature.config.yaml` (plain, non-salesy, show-don't-tell) —
-   same bot-tell blocklist bar as `blog-from-git`.
-
-5. **If `:research` flagged a gap** (no documented mission, etc.), keep that gap explicit here
-   rather than papering over it with invented copy — `:compose` renders the gap-note verbatim.
-
-## Output
-
-Hand off to `:illustrate` and `:compose`: final Mission & Description text, final Feature
-Description text, the one-sentence essence line, and captured step captions unchanged from
-`:capture`.

package/plugins/session-manager-dev/skills/blog-for-project-feature/5-illustrate/SKILL.md

@@ -1,50 +0,0 @@
----
-name: blog-for-project-feature:illustrate
-description: Step 5 of blog-for-project-feature — generate ONE companion illustration that captures the feature's essence, from the finalized copy (not before it exists). Runs after :draft-copy, before :compose. Skips cleanly (never blocks the pipeline) when no image-generation capability is configured.
----
-
-# blog-for-project-feature:illustrate
-
-Runs strictly **after** `:draft-copy` — the companion image is generated from the finalized
-essence line, not from raw research notes, so it actually reflects what the page ends up saying
-rather than an earlier draft of it.
-
-## Input
-The one-sentence "essence" line + final Feature Description, from `:draft-copy`.
-
-## Steps
-
-1. **Check for an available image-generation capability** before doing anything else, in this
-   order:
-   - a project-local generator the target project already has wired up (e.g. Burrow's own
-     `app/shared/image_gen.py`) — reuse it as-is rather than reimplementing
-   - otherwise, **default to the Gemini API** (same provider/pattern as Burrow's
-     `image_gen.py`: `gemini-2.5-flash-image` via `google-genai`) using whatever Gemini API key
-     is available in the environment (`GEMINI_API_KEY` / `GOOGLE_API_KEY`) — this is the
-     standard path for projects with no generator of their own yet
-   - **if no Gemini key or other generator is available, skip this step cleanly** — report "no image-generation capability
-     available, companion image omitted" and hand `:compose` nothing. This is a valid, expected
-     outcome on environments without a configured image provider — never block the pipeline on
-     it, and never substitute a stock photo, icon pack graphic, or hand-placed screenshot as a
-     stand-in for a generated illustration (that would violate the same no-fabrication rule
-     `:capture` follows, just for a different image class).
-
-2. **If available, generate exactly ONE image** from a prompt built as: the essence line +
-   `feature.config.yaml`'s `illustration` style tokens (mood/palette/composition) + an explicit
-   instruction that this is a conceptual/editorial illustration, NOT a UI mockup or screenshot
-   — it must be visually distinguishable at a glance from the real click-through screenshots
-   (no fake window chrome, no invented UI text). This distinction matters: `:review` gate 2
-   checks that nothing generated here could be mistaken for a real captured screen.
-
-3. **Save and size** per `feature.config.yaml`'s `illustration` block (format, max dimensions,
-   compression) — same discipline as `:capture`'s screenshot handling.
-
-4. **One regeneration attempt max** if the first result is off-brief (wrong subject, contains
-   text/UI chrome it shouldn't). If still off after one retry, drop it and report rather than
-   shipping a confusing image.
-
-## Output
-
-Hand off to `:compose`: either one companion image file (clearly tagged as `kind: illustration`,
-distinct from `kind: screenshot` steps from `:capture`), or an explicit "omitted — no generator
-available" / "omitted — two attempts off-brief" note.

package/plugins/session-manager-dev/skills/blog-for-project-feature/6-compose/SKILL.md

@@ -1,51 +0,0 @@
----
-name: blog-for-project-feature:compose
-description: Step 6 of blog-for-project-feature — assemble the finalized copy, the optional companion illustration, and the captured screenshots into one self-contained, portable, click-through HTML page per feature.config.yaml's theme and output conventions.
----
-
-# blog-for-project-feature:compose
-
-## Input
-Final Mission & Description text + final Feature Description text (from `:draft-copy`),
-captured steps with real images and captions (from `:capture`), the companion illustration or
-its omission-reason (from `:illustrate`).
-
-## Steps
-
-1. **Pick output mode** per `feature.config.yaml`: default `single_file` with base64-embedded
-   images. Estimate total size first (sum of image bytes after downscale/compression, including
-   the companion illustration if present); if it would exceed `single_file_size_ceiling_mb`, use
-   the `folder_fallback_layout` instead (html + `screenshots/` dir, relative paths).
-
-2. **Build the page**, self-contained (inline `<style>`/`<script>`, no external CDN/font/JS
-   requests — must work fully offline via `file://`), with exactly the three required sections,
-   **Click-Through Demo first** — the real screenshots are the most persuasive thing on the page,
-   so they lead, above the fold, before any prose:
-   - **Click-Through Demo** — the captured steps rendered as a one-step-at-a-time viewer
-     (numbered tabs or next/prev buttons — vanilla JS, no framework). Each step's real image
-     renders on top, full width within the viewer, with its caption directly below it — image
-     first, caption second, never the reverse. Screenshots only — the illustration never appears
-     in this section. This section opens the page, immediately above the fold.
-   - **Project Mission & Description** — the finalized text from `:draft-copy`, verbatim
-   - **Feature Description** — the finalized text from `:draft-copy`, verbatim. If a companion
-     illustration exists, place it here as a header/hero image for the section — never inside
-     the Click-Through Demo viewer, so it's never confusable with a real screenshot
-   - If `:illustrate` reported an omission, skip the hero image silently (it's an optional
-     companion, not a required section) — do not note the omission on the page itself
-
-3. **Apply theme tokens** from `feature.config.yaml`'s `theme` block (font stack, colors,
-   radius, max width) — keep it minimal and consistent, this is not a place to freelance a new
-   visual style per run.
-
-4. **Write the file** to `output.path_template` (or the folder fallback), resolving
-   `{feature-slug}` from the confirmed feature name (kebab-case).
-
-5. **If a required section would be empty** (e.g. `:research` flagged a real gap and nothing
-   was found), do not silently omit it — render it with an explicit note ("mission statement not
-   documented in this project") so `:review` and the reader both see the gap rather than a
-   silently thinner page.
-
-## Output
-
-Hand off to `:review`: the path to the composed HTML (or html+folder), the output mode used,
-final size, and whether a companion illustration was included.

package/plugins/session-manager-dev/skills/blog-for-project-feature/7-review/SKILL.md

@@ -1,54 +0,0 @@
----
-name: blog-for-project-feature:review
-description: Step 7 of blog-for-project-feature — check the composed HTML against feature.config.yaml's gate list before reporting it ready. Loops back to :compose for content issues, :capture for screenshot gaps, or :illustrate for a mislabeled companion image; never ships on a failed gate.
----
-
-# blog-for-project-feature:review
-
-## Input
-Path to the composed HTML (or html+folder) + output mode + size, from `:compose`.
-
-## Steps
-
-Check every item in `feature.config.yaml`'s `gates` list against the actual file:
-
-1. Open it (or inspect its markup directly) and confirm every image reference resolves — for
-   base64-embedded images this means the data URI is present and non-empty; for the folder mode,
-   confirm each referenced file actually exists on disk.
-2. Confirm zero placeholder/mockup images slipped through — cross-check every `kind: screenshot`
-   image against `:capture`'s reported real captures; anything not in that list is a violation.
-   If a companion illustration is present, confirm it's placed only in the Feature Description
-   header (never inside the Click-Through Demo) and is visually distinguishable from a real
-   screenshot (no fake window chrome/UI text) — if it could pass as a captured screen, that's a
-   violation too.
-3. Confirm all three required sections are present and non-empty (or explicitly gap-noted per
-   `:compose` step 5, which is an acceptable non-empty state). The companion illustration is
-   optional — its absence is never a gate failure.
-4. Confirm the section order matches `feature.config.yaml`'s `content.sections_required` —
-   Click-Through Demo leads the page (above the fold, before the prose sections), each visible
-   step showing its real image on top and the caption directly below it.
-5. Confirm the demo is genuinely click-through — the next/prev or tab controls exist and their
-   JS actually switches the visible step (not just a cosmetic active-class flip with all steps
-   rendered stacked underneath).
-6. Confirm no external network calls (grep for `http://`/`https://` in `<script src>`,
-   `<link href>`, `fetch(`, `@import` — should be none).
-7. Confirm the size ceiling was respected for the mode chosen.
-8. Spot-check 2-3 sentences in the Mission/Feature sections against `:research`'s notes for
-   traceability — flag anything that reads like invented marketing language.
-
-## On failure
-
-- **Content/structure issue** (sections, theme, controls, external calls, size) → loop back to
-  `:compose` with the specific gate that failed.
-- **Screenshot issue** (missing/broken image, a step that needs re-capturing) → loop back to
-  `:capture` for that step specifically, then re-run `:compose` for just the affected step.
-- **Illustration issue** (looks like a mockup/screenshot, placed in the wrong section) → loop
-  back to `:illustrate` for one more attempt, or drop it entirely and re-run `:compose` without it.
-- Never mark the page ready with a known-failing gate "to save time" — a shorter honest page
-  beats a complete one that fails its own checklist.
-
-## Output
-
-On all-pass: report the final path, output mode, size, and step count to the user. State clearly
-that publishing/uploading/deploying happens **only if explicitly asked next** — this step's job
-ends at "ready," not "shipped."

package/plugins/session-manager-dev/skills/blog-for-project-feature/SKILL.md

@@ -1,144 +0,0 @@
----
-name: blog-for-project-feature
-description: Produce a self-contained, interactive HTML "feature showcase" for one project + one feature — Project Mission & Description, Feature Description (with an optional generated companion illustration), and a Click-Through Demo built from REAL screenshots (never mockups) — one aspect revealed at a time. Output is a single portable HTML file uploadable anywhere (no server, no build step). Distinct from blog-from-git (which drafts narrative bilko.run changelog posts from git history) — this is an evergreen, per-feature product page, not a dated post. Orchestrates 8 nested sub-skills (blog-for-project-feature:select, :research, :storyboard, :capture, :draft-copy, :illustrate, :compose, :review) so each step is independently invokable and inspectable. Use for "make a feature page for X", "showcase this feature", "/blog-for-project-feature", "interactive demo of X", or turning a shipped feature in Session Manager / Social Signal Builder (or any project) into something you can hand someone a link to.
----
-
-# blog-for-project-feature (orchestrator)
-
-Project-agnostic. Runs against whatever project the current working directory (or a named
-project path) points to — built first for **Session Manager** and **Social Signal Builder**,
-but nothing here is hardcoded to either.
-
-**Not `blog-from-git`.** That skill drafts a dated, narrative bilko.run post from git activity
-("here's what shipped this week"). This skill produces an **evergreen, single-feature product
-page** — no date, no changelog framing, not tied to a publishing cadence. One project, one
-feature, three things: what the project is for, what this feature does, and a real click-through
-demo of it working. The two skills never share output or ledger state.
-
-**`feature.config.yaml` in this folder is the grounding authority** for output conventions
-(where the HTML lands, image size/compression limits, single-file-vs-folder default, theme
-tokens). Read it first, before any sub-skill file. If prose here ever disagrees with the config,
-the config wins.
-
-## Pipeline DAG
-
-```
-project (+ optional feature name)
-              │
-              ▼
-┌───────────────────────────────┐
-│ 0. blog-for-project-feature:select │──▶ one confirmed project + one confirmed feature
-└───────────────────────────────┘
-              │
-              ▼
-┌───────────────────────────────┐
-│ 1. :research                       │──▶ mission, feature description, key files/entry points
-└───────────────────────────────┘
-              │
-              ▼
-┌───────────────────────────────┐
-│ 2. :storyboard                     │──▶ ordered demo steps (action, expected screen, caption)
-└───────────────────────────────┘
-              │
-              ▼
-┌───────────────────────────────┐
-│ 3. :capture                        │──▶ real screenshots per step (+ storyboard corrections)
-└───────────────────────────────┘        │ no real screenshot obtainable for a step
-              │ all steps captured        ▼
-              ▼                    STOP — report which step blocked, don't fabricate
-┌───────────────────────────────┐
-│ 4. :draft-copy                     │──▶ FINAL mission/feature text + one-sentence "essence" line
-└───────────────────────────────┘
-              │
-              ▼
-┌───────────────────────────────┐
-│ 5. :illustrate                     │──▶ one companion illustration from the essence line
-└───────────────────────────────┘        (or a clean "omitted" note — never blocks the pipeline)
-              │
-              ▼
-┌───────────────────────────────┐
-│ 6. :compose                        │──▶ one self-contained interactive HTML file
-└───────────────────────────────┘
-              │
-              ▼
-┌───────────────────────────────┐
-│ 7. :review                         │──── fails a check ────┐
-└───────────────────────────────┘                            │
-              │ passes                                        │
-              ▼                                                │
-     report path, wait for explicit                            │
-     "publish/upload" instruction          loop back to :compose / :capture / :illustrate
-```
-
-| Step | Input | Output | On failure |
-|---|---|---|---|
-| 0. `:select` | project (cwd or named) + optional feature hint | one confirmed project + one confirmed feature name + why it's demo-worthy | **STOP** — report if no clear feature can be confirmed (don't guess) |
-| 1. `:research` | confirmed project + feature | mission/description (project-level), feature description, key files, how it actually works | n/a — always produces notes, flags gaps explicitly rather than inventing claims |
-| 2. `:storyboard` | mission + feature notes | ordered list of `{step, action, expected_screen, capture_scope, caption}`, 5-10 steps, a deliberate mix of full-page and component-scoped shots | n/a — storyboard is a draft, `:capture` is allowed to correct it |
-| 3. `:capture` | storyboard | one real screenshot file per step + any corrected captions | **STOP** on that step — report what's missing; never substitute a placeholder/mockup image |
-| 4. `:draft-copy` | research notes + captured captions | final Mission & Feature Description prose + one-sentence essence line | n/a — always produces final text, gaps stay explicit |
-| 5. `:illustrate` | the essence line (text must exist first) | one companion illustration, tagged distinct from screenshots — or an explicit omission note | never blocks — skips cleanly if no image generator is configured, or after one off-brief retry |
-| 6. `:compose` | final copy + captured steps + optional illustration | one self-contained HTML file (or html+images folder per config) | loop back to `:capture` if a required image is missing, else fix and retry |
-| 7. `:review` | the composed HTML | pass/fail against the gate below | loop back to `:compose` (content), `:capture` (screenshot), or `:illustrate` (mislabeled companion image) — never ship on a failed gate |
-
-## Golden rule: screenshots are real or the step doesn't exist
-
-This skill exists specifically because "feature demo" content is worthless if the images are
-invented, stale, or from the wrong build. `:capture` uses `mcp__playwright__*` (or the project's
-own screenshot tooling if `run`/a project skill already drives it — check for one first) against
-a running instance of the actual project. If a step can't be captured for real (app won't start,
-feature is behind auth you don't have, flow requires data that doesn't exist locally), **that
-step is dropped and reported, not faked.** A shorter, honest demo beats a complete, fabricated one.
-
-## Output
-
-Default: one self-contained `.html` file (inline CSS/JS, base64-embedded images) written to
-`docs/feature-showcase/<project-slug>-<feature-slug>.html` inside **`~/Projects/Bilko`** —
-never inside the showcased project's own repo, even when the feature being showcased belongs
-to a different project entirely. Bilko is the author/publisher of every showcase (same as
-`blog-from-git`'s posts), is guaranteed to be locally writable across sessions, and these pages
-are destined to eventually post to bilko.run — so output collects in one place from the start.
-See `feature.config.yaml` for the exact path convention, size ceiling, and the single-file vs.
-folder fallback (used when embedded images would blow past the size ceiling). This is what
-"uploadable anywhere" means: no server, no relative asset paths, no build step — open the file
-or drop it on any static host and it works.
-
-**Only push, deploy, or upload when explicitly asked.** Report the local path and a one-line
-description of what the page shows, and wait — same convention as `blog-from-git`'s seed gate
-and `issue-address`'s "only push when asked" rule.
-
-## Why nested skills instead of one inline pass
-
-Same reasoning as `issue-address` and `pr-review-sweep`: each phase is a real, independently
-invokable `SKILL.md` so progress is visible step by step ("storyboard produced 5 steps, capture
-got 4 real screenshots, 1 dropped") instead of one opaque generation pass, and a single phase
-(e.g. swapping the screenshot tool, changing the HTML theme) can be edited without touching the
-others. If a step is still doing too much once this ships, decompose it further the same way
-`issue-address:select` was (nested sub-DAG) — continuously, wherever one file covers too much to
-inspect as one unit.
-
-## Folder map
-
-```
-blog-for-project-feature/
-  feature.config.yaml ← output path convention, size ceiling, theme tokens — read first
-  SKILL.md             ← this file: pipeline, DAG, output contract
-  0-select/SKILL.md
-  1-research/SKILL.md
-  2-storyboard/SKILL.md
-  3-capture/SKILL.md
-  4-draft-copy/SKILL.md
-  5-illustrate/SKILL.md
-  6-compose/SKILL.md
-  7-review/SKILL.md
-```
-
-## What this skill is not
-
-- Not `blog-from-git` — no dated post, no rotation ledger, no git-diff scan. This is
-  feature-scoped and evergreen; that skill is time-scoped and narrative.
-- Not a marketing copy generator — every claim in `:research`'s output must trace to real code,
-  docs, or a live screenshot, same evidentiary bar as `blog-from-git`'s `ground.md`.
-- Not a full site generator — one feature, one page, per run. A project with N features worth
-  showcasing gets N runs (and, if wanted later, a separate index/landing skill — not built yet,
-  don't invent one inline).

package/plugins/session-manager-dev/skills/blog-for-project-feature/feature.config.yaml

@@ -1,90 +0,0 @@
-# Grounding authority for blog-for-project-feature. Read this before any sub-skill file.
-# If prose in a SKILL.md ever disagrees with this file, this file wins.
-
-output:
-  # Path is relative to ~/Projects/Bilko (the Bilko repo) — ALWAYS, regardless of which
-  # project the showcased feature lives in. Bilko is the author/publisher of every showcase
-  # (same reason blog-from-git's posts live in Bilko, not in the project they're about) and
-  # these pages are destined to eventually be posted on bilko.run — Bilko is the one repo
-  # guaranteed to be locally writable across every session this skill runs in, and keeping
-  # output there means all showcases accumulate in one place instead of scattering across
-  # sibling repos. Never write the HTML into the target project's own repo.
-  base_repo: "~/Projects/Bilko"
-  path_template: "docs/feature-showcase/{project-slug}-{feature-slug}.html"
-  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"
-  feature_slug_rule: "kebab-case, derived from the confirmed feature name in :select"
-  # Prefer one self-contained file. Only fall back to a folder when the size ceiling
-  # below would be exceeded by inlining images.
-  default_mode: single_file          # single_file | folder
-  folder_fallback_layout:
-    html: "docs/feature-showcase/{project-slug}-{feature-slug}/index.html"
-    images: "docs/feature-showcase/{project-slug}-{feature-slug}/screenshots/"
-  single_file_size_ceiling_mb: 8       # switch to folder_fallback_layout above this
-  never_upload_or_deploy_without_explicit_ask: true
-
-images:
-  format: png
-  max_width_px: 1600                  # downscale before embedding; demo clarity, not pixel-perfect
-  compression: "reasonable lossy ok for PNG->WebP if it keeps text legible; never so lossy captions become unreadable"
-  source_of_truth: "mcp__playwright__browser_take_screenshot against a real running instance"
-  placeholder_or_mockup_images: forbidden   # a dropped step beats a fabricated one
-  capture_scope: "full_page | component, chosen per step in :storyboard and executed in :capture.
-    Full-page screenshots are not always the clearest way to show a feature — a control or state
-    change is often clearer cropped to just that component. Default to component-scoped shots for
-    mechanism/detail steps; reserve full_page for orientation (where the feature lives) and
-    outcome (the result landing back in the real product) steps. See :storyboard's composition
-    recipe for the authoritative mix."
-
-illustration:
-  # The ONE companion image, generated by :illustrate — a distinct image class from the
-  # click-through screenshots above. Optional: omitted cleanly if no generator is configured.
-  runs_after: draft-copy               # never generate from anything but finalized copy
-  generator: "project-local generator if the target project has one, else Gemini
-    (gemini-2.5-flash-image via google-genai — same provider/pattern as Burrow's
-    app/shared/image_gen.py) using GEMINI_API_KEY / GOOGLE_API_KEY from the environment"
-  count: 1
-  placement: "Feature Description section header only — never inside the Click-Through Demo"
-  format: png
-  max_width_px: 1200
-  style: "conceptual/editorial illustration — mood/palette should follow the project's own
-    theme tokens above if it has brand colors, otherwise a clean flat/geometric style"
-  must_not_resemble: "a UI mockup, screenshot, or contain invented interface text/window chrome
-    — must be visually distinguishable from a real captured screen at a glance"
-  max_regeneration_attempts: 1
-  on_no_generator_available: "skip silently, no page-visible note, report to the operator only"
-
-content:
-  sections_required:
-    # Order matters: this IS the on-page order, top to bottom.
-    - "Click-Through Demo"              # LEADS the page — the storyboard steps, one aspect
-                                         # revealed at a time; screenshot on top, caption below
-    - "Project Mission & Description"   # 2-4 sentences, from :research, project-level not feature-level
-    - "Feature Description"             # what it does, why it matters, 1-2 short paragraphs
-  demo_interaction: "one-step-at-a-time reveal (next/prev controls or numbered tabs) — never a single long scroll dump of every screenshot at once. Each step: real image on top, caption directly below it."
-  demo_step_count: "5-10 steps (a mix of full_page and component-scoped captures — see :storyboard's composition recipe), not a flat full-page-per-step dump"
-  tone: "same plain, non-salesy, show-don't-tell bar as blog-from-git/voice.md bot-tell blocklist — no 'excited to share', no grand-implication filler"
-  caption_rule: "every screenshot has a one-sentence caption naming what changed on screen, not what the code does internally"
-
-theme:
-  # Minimal neutral tokens so every showcase looks consistent without importing a design system.
-  # Swap these per-project only if the project has its own documented brand tokens.
-  font_stack: "system-ui, -apple-system, 'Segoe UI', sans-serif"
-  bg: "#0b0d10"
-  surface: "#15181d"
-  text: "#e8eaed"
-  text_muted: "#9aa0a6"
-  accent: "#5b9dff"
-  radius_px: 10
-  max_width_px: 900
-
-gates:
-  # Checked in step 7 (:review). All must pass before reporting the page ready.
-  - "every image referenced actually loads (no broken src, no 404 in a local file:// open)"
-  - "zero placeholder/mockup images — every screenshot traces to a real :capture run"
-  - "if present, the companion illustration sits only in the Feature Description header and is
-    visually distinguishable from a real screenshot (no UI chrome/invented interface text)"
-  - "all three required sections present and non-empty (illustration is optional, never gates)"
-  - "demo is click-through (has working next/prev or tab controls), not a flat scroll"
-  - "file opens correctly via file:// with no console errors (network calls, external CDN fonts/JS forbidden — must be fully offline-capable)"
-  - "single_file_size_ceiling_mb respected, or folder fallback used instead"
-  - "no invented claims — every sentence in Mission/Feature sections traces to :research notes"