@launchsecure/launch-kit 0.0.34 → 0.0.35

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@launchsecure/launch-kit",
3
- "version": "0.0.34",
3
+ "version": "0.0.35",
4
4
  "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.",
5
5
  "license": "MIT",
6
6
  "author": "LaunchSecure - AutomateWithUs",
@@ -56,25 +56,8 @@
56
56
  "launch-orbit": "./dist/server/orbit-entry.js",
57
57
  "launch-course": "./dist/server/course-entry.js",
58
58
  "launch-beacon": "./dist/server/beacon-monitor-entry.js",
59
- "launch-rover": "./dist/server/rover-entry.js"
60
- },
61
- "scripts": {
62
- "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
63
- "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
64
- "test:beacon": "vitest run --config vite.beacon.config.ts",
65
- "test:radar": "vitest run --config vite.radar.config.ts",
66
- "test:chart": "vitest run --config vite.chart.test.config.ts",
67
- "build:deck-client": "vite build --config vite.deck.config.ts",
68
- "build:council-client": "vite build --config vite.council.config.ts",
69
- "build:client": "vite build",
70
- "build:chart-client": "vite build --config vite.chart.config.ts",
71
- "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 --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",
72
- "dev:client": "vite",
73
- "dev:deck-serve": "cd ../.. && tsx watch packages/cli/src/server/deck-mcp-entry.ts serve",
74
- "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
75
- "dev:server": "pnpm build:server && node dist/server/cli.js",
76
- "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\"",
77
- "prepublishOnly": "pnpm build"
59
+ "launch-rover": "./dist/server/rover-entry.js",
60
+ "launch-bot": "./dist/server/launch-bot-entry.js"
78
61
  },
79
62
  "files": [
80
63
  "dist",
@@ -96,8 +79,6 @@
96
79
  "ws": "^8.18.0"
97
80
  },
98
81
  "devDependencies": {
99
- "@launchsecure/claude-code-web": "workspace:*",
100
- "@launchsecure/ui": "workspace:*",
101
82
  "@types/node": "^20.0.0",
102
83
  "@types/pg": "^8.11.10",
103
84
  "@types/react": "^18.3.12",
@@ -121,6 +102,25 @@
121
102
  "react-router-dom": "^6.28.0",
122
103
  "tailwindcss": "^3.4.19",
123
104
  "vite": "^5.4.11",
124
- "vitest": "^1.6.0"
105
+ "vitest": "^1.6.0",
106
+ "@launchsecure/claude-code-web": "0.0.1",
107
+ "@launchsecure/ui": "0.0.1"
108
+ },
109
+ "scripts": {
110
+ "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
111
+ "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
112
+ "test:beacon": "vitest run --config vite.beacon.config.ts",
113
+ "test:radar": "vitest run --config vite.radar.config.ts",
114
+ "test:chart": "vitest run --config vite.chart.test.config.ts",
115
+ "build:deck-client": "vite build --config vite.deck.config.ts",
116
+ "build:council-client": "vite build --config vite.council.config.ts",
117
+ "build:client": "vite build",
118
+ "build:chart-client": "vite build --config vite.chart.config.ts",
119
+ "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",
120
+ "dev:client": "vite",
121
+ "dev:deck-serve": "cd ../.. && tsx watch packages/cli/src/server/deck-mcp-entry.ts serve",
122
+ "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
123
+ "dev:server": "pnpm build:server && node dist/server/cli.js",
124
+ "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\""
125
125
  }
126
- }
126
+ }
@@ -1,38 +1,55 @@
1
1
  ---
2
- description: Create or update a repo-backed Brief — a long-form idea document committed as a markdown file under doc/ideas/. NOT a Comm Hub / CapCom comment. Use to capture an idea in the repo before promoting it to an Epic.
2
+ description: Create or update a repo-backed Brief — a long-form document committed as a markdown file under doc/<category>/. The server syncs it to a Comm Hub comment; you don't post it yourself. Use to capture a feature, architecture decision, requirement, or playbook in the repo.
3
3
  ---
4
4
 
5
5
  # /kit:brief
6
6
 
7
- A **Brief** is a repo-backed idea document: a long-form description of a problem/opportunity written as a **markdown file committed to the repo** under `doc/ideas/<slug>.md`. It is the structured alternative to a free-form thought when the idea has enough shape to write down. Briefs get promoted to Epics on the Roadmap once they're DECIDED.
7
+ A **Brief** is a structured long-form document that lives **both** as a markdown file in the repo at `doc/<category>/<slug>.md` **and** as a comment in the LaunchSecure Comm Hub. You write the file; the LS server's file-backed sync materializes the matching Comm Hub comment (favoring server file convergence). See `doc/features/briefs.md`, `doc/playbook/runbooks/write-a-brief.md`, and `architecture/systems/briefs-discovery.md`.
8
8
 
9
- **A Brief is a FILE, not a comment.** Do NOT post Briefs to the LaunchSecure Comm Hub / CapCom via `communication_write`. Briefs live in the repo and travel through git like any other source artefact. (An earlier version of this skill posted Briefs as Comm Hub comments that was wrong; Briefs are file commits.)
9
+ **You write the file, the server does the sync.** Do NOT call `communication_write` / `communication_update` yourself — the brief becomes a Comm Hub comment automatically via the `discussion` handler once the file lands on the default branch (stamped with the category's `docCategory`, icon, and color). The only allowed Comm Hub touch from this skill is reading a `--from` discussion seed, and that's read-only.
10
+
11
+ ## Categories
12
+
13
+ A Brief is **category-scoped** — the category determines its folder, icon, color, and where readers find it. Pick the one matching the question the reader is asking:
14
+
15
+ | Reader is asking… | Category | Folder |
16
+ |---|---|---|
17
+ | "What are we building / what does LS offer?" | `features` | `doc/features/` |
18
+ | "How does this system work / why built this way?" | `architecture` | `doc/architecture/` |
19
+ | "What rule must I follow?" | `requirement` | `doc/requirement/` |
20
+ | "How do I do X?" | `playbook` | `doc/playbook/` |
21
+ | "Something happened, I want to remember" | `incident` | `doc/incident/` |
22
+ | "Half-formed personal thought" | `ideas` | `doc/ideas/` (personal — see below) |
23
+
24
+ `features`, `architecture`, `requirement`, `playbook`, `shipping-logs` are framework defaults; `ideas` and `incident` are this project's custom categories (`.launch-secure.config`). Other projects may differ — read `.launch-secure.config` `docCategories[]` if unsure. **Do not default to `ideas`** — that's the personal-scratch category, not a dumping ground for real briefs. Shipping-log briefs are written by `/kit:ship`, not this skill.
10
25
 
11
26
  Parse `$ARGUMENTS`:
12
27
  - **subcommand** (required) — `new` | `update` | `list` | `show`.
13
- - For **new**: `<title>` (required), `--from=discussion:<id>` to seed body from an existing discussion thread, `--dir=<path>` to override the default `doc/ideas/` location.
28
+ - For **new**: `<title>` (required), `--category=<name>` (the category from the table; if omitted, infer from the title/intent and confirm before writing), `--from=discussion:<id>` to seed body from an existing discussion thread, `--dir=<path>` to override the resolved folder.
14
29
  - For **update**: `<slug-or-path>` and either a body description (re-generates body) or `--append=<text>` to add a section.
15
- - For **list**: `[--dir=<path>]` defaults to listing `doc/ideas/`.
30
+ - For **list**: `[--category=<name>]` to filter to one category, else lists briefs across all category folders. `[--dir=<path>]` to scan a specific dir.
16
31
  - For **show**: `<slug-or-path>`.
17
32
 
18
33
  Examples:
19
- - `/kit:brief new "Channels for Comm Hub"`
20
- - `/kit:brief new "Roadmap nav" --from=discussion:cmt_abc123`
34
+ - `/kit:brief new "Comm Hub channels" --category=features`
35
+ - `/kit:brief new "Roadmap nav" --from=discussion:cmt_abc123 --category=architecture`
21
36
  - `/kit:brief list`
37
+ - `/kit:brief list --category=requirement`
22
38
  - `/kit:brief show launch-watch`
23
- - `/kit:brief update launch-watch --append="Resolved: use the Slack metaphor not Teams."`
39
+ - `/kit:brief update comm-hub-channels --append="Resolved: use the Slack metaphor not Teams."`
24
40
 
25
41
  ## Location
26
42
 
27
- - **Default directory**: `doc/ideas/` at the repo root.
43
+ - **Folder**: `doc/<category>/` at the repo root, where `<category>` is resolved from `--category` (or inferred + confirmed).
28
44
  - **Filename**: `<slug>.md`, where the slug is the kebab-cased title (e.g. "launch-watch — unified monitor" → `launch-watch.md`; keep it short — derive from the leading words, drop the subtitle after an em-dash).
29
- - Override with `--dir=<path>` only if the user asks.
45
+ - Override the folder with `--dir=<path>` only if the user asks.
30
46
 
31
47
  ## Preflight
32
48
 
33
49
  1. Resolve the repo root (the working directory is the repo root in this project).
34
- 2. For **new**, check `doc/ideas/<slug>.md` does not already exist. If it does, surface it and ask whether to `update` instead — do NOT overwrite silently.
35
- 3. No MCP, no network, no Comm Hub calls. This skill only touches the filesystem + git.
50
+ 2. Resolve the category (from `--category`, or infer from the title and confirm with the user). Map it to `doc/<category>/`.
51
+ 3. For **new**, check `doc/<category>/<slug>.md` does not already exist. If it does, surface it and ask whether to `update` instead — do NOT overwrite silently. Also check the slug isn't already used under a *different* category before creating a duplicate.
52
+ 4. No `communication_write`. This skill writes the filesystem (+ optionally reads a `--from` seed); the server handles the Comm Hub side.
36
53
 
37
54
  ## Body template
38
55
 
@@ -74,31 +91,45 @@ When generating a NEW brief, write this skeleton as the file contents (plain mar
74
91
 
75
92
  ### new
76
93
 
77
- 1. Build the body from the template + the user's description (or the `--from=discussion:<id>` seed — fetch via `mcp__launch-secure__communication_read` and weave the relevant points into Problem / Proposed-direction; reading a seed discussion is fine, but the Brief itself is still written to a file, never posted back).
78
- 2. Use launch-chart (`read_graph`, `grep_nodes`) to populate the References section with real code paths don't invent them.
79
- 3. **Write the file** to `doc/ideas/<slug>.md` with the Write tool.
80
- 4. Print the path written. Do NOT commit or push unless the user explicitly asks — leave it as a working-tree change for them to review and commit.
94
+ 1. Resolve the category and folder (see Preflight).
95
+ 2. Build the body from the template + the user's description (or the `--from=discussion:<id>` seed — fetch via `mcp__launch-secure__communication_read` and weave the relevant points into Problem / Proposed-direction; reading a seed discussion is fine, but the Brief itself is still written as a file, never posted back).
96
+ 3. Use launch-chart (`read_graph`, `grep_nodes`) to populate the References section with real code paths — don't invent them.
97
+ 4. **Write the file** to `doc/<category>/<slug>.md` with the Write tool.
98
+ 5. Print the path written and remind the user it materializes as a Comm Hub comment on the next default-branch push. Do NOT commit or push unless the user explicitly asks — leave it as a working-tree change for them to review and commit.
81
99
 
82
100
  ### update
83
101
 
84
- 1. Resolve `<slug-or-path>` to a file under `doc/ideas/` (or the `--dir` override). If nothing matches, list candidates and stop.
85
- 2. If `--append=<text>`, Read the file, append the text under a `## Update <ISO-date>` heading, and Write it back.
102
+ 1. Resolve `<slug-or-path>` with `node "$CLAUDE_PLUGIN_ROOT/skills/brief/briefs.mjs" show <slug>` (it prints the resolved path on its `── <path> ──` header, or exits non-zero with candidates / an ambiguity list). If nothing matches, surface the candidates and stop; if ambiguous, ask which category.
103
+ 2. If `--append=<text>`, Read the resolved file, append the text under a `## Update <ISO-date>` heading, and Write it back.
86
104
  3. If a fresh description was passed, regenerate the body from the template + new description, show the user the diff briefly, then Write it back on confirmation.
87
105
 
88
106
  ### list
89
107
 
90
- List `doc/ideas/*.md` (or `--dir`). Render one line per brief: `slug status title` read each file's `# Title` and `**Status**:` line to fill those columns.
108
+ Run the bundled scannerdo NOT open and parse the brief files yourself:
109
+
110
+ ```
111
+ node "$CLAUDE_PLUGIN_ROOT/skills/brief/briefs.mjs" list [category]
112
+ ```
113
+
114
+ It walks every `doc/<category>/` folder once and prints an aligned `CATEGORY SLUG STATUS TITLE` table (pass a category to filter). Surface its output as-is; only read individual files if the user then asks to `show` one.
91
115
 
92
116
  ### show
93
117
 
94
- Read the file and print its contents as-is, no transformation.
118
+ Run the bundled scanner — it resolves the slug across all category folders and prints the file with a `── <path> ──` header:
119
+
120
+ ```
121
+ node "$CLAUDE_PLUGIN_ROOT/skills/brief/briefs.mjs" show <slug-or-path>
122
+ ```
123
+
124
+ Exit 1 = no match (it prints near-matches), exit 2 = ambiguous across categories (it lists them — re-run with the full path). Don't hand-glob `doc/` for the file.
95
125
 
96
126
  ## Constraints
97
127
 
98
- - **A Brief is a file, never a Comm Hub comment.** Do NOT call `communication_write` / `communication_update` to create or store a Brief. Reading a `--from` discussion seed is the only allowed Comm Hub touch, and it's read-only.
128
+ - **You write a file; the server creates the comment.** Do NOT call `communication_write` / `communication_update`. Reading a `--from` discussion seed is the only allowed Comm Hub touch, and it's read-only.
129
+ - **Pick the right category.** The folder, icon, and color all follow from it. Don't default to `ideas`.
99
130
  - **Plain markdown.** No HTML, no emojis unless the user wrote them.
100
131
  - **One brief, one file.** Don't fragment a brief across multiple files — append via `--append` to keep the document continuous.
101
132
  - **Don't commit or push on your own.** Write the file to the working tree and stop; committing/pushing is the user's call (per project conventions on no unauthorized pushes).
102
- - **`doc/ideas/` is the user's personal scratch.** Write the brief the user asked for, but do NOT reorganize, reclassify, or migrate other files in that directory. Promotion out of `doc/ideas/` is user-driven only.
133
+ - **`doc/ideas/` is the user's personal scratch.** Write an `ideas` brief there only when the user explicitly asks for one, and do NOT reorganize, reclassify, or migrate other files in that directory. Promotion out of `doc/ideas/` is user-driven only.
103
134
  - **Cite real code.** Use launch-chart node ids in the References section — don't invent file paths.
104
135
  - **Don't auto-promote to Epic.** A Brief → Epic is a deliberate human action. Surface a hint at the end: "When DECIDED, promote this to an Epic on the Roadmap."
@@ -0,0 +1,152 @@
1
+ #!/usr/bin/env node
2
+ // briefs.mjs — list/show repo-backed Briefs without the agent reading every file.
3
+ //
4
+ // A Brief is a markdown file at doc/<category>/<slug>.md (see the /kit:brief
5
+ // SKILL.md). This script scans the doc/ tree once and emits structured output so
6
+ // the skill never has to open + parse N files itself.
7
+ //
8
+ // Usage (run from the repo root — process.cwd() must contain doc/):
9
+ // node briefs.mjs list [category] # table: CATEGORY SLUG STATUS TITLE
10
+ // node briefs.mjs show <slug-or-path> # print one brief's contents
11
+ //
12
+ // Exit codes: 0 ok · 1 not found · 2 ambiguous · 3 usage error.
13
+
14
+ import { readFileSync, readdirSync, existsSync, statSync } from 'node:fs';
15
+ import { join, relative, basename, sep } from 'node:path';
16
+
17
+ const DOC_ROOT = join(process.cwd(), 'doc');
18
+
19
+ /** Recursively collect every *.md under doc/, tagged with its top-level category. */
20
+ function collectBriefs(filterCategory) {
21
+ if (!existsSync(DOC_ROOT)) {
22
+ return { error: `no doc/ directory at ${DOC_ROOT}` };
23
+ }
24
+ const out = [];
25
+ const walk = (dir) => {
26
+ for (const entry of readdirSync(dir, { withFileTypes: true })) {
27
+ const full = join(dir, entry.name);
28
+ if (entry.isDirectory()) {
29
+ walk(full);
30
+ } else if (entry.isFile() && entry.name.endsWith('.md')) {
31
+ const rel = relative(DOC_ROOT, full); // e.g. features/foo.md, playbook/runbooks/bar.md
32
+ const category = rel.split(sep)[0];
33
+ if (filterCategory && category !== filterCategory) continue;
34
+ out.push({ category, slug: basename(entry.name, '.md'), rel, full });
35
+ }
36
+ }
37
+ };
38
+ walk(DOC_ROOT);
39
+ out.sort((a, b) => a.category.localeCompare(b.category) || a.slug.localeCompare(b.slug));
40
+ return { briefs: out };
41
+ }
42
+
43
+ /**
44
+ * Pull a brief's title + status without loading it into the model. Looks in both
45
+ * YAML frontmatter (`title:` / `status:`, used by the PUBLISHED briefs) and the
46
+ * markdown body (`# Title` / `**Status**:`, used by template-generated ones).
47
+ * Frontmatter wins for the title; the `**Status**:` line wins for status.
48
+ */
49
+ function parseMeta(file) {
50
+ let fmTitle = '', fmStatus = '', h1 = '', bodyStatus = '';
51
+ try {
52
+ const lines = readFileSync(file, 'utf8').split('\n');
53
+ let inFm = false, fmDone = false;
54
+ for (let i = 0; i < lines.length; i++) {
55
+ const line = lines[i];
56
+ if (i === 0 && line.trim() === '---') { inFm = true; continue; }
57
+ if (inFm) {
58
+ if (line.trim() === '---') { inFm = false; fmDone = true; continue; }
59
+ const t = line.match(/^title:\s*(.+?)\s*$/i);
60
+ if (t && !fmTitle) fmTitle = t[1].replace(/^["']|["']$/g, '');
61
+ const s = line.match(/^status:\s*(.+?)\s*$/i);
62
+ if (s && !fmStatus) fmStatus = s[1].replace(/^["']|["']$/g, '');
63
+ continue;
64
+ }
65
+ if (!h1) {
66
+ const m = line.match(/^#\s+(.+?)\s*$/);
67
+ if (m) { h1 = m[1]; continue; }
68
+ }
69
+ if (!bodyStatus) {
70
+ const m = line.match(/^\*\*Status\*\*:\s*(.+?)\s*$/i);
71
+ if (m) bodyStatus = m[1];
72
+ }
73
+ if ((fmTitle || h1) && (fmStatus || bodyStatus) && fmDone) break;
74
+ }
75
+ } catch { /* unreadable → fall through to defaults */ }
76
+ return {
77
+ title: fmTitle || h1 || '(untitled)',
78
+ status: bodyStatus || fmStatus || '-',
79
+ };
80
+ }
81
+
82
+ /** First clause of a status, capped — keeps the table aligned when a file writes a sentence. */
83
+ function shortStatus(s) {
84
+ const first = s.split(/[.(—]/)[0].trim() || s.trim();
85
+ return first.length > 18 ? first.slice(0, 17) + '…' : first;
86
+ }
87
+
88
+ function pad(s, n) { return s + ' '.repeat(Math.max(0, n - s.length)); }
89
+
90
+ function cmdList(category) {
91
+ const { error, briefs } = collectBriefs(category);
92
+ if (error) { console.error(error); process.exit(1); }
93
+ if (briefs.length === 0) {
94
+ console.log(category ? `(no briefs in doc/${category}/)` : '(no briefs under doc/)');
95
+ return;
96
+ }
97
+ const rows = briefs.map((b) => {
98
+ const { title, status } = parseMeta(b.full);
99
+ return { category: b.category, slug: b.slug, status: shortStatus(status), title };
100
+ });
101
+ const w = (k) => Math.max(k.length, ...rows.map((r) => r[k].length));
102
+ const wc = w('category'), ws = w('slug'), wst = w('status');
103
+ console.log(`${pad('CATEGORY', wc)} ${pad('SLUG', ws)} ${pad('STATUS', wst)} TITLE`);
104
+ for (const r of rows) {
105
+ console.log(`${pad(r.category, wc)} ${pad(r.slug, ws)} ${pad(r.status, wst)} ${r.title}`);
106
+ }
107
+ console.log(`\n${rows.length} brief${rows.length === 1 ? '' : 's'}.`);
108
+ }
109
+
110
+ function cmdShow(target) {
111
+ if (!target) { console.error('show: need a <slug-or-path>'); process.exit(3); }
112
+ // Direct path hit (relative to cwd or absolute).
113
+ for (const p of [target, join(process.cwd(), target)]) {
114
+ if (existsSync(p) && statSync(p).isFile()) {
115
+ console.log(`── ${relative(process.cwd(), p) || p} ──\n`);
116
+ console.log(readFileSync(p, 'utf8'));
117
+ return;
118
+ }
119
+ }
120
+ // Otherwise resolve a slug across categories.
121
+ const { error, briefs } = collectBriefs();
122
+ if (error) { console.error(error); process.exit(1); }
123
+ const slug = basename(target, '.md');
124
+ const matches = briefs.filter((b) => b.slug === slug);
125
+ if (matches.length === 0) {
126
+ console.error(`no brief matching "${slug}".`);
127
+ const near = briefs.filter((b) => b.slug.includes(slug)).slice(0, 8);
128
+ if (near.length) {
129
+ console.error('did you mean:');
130
+ for (const n of near) console.error(` ${n.category}/${n.slug}`);
131
+ }
132
+ process.exit(1);
133
+ }
134
+ if (matches.length > 1) {
135
+ console.error(`"${slug}" is ambiguous — matches ${matches.length} briefs:`);
136
+ for (const m of matches) console.error(` ${m.rel}`);
137
+ console.error('re-run show with the full path.');
138
+ process.exit(2);
139
+ }
140
+ const hit = matches[0];
141
+ console.log(`── ${hit.rel} ──\n`);
142
+ console.log(readFileSync(hit.full, 'utf8'));
143
+ }
144
+
145
+ const [cmd, ...rest] = process.argv.slice(2);
146
+ switch (cmd) {
147
+ case 'list': cmdList(rest[0]); break;
148
+ case 'show': cmdShow(rest[0]); break;
149
+ default:
150
+ console.error('usage: node briefs.mjs list [category] | show <slug-or-path>');
151
+ process.exit(3);
152
+ }
@@ -0,0 +1,151 @@
1
+ ---
2
+ description: Cold-start a session — read the last HANDOFF snapshot, the newest shipping log, the git summary, and (if LS is connected) your open work items, reconcile them, then categorize all pending work (resume in-flight · review/PR feedback · bugs · high-priority · low-hanging fruit · stale/dead · tech-debt/deferred, plus a non-pickable blocked list) and let you choose a list to work from before drilling into a specific item. Read-only; the complement to /kit:handoff. Does NOT branch, commit, or write files unless you confirm a next step.
3
+ ---
4
+
5
+ # /kit:kickoff
6
+
7
+ Start a session the way `/kit:handoff` ends one. Handoff **writes** the current-state snapshot and a single kickoff prompt at the end of a session; kickoff **reads** that snapshot back at the start of the next one, cross-checks it against git and your work items, and turns "what was I doing / what's next" into a concrete pick.
8
+
9
+ The loop is: `/kit:handoff` → (new session) → `/kit:kickoff` → choose a slice → work → `/kit:handoff` → `/kit:ship`. One session per feature; kickoff is the first thing you run in the fresh session.
10
+
11
+ This skill is **read-only by default**. It does not branch, commit, push, or write files. Its output is: a lay-of-the-land board, the pending work **sorted into categorized lists** (resume in-flight · low-hanging fruit · high-priority · stale/dead · tech-debt/deferred), a two-stage choice (pick a *list*, then a *specific item*), and — once you've chosen — a ready-to-use kickoff prompt for that item plus an offer to set up the branch/orbit as a *separate, confirmed* next step.
12
+
13
+ Parse `$ARGUMENTS`:
14
+
15
+ - (empty) — full orient: gather all sources, show the board + categorized lists, ask which list to work from, then drill into a specific item.
16
+ - **--brief** — show the lay-of-the-land board + the category headline counts only (e.g. "🍒 Low-hanging: 4 · 🔥 High-priority: 3 · 🪦 Stale: 6"). Skip the interactive choice. For "just remind me where I was."
17
+ - **--list=&lt;name&gt;** — skip the first-stage menu; go straight to the named list (`resume` / `review` / `bugs` / `priority` / `fruit` / `stale` / `debt`) and present its filtered items to pick from.
18
+ - **--pick=&lt;text&gt;** — skip both menus; treat `<text>` as the chosen item and go straight to producing its kickoff prompt + setup offer.
19
+ - **--all** — when assembling work-item candidates, include items not assigned to you (whole-board backlog), not just your own. Default is assigned-to-me.
20
+
21
+ ## Preflight
22
+
23
+ 1. `git rev-parse --is-inside-work-tree` — abort if not a git repo.
24
+ 2. Resolve the **base branch** (same logic as `/kit:handoff` and `/kit:ship`):
25
+ - `git symbolic-ref refs/remotes/origin/HEAD --short` (strip `origin/`). Fall back to `origin/main` / `origin/master` if unset.
26
+ 3. Record current branch (`git rev-parse --abbrev-ref HEAD`) and git email (`git config user.email`) — the email is the work-item handle.
27
+ 4. Detect LS connectivity: check for `.launch-secure.cred.config` at the repo root. If absent, kickoff still runs — it just **skips the work-items source** and notes "LS not connected; candidates from HANDOFF + git only." Do NOT abort (unlike `/kit:standup`, kickoff is useful offline).
28
+
29
+ ## Step 1 — Gather the sources (don't show yet)
30
+
31
+ Pull from four layers in parallel. Each is independently optional; a missing one is noted, not fatal.
32
+
33
+ **1a. The HANDOFF snapshot** — read `doc/handoff/HANDOFF.md` if it exists. Extract its four live sections: **Where we are**, **What's next** (the priority-ordered 1–3), **Open threads**, and the embedded **Kickoff prompt**. This is the human-curated "what's next," highest signal. If the file doesn't exist, note "no HANDOFF yet — first kickoff" and lean on git + work items.
34
+
35
+ **1b. The last ship** — read the newest file under `doc/shipping-logs/` (date-prefixed `YYYY-MM-DD-…`, so the lexically-last name is newest). This is the authoritative "what was *actually* last updated/shipped" — HANDOFF is current-state only and does not carry per-ship detail. Capture its title + the slice it shipped. If the dir is empty, skip.
36
+
37
+ **1c. Git summary** — the real on-disk state, to reconcile against what HANDOFF claims:
38
+ - `git log <base>..HEAD --oneline` — commits on this branch not yet in base.
39
+ - `git log -n 8 --oneline <base>` — recent baseline history (what landed lately).
40
+ - `git status --porcelain` — uncommitted work. Filter out generated noise (`.launchsecure/graphs/*.json`, `node_modules`, `dist`, `.next`). What remains is genuine in-flight work — a **"resume this"** candidate.
41
+ - Current branch + whether it's ahead/behind base.
42
+
43
+ **1d. Work items (only if LS connected)** — build the backlog candidates:
44
+ - `mcp__launch-secure__work_items_list({ assignee_email: "<git email>", status: "IN_PROGRESS" })` — things you already started; strongest "resume" candidates.
45
+ - `mcp__launch-secure__work_items_list({ assignee_email: "<git email>", status: "TODO" })` — your queued backlog.
46
+ - With `--all`, also fetch the same statuses without `assignee_email` to include unassigned/team items.
47
+ - Capture id + title + status for each. Cap at ~8 total; if more, keep the top 8 and note "(N more in LS)".
48
+
49
+ > Use the hosted `launch-secure` MCP by default. Only use `local-launch-secure` if the active course points there (see `/kit:course`). Don't ask for org/project slugs — the `.mcp.json` headers default to the current project.
50
+
51
+ ## Step 2 — Reconcile + flag drift
52
+
53
+ Before showing anything, cross-check the sources against each other. This is the honesty pass — the inverse of what `/kit:standup` does for shipped work.
54
+
55
+ - **Stale "What's next":** if a HANDOFF "What's next" item appears already done in git (matching commits in `<base>..HEAD`, or named in the newest shipping log), flag it: _"HANDOFF lists ‹X› as next, but it appears shipped (commit ‹sha›) — likely stale."_ Don't silently drop it; surface the contradiction.
56
+ - **Dedup across sources:** a HANDOFF "What's next" item and an LS work item often refer to the same slice (match on id like `LS-…`/`#…`, or on title similarity). Collapse them into one candidate that carries both handles.
57
+ - **Resolved open threads:** if an "Open thread" looks addressed by a recent commit, note it as "possibly resolved — confirm."
58
+ - **Branch sanity:** if the current branch already has commits ahead of base AND there's an in-progress work item, the most likely intent is "continue the current branch," not "start something new" — rank accordingly.
59
+
60
+ ## Step 3 — Categorize the pending work into lists
61
+
62
+ Pool every candidate from the reconciled sources (HANDOFF "What's next" + "Open threads", LS work items, uncommitted git work, follow-up flags grepped from recent commit bodies — same patterns `/kit:standup` uses: `TODO`, `follow-up`, `deferred`, `not patched`, `revert`, `next pass`, plus `broken`/`bug`/`failing`/`blocked`/`waiting on`). Dedup (Step 2).
63
+
64
+ **First, pull out the blocked items** — anything tagged `blocked`/`waiting`, marked depending on an unfinished item, or whose commit/thread says "waiting on ‹X›". These go to the non-pickable **🚧 Blocked** list (Step 4) so you see *why* they aren't moving; they are removed from all buckets below.
65
+
66
+ Then sort each remaining item into **one** bucket — most-specific bucket wins, in this precedence:
67
+
68
+ 1. **🔧 Resume in-flight** — uncommitted local work + `IN_PROGRESS` work items. The strongest "continue what you started" signal; always wins if present.
69
+ 2. **👀 Review / PR feedback** — work waiting on *your* action on something already in motion: open PRs you authored or are assigned to review, unresolved review comments, `needs-review`/`changes-requested` tags. Time-sensitive (someone's blocked on you), so it outranks fresh work.
70
+ 3. **🐛 Bugs / broken** — defects: work items of type `bug` or tagged `bug`/`defect`/`regression`, and `broken`/`failing`/`revert`/`not patched` follow-up flags from commit bodies. Distinct from feature backlog regardless of priority.
71
+ 4. **🔥 High-priority** — items the project marks urgent: a work-item priority/severity field at its top value, tags like `p0`/`p1`/`urgent`, **and** everything in HANDOFF "What's next" (human-curated = high priority by definition), minus anything Step 2 flagged stale.
72
+ 5. **🍒 Low-hanging fruit** — quick wins: work items with a small estimate/size field or `quick`/`chore`/`good-first`/`small` tags, single-file follow-up flags from commit bodies, and one-line open threads. When no size signal exists, infer from scope words in the title ("rename", "typo", "bump", "add flag", "copy") — but say it's inferred.
73
+ 6. **🪦 Stale / dead** — pending too long: `TODO`/`IN_PROGRESS` work items whose `updatedAt` is older than ~30 days (tune to the project's pace), and open threads that have survived multiple handoffs. These are the "why is this still here" items.
74
+ 7. **🧹 Tech-debt / deferred** — items tagged `tech-debt`/`debt`/`deferred`/`backlog`, explicit deferrals recorded in HANDOFF, and `deferred`/`rolled back` follow-up flags from commit bodies.
75
+
76
+ Each item lands in exactly one bucket. Within a bucket, sort by the most relevant key (priority desc, then age; for stale, oldest first; for fruit, smallest first). An empty bucket is simply omitted everywhere downstream.
77
+
78
+ ## Step 4 — Show the lay of the land
79
+
80
+ One compact block: orientation header, then each **non-empty** bucket with up to **5** items and a `+N more` tail. No preamble.
81
+
82
+ ```
83
+ 📍 Where we are
84
+ <HANDOFF "Where we are", trimmed to 2–4 lines. If no HANDOFF: a 1-line synthesis from git.>
85
+ 🚢 Last shipped: <newest shipping-log title + date> — <one line>
86
+ ⚠️ Drift: <Step 2 flags, one line each. Omit if none.>
87
+
88
+ 🔧 Resume in-flight (N)
89
+ - <item — handle/branch/file · short why>
90
+ …up to 5… (+N more)
91
+
92
+ 👀 Review / PR feedback (N)
93
+ - <item — PR#/LS-id · what's waiting on you>
94
+ …up to 5… (+N more)
95
+
96
+ 🐛 Bugs / broken (N)
97
+ - <item — LS-id · short why>
98
+ …up to 5… (+N more)
99
+
100
+ 🔥 High-priority (N)
101
+ - <item — LS-id · short why>
102
+ …up to 5… (+N more)
103
+
104
+ 🍒 Low-hanging fruit (N)
105
+ - <item — handle · est/size or "inferred quick">
106
+ …up to 5… (+N more)
107
+
108
+ 🪦 Stale / dead (N)
109
+ - <item — LS-id · "untouched 47d">
110
+ …up to 5… (+N more)
111
+
112
+ 🧹 Tech-debt / deferred (N)
113
+ - <item — handle · source>
114
+ …up to 5… (+N more)
115
+
116
+ 🚧 Blocked (N) — not pickable, shown for awareness
117
+ - <item — handle · waiting on ‹what›>
118
+ …up to 5… (+N more)
119
+ ```
120
+
121
+ Readable in under a minute. The 🚧 Blocked list is informational only — never offered as a pick. If `--brief`, stop after the headline counts line (don't expand the bucket items).
122
+
123
+ ## Step 5 — Two-stage choice: pick a list, then an item
124
+
125
+ **Stage A — which list.** Call **AskUserQuestion** ("Which list do you want to work from?"). Options are the **non-empty pickable buckets** (🚧 Blocked is never an option), capped at 4 (the tool's max) — there are up to 7 pickable buckets, so choose the 4 most useful for this session by precedence + item count + freshness, and surface the rest in option descriptions ("…also N stale, N tech-debt — say the word to see them"). Thin slow-moving buckets may be folded into one option ("Stale & deferred"). Each option's description carries the bucket's count + a one-line flavor of what's inside. "Other" (auto-added) lets the user name any list (including a folded/overflow one) or item directly. Skip Stage A if `--list=` was passed.
126
+
127
+ **Stage B — which item.** Once a list is chosen, show that bucket's **full** filtered list (not just the top 5 — now we're focused on one category, so depth is fine), numbered, each with its handle + the one-line why. Ask the user to pick one (a second `AskUserQuestion` with up to 4 of the top items, or just let them reply with a number/name if the list is long). Skip Stage B if `--pick=` was passed.
128
+
129
+ ## Step 6 — Set up the chosen item
130
+
131
+ Once a specific item is chosen:
132
+
133
+ 1. **Produce its kickoff prompt.** If the chosen slice matches the one HANDOFF already wrote a "Kickoff prompt for the next session" for, **reuse that verbatim** in a fenced block. Otherwise synthesize one in the **same shape** handoff uses (Starting **‹item — Title›** · read CLAUDE.md + HANDOFF + relevant Briefs · then the 1–6 design-shape questions: Surface, Fields/inputs, Eligibility, Data path, feature-specific, Out-of-scope). Make it specific to the chosen slice, not generic.
134
+ 2. **Offer the setup as a confirmed next step — do not do it unprompted.** In one line, offer to: branch off the base (`git checkout <base> && git pull && git checkout -b <slice-branch>`) **or** create an isolated orbit (`/kit:orbit`) if the slice wants a forked DB. Wait for an explicit "yes" / branch name before running any git or orbit command — this is a state mutation and falls under the per-action confirmation rule.
135
+ 3. If the chosen slice is a `TODO` work item and the user confirms starting it, offer (don't auto-run) to move it to `IN_PROGRESS` via `mcp__launch-secure__work_item_move` / `work_item_update`.
136
+
137
+ ## Edge cases
138
+
139
+ - **No HANDOFF.md yet** (first kickoff in a repo) — don't fabricate a "Where we are." Synthesize the board from git + last shipping log + work items, and tell the user "no HANDOFF snapshot yet — run `/kit:handoff` at the end of this session to create one." Kickoff degrades to a git+LS orientation.
140
+ - **LS not connected** — skip Step 1d entirely; candidates come from HANDOFF + git. Note it once on the board.
141
+ - **Clean tree, nothing in flight, empty backlog** — say so plainly ("nothing in flight; HANDOFF's next is ‹X›") and just present HANDOFF's "What's next" as the candidates. Don't invent work.
142
+ - **HANDOFF wildly out of sync with git** (many stale "next" items already shipped) — lead with the drift block and suggest the previous session likely forgot `/kit:handoff`; offer to reconstruct current-state from git, but don't write HANDOFF here (that's `/kit:handoff`'s job).
143
+ - **Mid-branch resume** (current branch already ahead of base) — surface "continue this branch" at the top of the 🔧 Resume in-flight list, and skip the branch-creation offer in Step 6 unless the user picks a different item.
144
+ - **Everything lands in one bucket** (e.g. all candidates are stale) — that's fine; show the single list and skip Stage A (no choice to make), going straight to picking an item.
145
+
146
+ ## Notes for the assistant
147
+
148
+ - Kickoff is **read + orient + choose**. It is the mirror of `/kit:handoff` (write) — keep the boundary clean: kickoff does not write `HANDOFF.md`, does not commit, does not push. The only mutations it ever performs are the explicitly-confirmed branch/orbit/work-item-move in Step 6.
149
+ - The single most useful thing kickoff adds over just re-reading HANDOFF is **reconciliation** (Step 2): HANDOFF is hand-maintained and goes stale. Always cross-check it against git before presenting its "What's next" as gospel.
150
+ - Prefer commit scopes, work-item ids, and shipping-log titles as candidate handles — they're stable and clickable. Don't pull the full chart/graph for this; kickoff is a fast orientation, not an analysis (`/kit:analyse` is for structure).
151
+ - Respect the course: read/write LS through whichever server the active course points at, never cross prod/local.
@@ -10,7 +10,8 @@ Parse `$ARGUMENTS` — first token is the subcommand:
10
10
 
11
11
  - **create &lt;branch&gt;** — `[--base=<ref>] [--profile=<name>]` — fork resources per `orbit.json`, return path + envFile.
12
12
  - **list** — list every orbit registered on this machine.
13
- - **switch &lt;branch&gt;** — print the path/env for an existing orbit (no shell mutation).
13
+ - **switch &lt;branch&gt;** — activate an orbit: atomically repoint the `current` anchor at its worktree, then operate under that anchor.
14
+ - **deactivate** — clear the `current` anchor so work targets the main checkout again.
14
15
  - **doctor** — surface registry inconsistencies.
15
16
  - **check &lt;branch&gt; --target=&lt;target-branch&gt;** — run pre-merge gates WITHOUT merging.
16
17
  - **merge &lt;branch&gt; --target=&lt;target-branch&gt;** — `[--cleanup=full|none] [--skip-gate=<id>,…]` — run gates + merge.
@@ -43,7 +44,18 @@ Examples:
43
44
 
44
45
  ### switch
45
46
 
46
- `mcp__launch-orbit__orbit_switch(branch)` print `cd <path>` + `envFile`. Don't run cd.
47
+ `mcp__launch-orbit__orbit_switch(branch)` **activates** the orbit — it atomically repoints `<project>/.launchsecure/orbit/current` at the orbit's worktree and writes `active.json`, then returns `anchor` + `nextAction`. This is a real, deterministic switch: one stable path now resolves into the active orbit.
48
+
49
+ After switching, target the anchor for everything (this is the whole point — one path, not the raw worktree path):
50
+ - **files**: Read / Edit / Write under `.launchsecure/orbit/current/<path>`.
51
+ - **chart**: pass `project_root: ".launchsecure/orbit/current"`.
52
+ - **commands**: run the returned `nextAction` (`cd ".launchsecure/orbit/current"`) once, then all Bash runs in the orbit.
53
+
54
+ Switching to a *different* orbit just repoints the anchor — re-run `nextAction` afterward, because a shell that already `cd`'d resolved the old target at cd-time (files and chart follow the symlink live; only the shell needs the re-cd).
55
+
56
+ ### deactivate
57
+
58
+ `mcp__launch-orbit__orbit_deactivate()` removes the `current` anchor + `active.json` for this project. Use when done in the orbit so subsequent work targets the main checkout. No-op if nothing is active. (Dropping the active orbit clears the anchor automatically.)
47
59
 
48
60
  ### doctor
49
61
 
File without changes