@launchsecure/launch-kit 0.0.29 → 0.0.30

package/scaffolds/ls-marketplace/plugins/kit/skills/course.md

@@ -0,0 +1,84 @@
+---
+description: Show the currently active LaunchSecure course (server profile) and list the others available in .launch-secure.cred.config. Surfaces which serverUrl/org/project this Claude session is talking to so the user doesn't post local LS comms to prod, or vice versa. Read-only by default; switch is opt-in.
+---
+
+# /kit:course
+
+A "course" is a named LaunchSecure destination — `serverUrl + PAT + orgSlug + projectSlug` — stored under `profiles` in `.launch-secure.cred.config`. The active course drives every MCP call and every `npx launch-pod` invocation. This skill answers two questions: *which course am I on right now*, and *what others are available* — without changing anything unless explicitly told to.
+
+Parse `$ARGUMENTS` — first token is the subcommand:
+
+- (empty) or **status** — one-line: which course is active.
+- **list** — table of every course, active marked with `★`.
+- **switch <name>** — change the active course (rewrites `.launch-secure.cred.config` AND `.mcp.json`'s launch-secure URL). Asks for confirmation.
+- **diff** — show the deltas between two courses (`--a=<name> --b=<name>`).
+
+Examples:
+- `/kit:course`            → "active: prod (acme/launchsecure-v2 @ launchsecure-v2.vercel.app)"
+- `/kit:course list`       → table
+- `/kit:course switch local`
+- `/kit:course diff --a=local --b=prod`
+
+## Preflight
+
+Confirm `.launch-secure.cred.config` exists in the cwd (or in the nearest parent up to 3 levels — `cred-shape.ts`'s lookup convention). If missing, tell the user: `"No .launch-secure.cred.config here. Run \`npx @launchsecure/launch-kit init\` first."`
+
+Read the cred file directly (it's gitignored, lives at the repo root, JSON shape with `active` + `profiles`). Never call out to launch-course CLI from inside the skill for read operations — read the file. Use `launch-course` (Bash) only for `switch` (it owns the MCP rewrite invariant).
+
+## Per-subcommand behavior
+
+### status (default)
+
+Read the cred file. Print one line:
+
+```
+active: <name> (<orgSlug>/<projectSlug> @ <serverUrl>)
+```
+
+If the file is in legacy flat shape (single profile at the top), say so explicitly: `"active: (legacy single-profile shape — no name; first multi-profile op auto-migrates)"`.
+
+### list
+
+```
+courses (3):
+    name        serverUrl                              org/project
+  ★ prod        https://launchsecure-v2.vercel.app     acme/launchsecure-v2
+    staging     https://staging.launchsecure-v2.app    acme/launchsecure-v2
+    local       http://localhost:3000                  acme/launchsecure-v2
+```
+
+Sort: active first, then alphabetical. Column-align with monospace.
+
+### switch
+
+1. Sanity-check `<name>` exists in `profiles`. If not, list available names and stop.
+2. Print the BEFORE → AFTER one-liner:
+   ```
+   switching: prod (acme/launchsecure-v2 @ launchsecure-v2.vercel.app)
+             → local (acme/launchsecure-v2 @ localhost:3000)
+   ```
+3. Ask: `"Continue? (yes / no)"` — wait for `yes`. Per project memory, destructive/sticky changes require explicit confirmation.
+4. On `yes`, run `npx launch-course set <name>` via Bash. This rewrites both `.launch-secure.cred.config` (active pointer) AND `.mcp.json` (the launch-secure URL). Surface the CLI output verbatim.
+5. After switch, remind: `"Restart Claude Code to pick up the new MCP URL (or use \`/mcp reload\` if available)."`
+
+### diff
+
+Resolve `--a` and `--b` from `profiles`. Print a compact diff:
+
+```
+local         →  prod
+serverUrl     http://localhost:3000              →  https://launchsecure-v2.vercel.app
+org           acme                               →  acme
+project       launchsecure-v2                    →  launchsecure-v2
+pat           sha256:abc1…ef                     →  sha256:def0…12
+```
+
+PAT values are hashed (sha256 first 8 of each, last 2 — purely for the user to confirm they differ; never print full PATs). Same row for unchanged values.
+
+## Constraints
+
+- **Read-only by default.** Only `switch` writes; status/list/diff never mutate.
+- **Switch requires confirmation.** Per project memory, never destructive without `yes`.
+- **No PAT exfiltration.** Never print the full PAT value; show short hashes for diff identification only.
+- **Don't bypass launch-course CLI.** The `switch` MCP-rewrite logic is its responsibility — call the CLI; don't reimplement the .mcp.json mutation inside the skill (drift risk).
+- **Surface the active course on every run.** Even on `list`/`diff`, the first or last line shows which course is active so the user is never confused about session scope.

package/scaffolds/ls-marketplace/plugins/kit/skills/debug.md

@@ -0,0 +1,92 @@
+---
+description: Investigate a bug, error message, or unexpected behavior using launch-chart first (structural + variable queries), falling back to grep/Read only when the chart can't answer. When the chart gap is the reason for the fallback, files a feedback comment to LaunchSecure so the gap is monitored and fixed.
+---
+
+# /kit:debug
+
+A guided investigation workflow that defaults to chart-MCP queries and only reaches for grep/Read when the chart can't answer — and when that happens, files a one-line feedback comment in LS so the gap doesn't go unnoticed.
+
+Parse `$ARGUMENTS`:
+- **symptom** (required) — the error message, broken behavior, or question to investigate. Quoted is fine: `/kit:debug "tags don't render on the work-item drawer"`.
+- **--start=<node>** — start the investigation from a specific file/function/table id (skip the search step).
+- **--layer=<id>** — scope chart queries to one layer (ui / api / db / static).
+- **--no-grep-fallback** — refuse the grep fallback entirely (strict MCP-only).
+
+Examples:
+- `/kit:debug tags don't render on the work-item drawer`
+- `/kit:debug "TypeError: Cannot read property 'status' of undefined" --layer=ui`
+- `/kit:debug --start=src/server/comms/build-feed.ts`
+
+## Investigation loop
+
+Run this loop until the user has enough to act, OR until a fallback was filed (then surface the fallback):
+
+### Step 1 — locate the entry point
+
+If `--start` was given, jump to step 2. Otherwise, use chart to find candidate nodes:
+
+1. Extract key terms from the symptom (component name, identifier, error class). Skip noise words.
+2. Call `mcp__launch-chart__read_graph(search: <term>, type: <best-guess-type>, layer: <layer?>)`. If `type` is uncertain, omit it and filter the response by relevance.
+3. If `read_graph` returns 0 candidates, broaden: try without `type`, then without `layer`. Surface the top 3 candidates to the user as ranked options; if the user can pick, jump to step 2 with their pick.
+
+**Chart-gap detection (entry-point search):**
+- If `read_graph` returns 0 candidates AND a quick `grep` confirms the term exists somewhere in source → file a chart-gap report per the protocol below, then proceed via the grep fallback for this query only.
+- If `detect_project_stack` lists a layer (e.g. `api`) but `read_graph(layer:"api")` returns 0 nodes → file a chart-gap report (parser misconfig).
+
+### Step 2 — understand the node
+
+Once the entry point is known, query its structure and behavior:
+
+- **Structural** — `mcp__launch-chart__read_graph(node_id: <id>, hops: 1, include_edges: true)` for what it renders/imports and what depends on it.
+- **Variable / state** — `mcp__launch-chart__inspect_node(node_id: <id>, fields: ["stateVars"])` or `(filter: <key-term>)` for what state it holds, what conditions exist. Per project CLAUDE.md, ALWAYS start with `fields` or `filter` to keep the response small.
+
+Compose a hypothesis from these two reads. Example: "WorkItemDrawer fetches tags via `useWorkItemTags`, which calls `GET /api/work-items/:id/tags` — let's see what that returns."
+
+### Step 3 — follow the trail
+
+Walk the dependency edges toward the suspected cause (API endpoint, DB table, util fn, etc.). At each hop, use `read_graph(node_id, hops:1)` to find the next link. When you hit a leaf or run out of edges, narrate the chain back to the user with file:line refs from the node ids.
+
+### Step 4 — propose, don't fix
+
+End with a one-paragraph diagnosis + 2-3 candidate causes ranked by likelihood. Do NOT propose an edit unless the user asks for one — debug is investigation, not implementation. Suggest the next move: "Want me to read the route handler and confirm?" or "Want `/kit:diagram sequence`-ing the call chain?"
+
+## Grep fallback
+
+Only enter this path when:
+- the chart returned no results AND a chart-gap report was filed, OR
+- the symptom is about a non-TS asset (CSS string, env var, JSON value, comment) — the chart doesn't model these and the gap is expected.
+
+Then use `grep`/`Read` directly. Always tell the user explicitly: `"Chart returned nothing — falling back to grep (filed gap report id: …)"` or `"Symptom is in CSS/JSON, which chart doesn't model — using grep directly (no gap report needed)."`
+
+## Chart-gap protocol (shared)
+
+When the chart MCP returns less than the symptom suggests it should, file ONE feedback comment in the project's Comm Hub via `mcp__launch-secure__communication_write` (cloud LS by default):
+
+```
+resource_type: "feedback"
+title: "launch-chart gap: <one-line>"
+body: |
+  Skill: /kit:debug
+  Symptom: <one-line symptom>
+  Tool:    read_graph(search="…", layer="…", type="…")
+  Returned: 0 nodes
+  Cross-check: grep "<term>" matched <N> files (sample: <path1>, <path2>)
+  Project stack: <detect_project_stack one-liner>
+fields:
+  severity: "low"
+  source: "kit-skill"
+  skill: "debug"
+  tool: "read_graph"
+  args: { search, layer, type }
+  response_summary: { nodes_count: 0, grep_hit_count }
+```
+
+Then continue with the grep fallback for THIS query. Don't file again in the same invocation.
+
+## Constraints
+
+- **Chart-first.** Default to MCP queries; grep only when the chart cannot answer.
+- **One gap report per invocation.** Don't spam comments.
+- **No implementation.** This skill diagnoses; it does not edit. If the user wants the fix, they invoke `/fix:*` or hand the diagnosis back to you in chat.
+- **Cite by node id.** Every claim links to a chart node id (file:line via `inspect_node` lines) so the user can verify.
+- **Surface the fallback verbatim.** When grep is used, the message that grep was used (and why) must appear in the output — silent fallback hides the gap.

package/scaffolds/ls-marketplace/plugins/kit/skills/deploy-check.md

@@ -0,0 +1,160 @@
+---
+description: Production-readiness check for the current branch — typecheck, lint, build, prisma drift, migration safety, env coverage, and recent LS comms. Read-only; reports a punch list of go/no-go signals before a deploy or merge to a deploy-tracked branch. Does NOT deploy.
+---
+
+# /kit:deploy-check
+
+Audit the current branch for production readiness. Bundles every signal a human would manually check before clicking "deploy" or merging to a deploy-tracked branch (per project convention: `master`). Reports a punch list with ✓ / ⚠ / ✗ per check and a single go/no-go verdict.
+
+Parse `$ARGUMENTS`:
+- (empty) — full check on the current branch vs `master` (or repo's default).
+- **--target=<branch>** — compare against a different deploy-tracked branch.
+- **--skip=<check,…>** — comma-separated checks to skip (e.g. `--skip=lint,build`). Use sparingly; surface skipped checks in the report.
+- **--quick** — skip the build (the slowest check). Still runs typecheck, lint, prisma, env, comms.
+- **--json** — emit a machine-readable report (per check: ok, detail, durationMs).
+
+Examples:
+- `/kit:deploy-check`
+- `/kit:deploy-check --quick`
+- `/kit:deploy-check --skip=lint`
+- `/kit:deploy-check --target=staging-mirror --json`
+
+## Preflight
+
+1. Confirm cwd is a git repo (`git rev-parse --is-inside-work-tree`).
+2. Resolve the target branch — `--target=` if given, else default branch (`git symbolic-ref refs/remotes/origin/HEAD --short` → strip `origin/`; fall back to `master`).
+3. Print the scope upfront: `"deploy-check: <current-branch> → <target-branch>"`. The user should never wonder which comparison this is.
+4. Stash check — if `git status --porcelain` shows uncommitted changes, surface this as a `⚠ uncommitted changes in working tree` row at the top of the report. Don't refuse; some workflows want the check to include uncommitted work.
+
+## Checks
+
+Run every check in PARALLEL when possible (typecheck/lint/build are independent and slow). Each check returns `{ name, status: "ok"|"warn"|"fail", detail: <one-line>, artifact?: <path or url> }`.
+
+### 1. branch_freshness
+
+How far behind the target branch is the current branch?
+
+```
+git fetch --quiet origin
+git rev-list --left-right --count <target>...HEAD
+```
+
+- ✓ `0 commits behind target` → fresh
+- ⚠ `1–10 behind`
+- ✗ `>10 behind` → suggest `git merge origin/<target>` or rebase
+
+### 2. typecheck
+
+`npx tsc --noEmit` (or the project's `npm run typecheck` if defined in `package.json` scripts — prefer the script).
+
+- ✓ `0 errors`
+- ✗ `<N> errors` (sample first 3 file:line:message)
+
+### 3. lint
+
+`npm run lint` if defined in `package.json` scripts; else skip with a `⚠ no lint script defined` row.
+
+- ✓ `0 errors`
+- ⚠ `<N> warnings`
+- ✗ `<N> errors`
+
+### 4. build
+
+`npm run build` (uses the project's actual build pipeline so the check matches what Vercel/CI would do). Skip if `--quick` or `--skip=build`.
+
+- ✓ `built in <durationMs>ms`
+- ✗ `build failed` (last 20 lines of stderr as artifact)
+
+Note: this runs the full prod build including prisma generate + migrate deploy. Make sure `DATABASE_URL` is set to a *safe* dev DB before running. If `DATABASE_URL` looks production-y (matches `vercel.app`, `neon.tech`, `rds.amazonaws.com`, etc.), refuse the build step and surface `⚠ build skipped — DATABASE_URL looks production-y (<host>); re-run with a dev DB or pass --skip=build`.
+
+### 5. prisma_drift
+
+Schema vs migrations consistency:
+
+```
+npx prisma migrate diff --from-schema-datasource prisma/schema.prisma --to-migrations prisma/migrations --shadow-database-url <DEV_SHADOW_URL>
+```
+
+The project authors migrations by hand (CLAUDE.md: never `prisma db push` or `migrate dev`). So this diff should be EMPTY — any non-empty result means a model field was added without a corresponding hand-written migration.
+
+- ✓ `schema matches migrations`
+- ✗ `<N> drift detected` — surface the diff body as an artifact; suggest authoring a migration per the project's hand-written SQL convention.
+
+If no `DEV_SHADOW_URL` is available, skip this check with `⚠ prisma_drift skipped — no shadow DB URL` and recommend setting one in `.env.local`.
+
+### 6. migration_safety
+
+Recent migrations on the branch — look at every migration file added since divergence from target:
+
+```
+git diff --name-only <target>...HEAD -- prisma/migrations/
+```
+
+For each new migration, scan the SQL for risk patterns (per project CLAUDE.md migration safety rules):
+
+- ✓ no destructive ops (`DROP COLUMN`, `DROP TABLE`, `ALTER COLUMN ... DROP`, `DELETE FROM` without `WHERE` matching backup) found.
+- ⚠ destructive ops present BUT a sidecar `CREATE TABLE _backup_*` exists in the same file AND an orphan-check (`RAISE EXCEPTION ... orphans remain`) is present.
+- ✗ destructive ops without backup OR without orphan-check OR mixing expand+contract in a single migration.
+
+Each failure cites the exact migration filename + line numbers.
+
+### 7. env_coverage
+
+Compare `.env.example` (or `.env.testing` if it exists) keys against `process.env.*` references in the new code since divergence:
+
+```
+git diff <target>...HEAD -- '*.ts' '*.tsx' | grep -oE 'process\.env\.[A-Z_][A-Z0-9_]+'
+```
+
+- ✓ every referenced env var is documented in `.env.example`
+- ⚠ `<N> new env vars used but missing from .env.example` (list them)
+- ✗ N/A (always a warn, never a hard fail — env docs are advisory)
+
+### 8. recent_comms (LS Comm Hub)
+
+Pull the last 10 comments tagged `release` or `daily_update` via `mcp__launch-secure__communication_read` and surface a one-line: `"<N> release/standup comments in last 7 days — latest: <title> (<author>, <age>)"`. This is informational — it helps the user know if a release note was already drafted or if the team flagged something to ship.
+
+Skip with a `⚠ launch-secure MCP not wired` row if the MCP isn't available; don't fail the whole check.
+
+### 9. recall_health
+
+`mcp__launch-recall__recall_status` — ensures the shadow-git backup is alive so a rollback path exists if the deploy goes sideways. Informational only.
+
+- ✓ `recall alive — last snap <X ago>`
+- ⚠ `recall dead — restart before deploy (\`/kit:recall doctor\` for detail)`
+
+## Report
+
+Render a punch list (plain text, monospace; not markdown table):
+
+```
+deploy-check: implementation → master
+
+  ✓ branch_freshness       0 commits behind master
+  ✓ typecheck              0 errors (3.2s)
+  ⚠ lint                   12 warnings (no errors)
+  ✓ build                  built in 47s
+  ✓ prisma_drift           schema matches migrations
+  ✗ migration_safety       1 destructive op without backup
+                           → prisma/migrations/2026_05_25_drop_legacy_thread/migration.sql:14 (DROP COLUMN legacyThreadId, no _backup_* sidecar)
+  ⚠ env_coverage           2 new env vars missing from .env.example: FEED_BACKEND_URL, FEED_TIMEOUT_MS
+  ✓ recent_comms           1 release comment in last 7 days — "Comm Hub channels rollout" (prajyot, 2d ago)
+  ✓ recall_health          alive — last snap 4m ago
+
+verdict: NO-GO — 1 hard fail (migration_safety).
+next: author a backup table + orphan check in the listed migration, then re-run /kit:deploy-check.
+```
+
+Verdict rules:
+- Any ✗ → NO-GO with the failing check(s) listed.
+- All ✓ + ⚠ only → GO WITH CAVEATS, list the warnings.
+- All ✓ → GO.
+
+## Constraints
+
+- **Read-only.** Never deploy, never push, never auto-fix.
+- **Parallel checks.** Run independent checks concurrently (Bash run_in_background) — sequential bloats the wait time past usefulness.
+- **No silent skips.** Every skipped check appears in the report with a reason.
+- **DB-safe.** Refuse to run `build` against a production-looking DATABASE_URL — the build runs `prisma migrate deploy` against it.
+- **Honest about scope.** This check is what a human would do manually; it is NOT a guarantee. Surface false-negatives readers: `"This check doesn't run e2e tests, doesn't validate runtime config, doesn't sniff for secrets in commits — those are separate skills."`
+- **Use launch-chart only for nice-to-have context (e.g. blast radius of a migration), not for the gate.** The gate is git+npm+prisma+MCP-LS; chart is optional.

package/scaffolds/ls-marketplace/plugins/kit/skills/diagram.md

@@ -0,0 +1,134 @@
+---
+description: Render a Mermaid diagram (flowchart, sequence, ERD, state, gantt) via launch-deck. For ERDs, auto-derives tables and relations from launch-chart's db layer so the diagram matches the real schema. Files a chart-gap feedback comment to LS if the db layer is missing or empty.
+---
+
+# /kit:diagram
+
+Push a Mermaid diagram to launch-deck. Five flavors:
+
+- **flowchart** — boxes-and-arrows for any process
+- **sequence** — request/response timing between actors
+- **erd** — entity-relationship diagram. Auto-pulled from chart `db` layer unless the user provides their own DSL.
+- **state** — state machine
+- **gantt** — timeline
+
+Parse `$ARGUMENTS`:
+- **kind** (required) — `flowchart` | `sequence` | `erd` | `state` | `gantt`. If absent, ask.
+- **subject** (required for non-erd) — what to diagram, e.g. "user login flow" or "OAuth handshake".
+- **--scope=<filter>** — for ERDs, limit to one module or table set (e.g. `--scope=auth` or `--scope=User,Org,Membership`). Default: all tables.
+- **--session=<id>** — deck session name. Default `diagram-<kind>-<subject-slug>`.
+- **--dsl=<raw-mermaid>** — bypass auto-generation; push the user's DSL verbatim.
+- **--feedback** — push in feedback mode and await response.
+
+Examples:
+- `/kit:diagram flowchart user login flow`
+- `/kit:diagram sequence OAuth handshake between client, gateway, idp`
+- `/kit:diagram erd --scope=work-items`
+- `/kit:diagram erd` → full project ERD
+- `/kit:diagram state work-item lifecycle: backlog → todo → in-progress → done`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` is running; start if not.
+2. For `erd`: confirm `mcp__launch-chart__chart_server_status` is up, then call `mcp__launch-chart__detect_project_stack` and check `db` is in the layers list.
+
+## Build the DSL
+
+### flowchart / sequence / state / gantt
+
+Translate the subject into Mermaid DSL based on what the user described. For sequence, infer actors from the subject (client/server/db are common defaults). Add concise labels — don't overload with prose.
+
+Example flowchart skeleton:
+
+```mermaid
+flowchart TD
+  Start([User opens app]) --> Auth{Session valid?}
+  Auth -- yes --> Home[Home]
+  Auth -- no --> Login[Login form]
+  Login -- success --> Home
+```
+
+If the user passed `--dsl=…`, skip generation — use their DSL.
+
+### erd
+
+Query the db layer to derive entities and edges:
+
+1. `mcp__launch-chart__read_graph(layer: "db", type: "table"[, module: <scope>])` — gets every table node.
+2. For each table, `mcp__launch-chart__inspect_node(node_id: <id>, fields: ["columns", "relations"])` to get fields and FK relations.
+3. Render Mermaid `erDiagram` DSL:
+
+```mermaid
+erDiagram
+  USER ||--o{ WORK_ITEM : owns
+  USER {
+    string id PK
+    string email
+    datetime createdAt
+  }
+  WORK_ITEM {
+    string id PK
+    string userId FK
+    string title
+    enum type
+  }
+```
+
+Rules:
+- Use `||--o{` for 1:N FK relations, `}o--o{` for many-to-many join tables.
+- Include PK + FK markers; include enum/scalar type for the first ~8 columns per table; truncate the rest with a `… (N more)` comment.
+- Cap at 25 tables to keep the diagram readable. If the project has more than 25 in scope, ask the user to narrow with `--scope=`.
+
+**Chart-gap detection** — file a feedback comment per the protocol below before stopping if:
+- the db layer is missing from `detect_project_stack`
+- `read_graph(layer: "db")` returns 0 nodes
+- the chart shows tables but `inspect_node` returns no `columns` (parser misconfiguration)
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` or `"feedback"` (+ `prompt: "Does this match the schema you expected?"` for ERDs)
+- `blocks: [{ type: "mermaid", label: <kind>-<subject>, content: <mermaid-dsl> }]`
+
+If `--feedback`, call `await_feedback` and surface the response.
+
+## Output
+
+```
+diagram pushed — deck session "<session>" — http://localhost:52829/?session=<session>
+kind: <kind>
+nodes: <N>  edges: <M>
+```
+
+For ERDs add `tables: <N>  relations: <M>  scope: <scope or "all">`.
+
+## Chart-gap protocol (shared)
+
+When the chart MCP returns less data than expected (db layer missing, 0 tables, empty columns), file ONE feedback comment in the project's Comm Hub via `mcp__launch-secure__communication_write` (cloud LS, not local) before stopping:
+
+```
+resource_type: "feedback"
+title: "launch-chart gap: <one-line>"
+body: |
+  Skill: /kit:diagram
+  Tool:  read_graph(layer="db", …) / inspect_node(...)
+  Returned: <tables_count> tables, <relations_count> relations
+  Expected: db layer present per detect_project_stack
+  Project stack: <one-line summary>
+fields:
+  severity: "low"
+  source: "kit-skill"
+  skill: "diagram"
+  tool: "read_graph"
+  response_summary: { layer, tables_count, error }
+```
+
+Then fall back: render a `flowchart` placeholder explaining "DB layer not available — re-run `npx launch-chart generate_graph` then retry" instead of the ERD.
+
+## Constraints
+
+- **MCP-first for ERDs.** Never grep `prisma/schema.prisma` to build the DSL — the chart has the parsed model.
+- **Cap entities at 25.** Past that, Mermaid wraps unreadably; ask the user to narrow scope.
+- **Mermaid only.** This skill does not draw raster images — Mermaid DSL is the deliverable.
+- **One block per push.**

package/scaffolds/ls-marketplace/plugins/kit/skills/orbit.md

@@ -0,0 +1,87 @@
+---
+description: Create an isolated worktree, run pre-merge gates, or merge an orbit into its target — using launch-orbit MCP tools with launch-chart layer detection in the pre-flight. Encodes the project's orbit standards (database fork by profile, gate enforcement, post-merge cleanup) so every orbit gets created and merged the same way.
+---
+
+# /kit:orbit
+
+Drive a launch-orbit worktree through its lifecycle: create → work → check_mergeable → merge → drop. Wraps the MCP tools with sensible defaults and a layer-aware pre-flight so the operator doesn't forget the project's conventions.
+
+Parse `$ARGUMENTS` — first token is the subcommand:
+
+- **create &lt;branch&gt;** — `[--base=<ref>] [--profile=<name>]` — fork resources per `orbit.json`, return path + envFile.
+- **list** — list every orbit registered on this machine.
+- **switch &lt;branch&gt;** — print the path/env for an existing orbit (no shell mutation).
+- **doctor** — surface registry inconsistencies.
+- **check &lt;branch&gt; --target=&lt;target-branch&gt;** — run pre-merge gates WITHOUT merging.
+- **merge &lt;branch&gt; --target=&lt;target-branch&gt;** — `[--cleanup=full|none] [--skip-gate=<id>,…]` — run gates + merge.
+- **drop &lt;branch&gt;** — `[--no-backup]` — tear down (backup, drop DB, remove worktree, deregister).
+
+Examples:
+- `/kit:orbit create feat-channel-rename --profile=fe`
+- `/kit:orbit check feat-channel-rename --target=implementation`
+- `/kit:orbit merge feat-channel-rename --target=implementation`
+- `/kit:orbit doctor`
+
+## Preflight (runs on create / check / merge)
+
+1. Confirm `mcp__launch-orbit__orbit_doctor` returns no critical inconsistencies for THIS project. If it does, surface them and stop — the operator probably wants `/kit:orbit drop <stale-branch>` first.
+2. Confirm `orbit.json` exists at the repo root. If missing, tell the user to add one (point at the orbit docs) and stop.
+3. Run `mcp__launch-chart__detect_project_stack` and print the detected layers as part of the pre-flight log. This is the project's "what's in scope" surface — surface it before any branch op so the operator sees if the chart misses a layer that orbit.json's gates reference (e.g. orbit.json's build-lint gate runs against the api layer but chart doesn't see api).
+4. For **merge**: confirm `--target=` is set. Default is NOT `master` — explicit target only.
+
+## Per-subcommand behavior
+
+### create
+
+1. `mcp__launch-orbit__orbit_create` with `branch`, `baseRef` (if `--base`), `profile` (if `--profile`).
+2. On success, surface the returned `nextAction` (`cd <path>`) verbatim and the `envFile` path. Don't auto-cd — the operator's shell is theirs to drive.
+3. Remind: in the new worktree, `npx launch-kit refresh` will rewire MCPs against the worktree's `.launch-secure.cred.config` symlink if needed.
+
+### list
+
+`mcp__launch-orbit__orbit_list` → one row per orbit: `slug  branch  age  path  resources`.
+
+### switch
+
+`mcp__launch-orbit__orbit_switch(branch)` → print `cd <path>` + `envFile`. Don't run cd.
+
+### doctor
+
+`mcp__launch-orbit__orbit_doctor` → list every issue with a one-line fix (e.g. `orphan-registration` → `/kit:orbit drop <branch>`).
+
+### check
+
+`mcp__launch-orbit__orbit_check_mergeable(branch, target)` → render the gate report:
+
+```
+orbit feat-channel-rename → implementation
+  ✓ builtin/mergeability           (no textual conflicts)
+  ✗ builtin/build-lint             (tsc: 3 errors, see <artifact>)
+  ✓ launchsecure/migration-safety  (no destructive migrations)
+
+result: BLOCKED — fix build-lint then retry.
+```
+
+### merge
+
+1. Run `check` first (same report). If `passed: false`, stop with the report — don't attempt the merge.
+2. If `passed: true`, call `mcp__launch-orbit__orbit_merge(branch, target, cleanup, skipGates)` and surface the result.
+3. Default `cleanup: "full"` (orbit is dropped post-merge after pg_dump). The operator must pass `--cleanup=none` to keep the orbit around.
+4. After a successful merge, recommend `/kit:standup` to surface the change in the next standup, and `/kit:diagram` if it touched the schema.
+
+### drop
+
+`mcp__launch-orbit__orbit_drop(branch, backup: !args.noBackup)` → idempotent. Surface `backups[]` paths.
+
+## Conventions encoded here
+
+- **No bare `--target=master`.** Default merge target is `implementation` per project CLAUDE.md ("implementation branch is parent for all impl branches"). If the operator types `--target=master`, double-check by asking once.
+- **No `--skip-gate` without a reason in the next message.** Surface a banner: `"Skipping gates: <ids>. Reason?"` — let the operator answer in chat; do NOT proceed silently.
+- **Always run `check` before `merge`.** The skill enforces this — even if the operator runs `merge` directly, the skill runs `check` first.
+- **Layer awareness.** Pre-flight always prints `detect_project_stack` layers so the operator sees parity (or absence) between chart layers and orbit gate scope.
+
+## Constraints
+
+- **MCP-first.** Never shell out to `git worktree`, `git merge`, `pg_dump` directly — orbit's tools own these.
+- **Idempotent.** All subcommands are safe to retry. Drop especially — it handles partial-state gracefully.
+- **Surface, don't hide.** If a gate fails, print the artifact path; if the doctor finds inconsistency, print the exact slug.

package/scaffolds/ls-marketplace/plugins/kit/skills/prototype.md

@@ -0,0 +1,90 @@
+---
+description: Generate a working HTML/JS prototype page and push it to launch-deck for click-through review. Use to validate behavior — flow, transitions, interactions — before any framework code is touched. Calls deck's rich-html block with framework=raw; supports CDN scripts, animations, real DOM events.
+---
+
+# /kit:prototype
+
+Build a self-contained, interactive HTML page (HTML + CSS + JS, optional CDN scripts) and push it to launch-deck. Unlike `/kit:wireframe`, this is a *working* prototype: the user can click, type, navigate fake routes, see transitions — the goal is to test behavior cheaply.
+
+Parse `$ARGUMENTS`:
+- **description** (required) — what the prototype should demonstrate, e.g. "drag-to-reorder kanban with optimistic update and rollback on error".
+- **--session=<id>** — deck session name. Default `proto-<slugified-description-first-3-words>`.
+- **--feedback** — push in `feedback` mode with `prompt: "Did this match the interaction you had in mind?"` and call `await_feedback`.
+- **--cdn=tailwind|alpine|htmx|react|vue|none** — comma-separated CDN(s) to include. Default `tailwind` for styling. `none` for pure handwritten CSS.
+- **--theme=light|dark** — only when the prototype demands one mode (e.g. a dark-mode-only design).
+
+Examples:
+- `/kit:prototype drag-to-reorder kanban with optimistic update`
+- `/kit:prototype keyboard shortcut palette with fuzzy search --cdn=tailwind,alpine`
+- `/kit:prototype landing page hero with parallax scroll --feedback`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` is running. Start if not.
+2. If the description references real entities/pages in this repo, run `mcp__launch-chart__read_graph(search: <hint>)` to pull the shape — so the prototype mirrors actual data field names. Optional; skip on first iteration to keep the loop fast.
+
+## Build the page
+
+Generate a complete `<!DOCTYPE html>` document. Layout:
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title><short title></title>
+  <!-- CDNs (per --cdn flag) -->
+  <script src="https://cdn.tailwindcss.com"></script>
+  <script defer src="https://unpkg.com/alpinejs"></script>
+  <style>
+    /* page-specific styles */
+  </style>
+</head>
+<body class="…">
+  <!-- the prototype -->
+  <script>
+    // event handlers, state, fake data
+  </script>
+</body>
+</html>
+```
+
+CDN catalog (use only what's requested):
+- **tailwind** — `<script src="https://cdn.tailwindcss.com"></script>`
+- **alpine** — `<script defer src="https://unpkg.com/alpinejs"></script>` for `x-data` reactivity
+- **htmx** — `<script src="https://unpkg.com/htmx.org"></script>` for fake server swaps
+- **react** — `<script crossorigin src="https://unpkg.com/react/umd/react.production.min.js"></script>` + `react-dom` + Babel CDN if JSX
+- **vue** — `<script src="https://unpkg.com/vue@3/dist/vue.global.prod.js"></script>`
+
+Design rules:
+- **Fake the backend.** Use in-memory arrays, `setTimeout` to simulate latency, `Math.random() < 0.1` to simulate intermittent failures (for testing rollback flows).
+- **No real PII or secrets.** Use placeholder names ("Ada", "Lin", "Mehmet"), placeholder copy, never a real user from this project.
+- **Show the interaction explicitly.** If the prototype's point is drag-to-reorder, make the drag affordance OBVIOUS (cursor change, hover scale, snap line). If the point is optimistic update + rollback, force a visible failure within ~5 clicks so the reviewer experiences it.
+- **One screen unless the user asks for multi-screen.** Multi-screen prototypes use a fake router (`window.history.pushState` + a click handler) — don't pull in `react-router`.
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` or `"feedback"` (+ `prompt`)
+- `blocks: [{ type: "rich-html", framework: "raw", label: <short-title>, content: <full-doctype-html>, theme: <theme?> }]`
+
+`framework: "raw"` means the deck does NOT wrap your content — what you ship IS the page. That's why the full `<!DOCTYPE html>` doctype is required.
+
+If `--feedback`, call `mcp__launch-deck__await_feedback` afterward and surface the response.
+
+## Output
+
+```
+prototype pushed — deck session "<session>" — http://localhost:52829/?session=<session>
+size: <N> KB markup, <M> CDN scripts, <K> inline event handlers
+demonstrates: <one-line>
+```
+
+## Constraints
+
+- **Self-contained.** No external API calls, no auth flows, no real LS endpoints. Everything in one HTML file.
+- **One block per push.** Multi-block prototypes belong as separate sessions.
+- **Iterate via re-push.** Same `--session` overwrites — that's the loop. Don't accumulate prototype-v2, prototype-v3 sessions.
+- **No production-ready output.** If the user is happy with the prototype and wants to "turn it into the real thing," that's a separate `/fe:*` workflow — this skill is throw-away to validate behavior.