@launchsecure/launch-kit 0.0.38 → 0.0.39

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@launchsecure/launch-kit",
-  "version": "0.0.38",
+  "version": "0.0.39",
   "description": "LaunchSecure toolkit — launch-sequencer (pipeline runner + terminal bridge), launch-radar (feedback webhook receiver), launch-chart (project graph MCP), launch-deck (visual playground MCP), launch-kit-beacon (feedback Web Component), launch-recall (file-watcher backup). launch-pod is the container image these run inside.",
   "license": "MIT",
   "author": "LaunchSecure - AutomateWithUs",
@@ -59,6 +59,24 @@
     "launch-rover": "./dist/server/rover-entry.js",
     "launch-bot": "./dist/server/launch-bot-entry.js"
   },
+  "scripts": {
+    "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
+    "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
+    "test:beacon": "vitest run --config vite.beacon.config.ts",
+    "test:radar": "vitest run --config vite.radar.config.ts",
+    "test:chart": "vitest run --config vite.chart.test.config.ts",
+    "build:deck-client": "vite build --config vite.deck.config.ts",
+    "build:council-client": "vite build --config vite.council.config.ts",
+    "build:client": "vite build",
+    "build:chart-client": "vite build --config vite.chart.config.ts",
+    "build:server": "esbuild src/server/cli.ts src/server/fb-wizard.ts src/server/graph-mcp-entry.ts src/server/chart-serve.ts src/server/deck-mcp-entry.ts src/server/deck-serve.ts src/server/council-entry.ts src/server/council-serve.ts src/server/recall-entry.ts src/server/init-entry.ts src/server/orbit-entry.ts src/server/course-entry.ts src/server/beacon-monitor-entry.ts src/server/parse-worker-entry.ts src/server/radar-teardown-entry.ts src/server/radar-docker-init-entry.ts src/server/launch-radar-entry.ts src/server/rover-entry.ts src/server/launch-bot-entry.ts --bundle --platform=node --target=node18 --outdir=dist/server --external:node-pty --external:ws --external:typescript --external:web-tree-sitter --external:tree-sitter-typescript --external:cloudflared --external:pg --external:pg-native --external:pgsql-parser --external:libpg-query && rm -rf dist/server/public && cp -r ../claude-code-web/src/public dist/server/public && rm -rf dist/server/graph/queries && mkdir -p dist/server/graph && cp -r src/server/graph/queries dist/server/graph/queries",
+    "dev:client": "vite",
+    "dev:deck-serve": "cd ../.. && tsx watch packages/cli/src/server/deck-mcp-entry.ts serve",
+    "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
+    "dev:server": "pnpm build:server && node dist/server/cli.js",
+    "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\"",
+    "prepublishOnly": "pnpm build"
+  },
   "files": [
     "dist",
     "prompts",
@@ -79,6 +97,8 @@
     "ws": "^8.18.0"
   },
   "devDependencies": {
+    "@launchsecure/claude-code-web": "workspace:*",
+    "@launchsecure/ui": "workspace:*",
     "@types/node": "^20.0.0",
     "@types/pg": "^8.11.10",
     "@types/react": "^18.3.12",
@@ -102,25 +122,6 @@
     "react-router-dom": "^6.28.0",
     "tailwindcss": "^3.4.19",
     "vite": "^5.4.11",
-    "vitest": "^1.6.0",
-    "@launchsecure/claude-code-web": "0.0.1",
-    "@launchsecure/ui": "0.0.1"
-  },
-  "scripts": {
-    "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
-    "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
-    "test:beacon": "vitest run --config vite.beacon.config.ts",
-    "test:radar": "vitest run --config vite.radar.config.ts",
-    "test:chart": "vitest run --config vite.chart.test.config.ts",
-    "build:deck-client": "vite build --config vite.deck.config.ts",
-    "build:council-client": "vite build --config vite.council.config.ts",
-    "build:client": "vite build",
-    "build:chart-client": "vite build --config vite.chart.config.ts",
-    "build:server": "esbuild src/server/cli.ts src/server/fb-wizard.ts src/server/graph-mcp-entry.ts src/server/chart-serve.ts src/server/deck-mcp-entry.ts src/server/deck-serve.ts src/server/council-entry.ts src/server/council-serve.ts src/server/recall-entry.ts src/server/init-entry.ts src/server/orbit-entry.ts src/server/course-entry.ts src/server/beacon-monitor-entry.ts src/server/parse-worker-entry.ts src/server/radar-teardown-entry.ts src/server/radar-docker-init-entry.ts src/server/launch-radar-entry.ts src/server/rover-entry.ts src/server/launch-bot-entry.ts --bundle --platform=node --target=node18 --outdir=dist/server --external:node-pty --external:ws --external:typescript --external:web-tree-sitter --external:tree-sitter-typescript --external:cloudflared --external:pg --external:pg-native --external:pgsql-parser --external:libpg-query && rm -rf dist/server/public && cp -r ../claude-code-web/src/public dist/server/public && rm -rf dist/server/graph/queries && mkdir -p dist/server/graph && cp -r src/server/graph/queries dist/server/graph/queries",
-    "dev:client": "vite",
-    "dev:deck-serve": "cd ../.. && tsx watch packages/cli/src/server/deck-mcp-entry.ts serve",
-    "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
-    "dev:server": "pnpm build:server && node dist/server/cli.js",
-    "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\""
+    "vitest": "^1.6.0"
   }
-}
+}

package/scaffolds/ls-marketplace/plugins/kit/commands/activate-statusline.md

@@ -1,5 +1,5 @@
 ---
-description: Wire launch-kit's MCP chips into the user's existing Claude Code statusline. Additive — does not create or replace an existing statusline, only appends colored chips (recall/chart/deck/council/secure) showing each daemon's liveness + last-activity age, plus a reachability probe for the hosted launch-secure MCP. Idempotent. Run /kit:deactivate-statusline to undo.
+description: Wire launch-kit's MCP chips into the user's Claude Code statusline. Appends colored chips (recall/chart/deck/council/secure) showing each daemon's liveness + last-activity age, plus a reachability probe for the hosted launch-secure MCP. If the user has no statusline, scaffolds Claude Code's default base line first so the chips have something to attach to. Idempotent. Run /kit:deactivate-statusline to undo.
 ---
 
 # /kit:activate-statusline
@@ -9,11 +9,12 @@ Extends the user's existing `~/.claude/settings.json` statusline so MCP daemon h
 ## What it does
 
 1. Reads `~/.claude/settings.json` and checks for an existing `statusLine.command`.
-   - If absent → reports plainly that the user must create their own statusline first. Do NOT scaffold one — launch-kit only EXTENDS, never CREATES.
-2. Writes two scripts under `~/.launchsecure/`:
+   - If absent → scaffolds `statusline-base.sh` (Claude Code's documented default base line: model · folder · context %) and stashes it as the original, so the chips render over a useful line instead of bailing. Creates `~/.claude/settings.json` if it doesn't exist.
+2. Writes scripts under `~/.launchsecure/`:
    - `statusline-mcp.sh` — emits the colored MCP chips.
-   - `statusline-wrapper.sh` — runs the user's original command, then appends chips.
-3. Replaces `statusLine.command` with the wrapper, stashing the original under `_launchKitStatuslineOriginal` inside the same settings.json (single source of truth, no sidecar state).
+   - `statusline-wrapper.sh` — runs the original (or scaffolded base) command, then appends chips.
+   - `statusline-base.sh` — only when scaffolding; the default base line.
+3. Replaces `statusLine.command` with the wrapper, stashing the original (or scaffolded base) under `_launchKitStatuslineOriginal` inside the same settings.json (single source of truth, no sidecar state).
 4. Idempotent: if the wrapper is already wired, refreshes the chip scripts only.
 
 ## How to run
@@ -37,9 +38,9 @@ node packages/cli/dist/server/init-entry.js statusline activate [--show=...]
 If the user passed an argument to the slash command (e.g. `/kit:activate-statusline recall,chart`), forward it as `--show=$ARGUMENTS`.
 
 The command prints one of:
-- `✓ activated …` — newly wrapped
+- `✓ activated …` — newly wrapped an existing statusline
+- `✓ scaffolded …` — user had no statusline; scaffolded the default base line + chips
 - `✓ refreshed …` — already wrapped, scripts refreshed
-- `✗ no-statusline …` — user has no statusline; report this and stop, do not propose creating one
 
 ## After running
 

package/scaffolds/ls-marketplace/plugins/kit/commands/deactivate-statusline.md

@@ -9,8 +9,8 @@ Reverses `/kit:activate-statusline`. Restores `~/.claude/settings.json`'s `statu
 ## What it does
 
 1. Reads `~/.claude/settings.json`.
-2. If `_launchKitStatuslineOriginal` is present, copies it back to `statusLine` and deletes the stash key.
-3. Removes `~/.launchsecure/statusline-wrapper.sh` and `~/.launchsecure/statusline-mcp.sh`.
+2. If `_launchKitStatuslineOriginal` is present, copies it back to `statusLine` and deletes the stash key. If the stash is launch-kit's own scaffolded base line (the user had no statusline before activation), removes `statusLine` entirely instead — back to no statusline.
+3. Removes `~/.launchsecure/statusline-wrapper.sh` and `~/.launchsecure/statusline-mcp.sh` (and `statusline-base.sh` if it was scaffolded).
 4. If `_launchKitStatuslineOriginal` is absent → reports "not active" and stops.
 
 ## How to run

package/scaffolds/ls-marketplace/plugins/kit/skills/comms/SKILL.md

@@ -0,0 +1,88 @@
+---
+description: Read, search, and post to the LaunchSecure Communication Center (CapCom) via the launch-secure MCP. Use to find a comment/feedback/discussion by wording or author, list a channel, or post an update. Knows the default system tags and the resource_type↔channel mapping so you don't have to call tags_list or page-and-grep.
+when_to_use: |
+  Auto-fire when the user wants to find, read, or post something in the LaunchSecure Communication Center / CapCom / Comm Hub. Trigger phrases: "find the feedback about X", "what did <person> say in comms", "search CapCom for Y", "read the feedback channel", "any discussions about Z", "post an update to comms", "what feedback did we get on W", "did anyone log X". Also auto-fire when an earlier attempt to find a comment failed and you reached for paging+grepping — that's the signal to use `q`/`author` server-side filters instead. Do NOT auto-fire for: writing a repo-backed long-form doc (use /kit:brief), drafting a daily standup (use /kit:standup), or filing a launch-kit bug/gap report (use kit_feedback_submit).
+allowed-tools:
+  - mcp__launch-secure__communication_read
+  - mcp__launch-secure__communication_write
+  - mcp__launch-secure__communication_update
+  - mcp__launch-secure__communication_vote
+  - mcp__launch-secure__communication_delete
+  - mcp__launch-secure__tags_list
+  - mcp__launch-secure__members_list
+---
+
+# /kit:comms
+
+Find, read, and post in the LaunchSecure Communication Center ("CapCom" / Comm Hub) through the `launch-secure` MCP. This skill exists because the failure mode is predictable: people pull a whole channel and grep locally, miss a comment, and conclude "it's not there" or "I can't read it." Use the server-side filters instead.
+
+`org_slug` / `project_slug` are **optional** — they default to the MCP's configured project (`.mcp.json` headers). Never ask the user for them unless a tool actually errors that they're missing.
+
+## The model that trips people up
+
+The CapCom UI sub-tabs (**All · Comments · Discussions · Issues · Requirements · Feedback**) map to **`resource_type`**, NOT to tags:
+
+| UI channel | `communication_read` filter |
+|---|---|
+| Comments | `resource_type: "comment"` |
+| Discussions | `resource_type: "discussion"` |
+| Issues | `resource_type: "issue"` |
+| Requirements | `resource_type: "requirement"` |
+| Feedback | `resource_type: "feedback"` |
+
+**A comment can be `resource_type:"feedback"` and NOT carry the `feedback` tag** — beacon-submitted feedback gets both the resource type and the tag, but legacy / non-beacon / pre-ingest feedback often has only the resource type. So `tag:"feedback"` and `resource_type:"feedback"` return **different sets**. To read the Feedback channel, filter by `resource_type:"feedback"` — not the tag.
+
+## Finding one comment (don't page-and-grep)
+
+`communication_read` filters compose with AND. The two that matter for search:
+
+- **`q`** — case-insensitive substring across **title AND body**. This is how you find a comment by its wording. `q:"create deck"` finds it in one call; pulling 50 comments and grepping does not (and misses anything whose text is in `title` only, or that wasn't in your page).
+- **`author`** — exact userId, or case-insensitive substring of the author's name/email. `author:"matt"` or `author:"hamann"`.
+
+Examples:
+- Find a feedback item by wording: `communication_read(resource_type:"feedback", q:"create deck")`
+- Everything a person logged: `communication_read(author:"hamann")`
+- A person's feedback only: `communication_read(resource_type:"feedback", author:"matt")`
+- A discussion by topic: `communication_read(resource_type:"discussion", q:"runtime logs")`
+
+If a search comes back empty, widen *before* concluding it's absent: drop `resource_type`, drop `tag`, try a shorter `q` stem (`"deck"` not `"create deck kit skill"`), try `author` alone. Only after the unfiltered `q`/`author` sweep is empty should you say it isn't there.
+
+## Default system tags
+
+These ship on every org (from `tags_list`, `isSystem: true`) — you don't need to call `tags_list` to know them, only to get their **IDs** for a write. Numeric tags (e.g. `247`) are auto-created per work-item and are not in this list.
+
+| Tag | Meaning |
+|---|---|
+| `announcement` | Team-wide announcement |
+| `daily_update` | Daily standup or status update |
+| `release` | Release note or changelog |
+| `deployment` | Deployment note or rollback log |
+| `decision` | Architectural or product decision |
+| `feature` | Feature request or enhancement |
+| `idea` | Feature idea or improvement suggestion |
+| `feedback` | User-submitted feedback (via launch-kit beacon) |
+| `bug` | Bug report or error |
+| `blocker` | Blocking issue needing attention |
+| `urgent` | Urgent priority item |
+| `question` | Open question needing an answer |
+| `review` | Code or design review thread |
+| `documentation` | Documentation related |
+| `Production` | Production incident, release, or hotfix |
+| `staging` | Staging environment update |
+| `a11y` | Accessibility concern |
+| `ux` | UX or design issue |
+
+To attach tags on a write you need their IDs: call `tags_list` once and map names → IDs (tag IDs are stable per org, names are not the API key).
+
+## Posting
+
+`communication_write` requires `body` (plaintext — canonical for search/sync). Optional: `title`, `resource_type` (`comment` default; `discussion`/`feedback`/`requirement`/`issue`), `tag_ids` (from `tags_list`), `parent_id` (reply), `mentions` (user IDs — resolve via `members_list`; only ACTIVE org members notify), `fields` (structured JSONB, e.g. beacon feedback), `status` (discussions).
+
+**Preview before you write.** CapCom posts are outward-facing and attributed to the user. Paste the full body in the terminal and wait for explicit "post it" before calling `communication_write` / `communication_update`. "Do it" / "go ahead" on an unrelated step does NOT authorize a Comm Hub write in the user's name. `communication_update` and `communication_delete` only work on the caller's own comments.
+
+## Constraints
+
+- **Repo-backed long-form doc?** That's `/kit:brief` — it writes a file and the server syncs the comment; don't hand-post it here.
+- **Daily standup?** That's `/kit:standup` — it has the voice/format conventions and the "since last push" diffing.
+- **Bug/gap in launch-kit itself?** That's `kit_feedback_submit`, not a hand-written comment.
+- **Reading is free; writing is gated.** Default to read/search freely; gate every write on an explicit go-ahead.

package/scaffolds/ls-marketplace/plugins/kit/skills/project-info/SKILL.md

@@ -0,0 +1,88 @@
+---
+description: Populate or refresh the local project-info snapshot (.claude/launch-kit/project-info.md) from LaunchSecure — members, providers/integrations, and environments — so Claude knows them every session without re-querying. Gitignored, CLAUDE.md-imported. Run after team/provider/env changes to refresh.
+when_to_use: |
+  Auto-fire when the user wants to populate or refresh the project-info memory snapshot, or when the snapshot is stale. Trigger phrases: "refresh project info", "/kit:project-info", "update the project memory", "re-pull members/providers/environments", "who's on this project" (when the snapshot is empty/stale), "the project-info file says 'not populated'". Also auto-fire the first time you notice .claude/launch-kit/project-info.md exists but its Members/Providers/Environments sections are still the "_Not populated yet_" placeholder. Do NOT auto-fire for: a one-off "who's a member" question you can answer with a single members_list call (just call it), posting to comms (/kit:comms), or reading code structure (/kit:analyse).
+allowed-tools:
+  - mcp__launch-secure__project_info
+  - mcp__launch-secure__members_list
+  - mcp__launch-secure__environments_list
+  - mcp__launch-secure__tags_list
+  - Read
+  - Write
+  - Bash
+---
+
+# /kit:project-info
+
+Regenerate `.claude/launch-kit/project-info.md` — the **local, git-ignored** snapshot of project facts (members, providers/integrations, environments) that Claude auto-loads every session via a CLAUDE.md `@`-import. `init` wires the file + import + gitignore and writes the identity block; **this skill fills and refreshes the cloud-sourced sections.**
+
+It's a **cache, not a source of truth** — stamp it with the date and treat it as stale-able. Re-run after someone joins/leaves, a provider is connected, or an environment changes.
+
+## When the file/import isn't wired yet
+
+`init` normally creates the file, the `@.claude/launch-kit/project-info.md` import in `CLAUDE.md`, and the `.gitignore` line. If the user never ran `init` (or hand-deleted them), ensure them yourself before writing:
+
+```bash
+# 1. gitignore the snapshot (it can carry member names/emails — never commit it)
+grep -qxF '.claude/launch-kit/project-info.md' .gitignore 2>/dev/null \
+  || printf '\n.claude/launch-kit/project-info.md\n' >> .gitignore
+
+# 2. ensure CLAUDE.md imports it (Claude Code won't auto-load it otherwise)
+grep -qF '@.claude/launch-kit/project-info.md' CLAUDE.md 2>/dev/null \
+  || printf '\n<!-- launch-kit:project-info -->\n@.claude/launch-kit/project-info.md\n<!-- /launch-kit:project-info -->\n' >> CLAUDE.md
+```
+
+Don't duplicate either line — the `grep` guards keep it idempotent.
+
+## Gather (cloud LS — slugs default to the .mcp.json project)
+
+Call these and keep only non-secret reference data:
+1. `mcp__launch-secure__project_info` → project name, counts, **active integration/provider flags**.
+2. `mcp__launch-secure__members_list` → member **name, email, role** (org + project role). Use the full list; note `mentionable`.
+3. `mcp__launch-secure__environments_list` → environment **slugs** + `defaultPullEnvSlug`.
+
+Never write secret **values** — only provider *types*/names, env *slugs*, member identity. If a section legitimately has no data (e.g. no providers connected), write `_None connected._`, not a placeholder.
+
+## Write
+
+Overwrite `.claude/launch-kit/project-info.md` (this skill owns the content; init only seeds it). Preserve the generated-header comment and the `## Identity` block if already present (re-derive Identity from `project_info` if you're regenerating from scratch). Shape:
+
+```markdown
+# Project Info — <projectName>
+
+<!-- launch-kit:generated — local, git-ignored snapshot. NOT a source of truth. -->
+> Snapshot as of <YYYY-MM-DD>. Cache of LaunchSecure facts so Claude doesn't
+> re-query each session. Re-run `/kit:project-info` after team/provider/env changes.
+
+## Identity
+- **Org:** <orgSlug>
+- **Project:** <projectName> (`<projectSlug>`)
+- **Server:** <serverUrl>
+- **Course:** <course>
+- **Repo:** <repositoryUrl or —>
+
+## Members
+| Name | Email | Org role | Project role |
+|---|---|---|---|
+| … | … | … | … |
+
+## Providers / integrations
+- <Category>: <provider> (<connected|manual>)
+  _…or_ `_None connected._`
+
+## Environments
+- `<slug>`<em> — default pull env</em> (mark the one matching defaultPullEnvSlug)
+```
+
+Use the real values from the calls — no placeholders, no invented people (this is *this* project, cite real names/roles). Date the snapshot with today's date from context.
+
+## Output
+
+After writing, print a one-line summary: `project-info refreshed — N members, M providers, K environments — snapshot <date>`. Mention it's git-ignored and loaded into context next session via the CLAUDE.md import.
+
+## Constraints
+
+- **Cache, not truth.** Always date it and remind the user it can drift; this skill is the refresh path.
+- **No secrets.** Provider/env *names and slugs* only — never pull or write secret values (that's `secrets_*`).
+- **Local only.** The file is git-ignored on purpose (member PII). Don't commit it, don't move it out of `.claude/launch-kit/`.
+- **Don't touch unrelated CLAUDE.md content.** Only ensure the single marked import block; never rewrite the user's CLAUDE.md.

package/scaffolds/ls-marketplace/plugins/kit/skills/slides/SKILL.md

@@ -0,0 +1,118 @@
+---
+description: Generate a slide deck (reveal.js presentation) and push it to launch-deck for review or live presenting. Use when the user wants a talk, design walkthrough, RFC pitch, sprint demo, or stakeholder summary as navigable slides — not a single page. Calls deck's rich-html block with framework=reveal; content is markdown slides joined by `---`, with code highlighting and speaker notes.
+when_to_use: |
+  Auto-fire when the user wants a navigable SLIDE PRESENTATION as the deliverable — a talk, pitch, design review walkthrough, RFC, sprint demo, kickoff, or stakeholder summary they'll step through. Trigger phrases: "slides for X", "make a deck / slide deck", "presentation about Y", "present this as slides", "turn this into a talk", "walkthrough deck for the design review", "pitch deck for the RFC", "demo slides for sprint review", "slide summary of Z". Deck is required because the deliverable is a rendered, arrow-key-navigable presentation the reviewer steps through — a flat document or terminal text cannot substitute. Do NOT auto-fire for: a single-screen UI sketch (use /kit:wireframe), an interactive click-through page (use /kit:prototype), a Mermaid flow/sequence/ERD (use /kit:diagram), a long-form repo-backed written document (use /kit:brief), or a plain-text summary the user can read inline in the terminal.
+allowed-tools:
+  - mcp__launch-deck__server_status
+  - mcp__launch-deck__start_server
+  - mcp__launch-deck__deck
+  - mcp__launch-deck__await_feedback
+  - mcp__launch-chart__read_graph
+  - Bash
+---
+
+# /kit:slides
+
+Build a slide presentation and push it to launch-deck as a `reveal.js` deck. The reviewer navigates with arrow keys; code blocks are syntax-highlighted and speaker notes are available in the presenter view. Use for talks, design-review walkthroughs, RFC pitches, sprint demos, kickoffs, and stakeholder summaries — anything where the point is *stepping through* a narrative, not reading one page.
+
+This is the slide-shaped sibling of `/kit:wireframe` (framework=wired) and `/kit:prototype` (framework=raw): same deck push, `framework: "reveal"`.
+
+Parse `$ARGUMENTS`:
+- **description** (required) — the topic/outline, e.g. "design review of the OIDC IdP rollout: problem, phases 1-4, edge gate, rollback". If absent, ask the user. If the user points at a doc/Brief/RFC, read it first and turn it into slides.
+- **--session=<id>** — deck session name. Default `slides-<slugified-description-first-3-words>`.
+- **--feedback** — push in `feedback` mode with `prompt: "Which slides land, and what's missing?"` and call `await_feedback` afterward.
+- **--theme=light|dark** — only set when the deck ONLY makes sense in one mode. Default: omit (deck's sun/moon toggle flips the reveal white/black themes live).
+- **--slides=<n>** — target slide count. Default: as many as the content needs; keep it tight (≈1 idea per slide).
+
+Examples:
+- `/kit:slides design review of the OIDC IdP rollout: problem, phases 1-4, edge gate, rollback`
+- `/kit:slides sprint demo of the deck feedback feed and share links --feedback`
+- `/kit:slides pitch the launch-kit health design (LS-161 first, LS-160 deferred) --slides=8`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` returns running. If not, call `mcp__launch-deck__start_server` first.
+2. If the description references a real doc, RFC, Brief, or module in this repo, pull the source before authoring slides:
+   - For a written doc the user names, Read it and condense — don't invent the content.
+   - For a codebase topic, run `mcp__launch-chart__read_graph(search: <hint>)` so the slides cite real module/file/table names, not guesses. Optional; skip on `--no-chart`.
+
+## Author the slides
+
+Write the deck as **markdown slides joined by `---` on its own line** (one blank line above and below the `---`). The deck renders each chunk as one slide via reveal's markdown plugin. This is the recommended form — only hand-write raw `<section>` HTML if you need nested/vertical slides or custom layout.
+
+```
+# Title slide
+A one-line subtitle
+
+---
+
+## Problem
+
+- Bullet one
+- Bullet two
+
+Note: speaker-only context that won't show on the slide.
+
+---
+
+## How it works
+
+```ts
+// fenced code is syntax-highlighted
+const gate = await edgeAccess(req)
+```
+
+---
+
+## Ask
+
+What we need a decision on.
+```
+
+Authoring rules:
+- **One idea per slide.** If a slide has more than ~6 bullets or two distinct ideas, split it. Lean toward more, lighter slides.
+- **Title slide first, "Ask"/"Next steps" slide last.** Give the deck a clear arc: context → problem → approach → detail → decision/next steps.
+- **Speaker notes via `Note:`.** Put the narration, caveats, and numbers you'd *say* (not show) on a `Note:` line — visible in reveal's presenter view (press `S`), hidden on the slide.
+- **Code blocks are highlighted.** Use fenced blocks with a language (```ts, ```sql, ```bash). For line emphasis use reveal's syntax: ```js [1-3|5] steps through line ranges.
+- **Real names, no placeholders.** Unlike a wireframe/prototype, a slide deck is about *this* work — cite the real modules, tables, ticket IDs, and file paths surfaced in preflight. No "Ada/Lin/Mehmet" filler here.
+- **No secrets or live PII on slides.** Summaries and counts are fine; don't paste credentials, tokens, or real user records.
+- Keep bullets to a phrase, not a sentence — the speaker fills in the rest.
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` (or `"feedback"` if `--feedback` was passed; also set `prompt`)
+- `blocks: [{ type: "rich-html", framework: "reveal", label: <short-title>, content: <markdown-slides>, theme: <theme?> }]`
+
+`framework: "reveal"` means the deck wraps your markdown in a full reveal.js document (CSS, JS, markdown + highlight + notes plugins, theme toggle) — you ship only the slide markdown, not a `<!DOCTYPE html>` doc. Slides split on `\n---\n`; `Note:` lines become speaker notes; fenced code is highlighted.
+
+If `--feedback` was passed, immediately call `mcp__launch-deck__await_feedback` with the same session and surface the user's response back.
+
+## Open in browser
+
+After the push (and after `await_feedback` if `--feedback`), open the per-session URL so the user lands directly on this deck:
+
+```
+open "<deck-url>/#<session>"          # macOS
+xdg-open "<deck-url>/#<session>"      # Linux
+```
+
+`<deck-url>` is the `url` returned by `mcp__launch-deck__server_status` (typically `http://localhost:52829`). The `#<session>` hash deep-links to this exact session — the deck-client picks it up on load and on hashchange. Tell the user: **arrow keys navigate, `S` opens speaker notes, `F` goes fullscreen, `Esc` shows the slide overview.**
+
+## Output
+
+```
+slides pushed — deck session "<session>" — <deck-url>/#<session>
+<N> slides — <M> with code — <K> with speaker notes
+arc: <title> → … → <last slide>
+```
+
+If `--feedback`: also print the feedback comment + any option selections, then ask what to change.
+
+## Constraints
+
+- **Slides, not a page.** If the user wants a single click-through screen, that's `/kit:prototype`; a UI sketch is `/kit:wireframe`; a long-form written doc committed to the repo is `/kit:brief`. This skill produces a navigable deck.
+- **Single block per push.** One deck = one `rich-html`/`reveal` block. Don't split a presentation across multiple deck blocks.
+- **Iterate via re-push.** Re-running with the same `--session` overwrites — that's the iteration loop. Don't accumulate slides-v2, slides-v3 sessions.
+- **Throwaway by default.** The deck lives in launch-deck for review/presenting. If the user wants the content committed to the repo as durable documentation, author it as a `/kit:brief` instead (or in addition).

package/scaffolds/statusline/statusline-base.sh

@@ -0,0 +1,20 @@
+#!/bin/bash
+# launch-kit default base statusline.
+# Scaffolded by `launch-kit statusline activate` ONLY when the user has no
+# statusLine.command of their own — gives the MCP chips a base line to attach
+# to instead of bailing. This is Claude Code's documented canonical example
+# (https://code.claude.com/docs/en/statusline.md, "Build a status line step by
+# step"), used verbatim so we ship the real default, not an invented format.
+# Deactivate restores whatever was here before (nothing, in the scaffold case).
+
+# Read JSON data that Claude Code sends to stdin
+input=$(cat)
+
+# Extract fields using jq
+MODEL=$(echo "$input" | jq -r '.model.display_name')
+DIR=$(echo "$input" | jq -r '.workspace.current_dir')
+# The "// 0" provides a fallback if the field is null
+PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
+
+# Output the status line - ${DIR##*/} extracts just the folder name
+echo "[$MODEL] 📁 ${DIR##*/} | ${PCT}% context"