@tanagram/lore 0.1.91 → 0.1.92

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tanagram/lore",
-  "version": "0.1.91",
+  "version": "0.1.92",
   "description": "Lore CLI",
   "type": "module",
   "bin": {
@@ -8,7 +8,6 @@
   },
   "files": [
     "dist",
-    "skills",
     "scripts/nodeVersionGuard.mjs",
     "scripts/runPostinstallCommand.mjs"
   ],
@@ -41,7 +40,7 @@
   "scripts": {
     "dev": "pnpm run postinstall && tsx src/index.ts",
     "dev:watch": "tsx src/index.ts _run_upload --watch",
-    "postinstall": "node scripts/runPostinstallCommand.mjs postinstall:migrate && node scripts/runPostinstallCommand.mjs postinstall:install-skills && node scripts/runPostinstallCommand.mjs postinstall:refresh-background-binary",
+    "postinstall": "node scripts/runPostinstallCommand.mjs postinstall:migrate && node scripts/runPostinstallCommand.mjs postinstall:cleanup-legacy-skills && node scripts/runPostinstallCommand.mjs postinstall:refresh-background-binary",
     "build": "node scripts/build.mjs",
     "build:prod": "node scripts/build.mjs --prod",
     "start": "node dist/index.js",

package/scripts/runPostinstallCommand.mjs

@@ -17,9 +17,8 @@ if (!nodeVersion.ok) {
 
 const allowedCommands = new Set([
   'postinstall:migrate',
-  'postinstall:install-skills',
+  'postinstall:cleanup-legacy-skills',
   'postinstall:refresh-background-binary',
-  'postinstall:uninstall-skills',
 ]);
 
 const command = process.argv[2];

package/skills/fork/SKILL.md

@@ -1,83 +0,0 @@
----
-name: fork
-description: >-
-  Distills a Lore thread into handoff context for continuing work. Use when the
-  user asks to "continue work from thread", "fork from thread", "pick up from
-  this Lore thread", or invokes /fork with a Lore thread URL/ID and forker
-  intent.
-argument-hint: "<lore-thread-url-or-id> <forker-intent>"
-allowed-tools: Bash
----
-
-# Fork a Lore Thread
-
-Fetches an intent-conditioned handoff summary for a Lore thread and returns the
-`source_distilled` payload to the agent so it can continue from that context.
-
-## When to Use
-
-Run when the user asks to:
-
-- "continue work from thread <thread-url-or-id>"
-- "fork from thread <thread-url-or-id>"
-- "pick up from this Lore thread"
-- "use this thread as context for <intent>"
-- invoke `/fork <thread-url-or-id> <forker-intent>`
-
-Do not use this for merely reading or listing Lore threads. Use the `lore-read`
-skill for read-only thread inspection.
-
-## Inputs
-
-This skill needs two inputs:
-
-1. A Lore thread URL or ID. Accepted examples include `th_...`,
-   and `https://lore.tanagram.ai/thread/th_...`.
-2. Forker intent: what the user wants to do with the source thread.
-
-If either input is missing, ask one concise clarification question before
-running the command.
-
-## Command
-
-Run `lore threads fork` with the thread reference and intent. The command emits
-JSON; extract and return only `source_distilled`.
-
-```bash
-THREAD_REF='<lore-thread-url-or-id>'
-FORKER_INTENT='<what the user wants to do next>'
-
-lore threads fork "$THREAD_REF" --forker-intent "$FORKER_INTENT" \
-  | node -e 'let input = "";
-process.stdin.on("data", (chunk) => { input += chunk; });
-process.stdin.on("end", () => {
-  const parsed = JSON.parse(input);
-  if (typeof parsed.source_distilled !== "string" || parsed.source_distilled.length === 0) {
-    console.error("lore threads fork did not return source_distilled");
-    process.exit(1);
-  }
-  process.stdout.write(parsed.source_distilled);
-});'
-```
-
-Use shell-safe quoting for both values. Do not pass the full thread transcript to
-the model yourself; the CLI/API performs the intent-conditioned distillation.
-
-## After Running
-
-Treat the printed `source_distilled` text as the source-thread context for the
-current task. Use it to continue the requested work. Do not show raw JSON to the
-user unless they explicitly ask for it.
-
-If the user only asked to prepare the fork context, return the distilled text
-verbatim. If they asked to continue the work, briefly acknowledge that the fork
-context was loaded and proceed with the task using that context.
-
-## Failure Modes
-
-- **Not logged in**: the command returns a login error. Tell the user to run
-  `lore login` and retry.
-- **Thread not found or not visible**: tell the user the thread could not be
-  found or they do not have access, and ask for a visible Lore thread URL/ID.
-- **Missing `source_distilled`**: surface the error and do not invent fork
-  context.

package/skills/lore-read/SKILL.md

@@ -1,95 +0,0 @@
----
-name: lore-read
-description: >-
-  Read information from Lore (the team's shared thread library). Use when the
-  user asks to fetch a specific Lore thread, search/list threads, or find
-  threads by filepath, author, or time range. Examples: "show me that Lore
-  thread", "what did my coworker share on Lore last week", "find Lore
-  threads that touched src/foo.ts", "list recent Lore sessions". Shells out
-  to the `lore threads get` and `lore threads list` CLI commands.
-allowed-tools: Bash
----
-
-# Read from Lore
-
-Fetches data from Lore via the `lore` CLI. Three underlying commands:
-
-- `lore threads get <thread-id-or-url>` — fetch a single thread by ID or Lore URL.
-- `lore threads list [flags]` — list/search threads with optional deterministic filters.
-- `lore threads ask --question=<question>` — search threads by semantic meaning; use when the user asks an open-ended question.
-
-Both print a JSON payload on stdout. Parse the JSON and summarize for the user; only show raw JSON if they ask for it.
-
-## When to Use
-
-Run when the user asks to:
-
-- "show me / open / read Lore thread <id-or-url>"
-- "what did <coworker> post / share on Lore"
-- "find Lore threads about <filepath / directory>"
-- "list recent Lore threads" or "Lore threads from <time range>"
-- "search Lore for ..."
-
-Do NOT run proactively. Only on explicit request.
-
-## Fetching a Single Thread
-
-When the user gives a thread ID (`th_...`) or a Lore thread URL (`https://lore.tanagram.ai/thread/th_...`):
-
-```bash
-lore threads get <thread-id-or-url>
-```
-
-The argument can be either form — the CLI extracts the thread ID from a URL automatically.
-
-## Listing / Searching Threads
-
-```bash
-lore threads list [--before <cursor>] [--after <cursor>] \
-                  [--author_ids <id1,id2,...>] \
-                  [--created_at <unix> | <start>...<end>] \
-                  [--filepath_prefixes <prefix1,prefix2,...>]
-```
-
-Flag reference:
-
-- `--filepath_prefixes` — comma-separated filepath prefixes. Matches threads whose sessions touched files under any of those prefixes. Use this for "threads about <some path>".
-- `--author_ids` — comma-separated **Lore user IDs** (not names or emails). If the user names a coworker, you need their Lore user ID; if you don't have it, ask the user or fetch a recent unfiltered list and look for their ID in the results before filtering.
-- `--created_at` — either a single Unix timestamp (seconds) or a `<start>...<end>` range of Unix timestamps. Convert any human time range ("last week", "since Monday") into Unix seconds before passing. Today is provided in the system context.
-- `--before` / `--after` — pagination cursors returned in a previous list response. Use these to page through large result sets, not for time filtering (that's `--created_at`).
-
-Combine flags freely — they AND together server-side.
-
-## Searching Threads Semantically:
-
-```bash
-lore threads ask --question=<question>
-```
-
-Use this when asks about threads in a broad way that can't be entirely captured by the flags listed above. For example:
-
-- "what have we been thinking about our open-source strategy?"
-- "what did we say about running multiple fastify replicas in railway?"
-- "what are some recent decisions we've made about our Posthog setup?"
-
-## Output
-
-All commands emit a single JSON object/array on stdout. After running:
-
-1. Parse the JSON.
-2. Summarize the relevant fields for the user (thread ID, title/topic, author, created time, URL, matching filepaths, etc.) instead of dumping raw JSON.
-3. If the user asked for a single thread, surface its Lore URL prominently so they can click through.
-4. If listing, show the top results with their URLs and a one-line hint each. Mention pagination cursors only if the user is likely to want more.
-
-## Failure Modes
-
-- **Not logged in**: command returns `not logged in — run 'lore login' first`. Tell the user to run `lore login`.
-- **Bad thread ref**: `lore threads get` requires either a `th_...` ID or a Lore session URL. If the user passes something else, ask them to clarify or provide the URL.
-- **Unknown author**: `--author_ids` only accepts Lore user IDs. If the user gives a name/email and you don't have a mapping, run `lore threads list` without the author filter (optionally narrowed by `--created_at` or `--filepath_prefixes`) and find the ID from the results, or ask the user.
-- **Empty results**: not an error — tell the user no threads matched and suggest loosening filters.
-
-## What This Does NOT Do
-
-- It does not export the current session — that's the `share` skill (`lore export`).
-- It does not modify threads, comments, visibility, or any Lore state. It is read-only.
-- It does not start or manage the Lore background daemon.

package/skills/share/SKILL.md

@@ -1,126 +0,0 @@
----
-name: share
-description: Share (export) the current Claude Code session to Lore and get back a shareable URL. Use when the user says "share this thread", "send this to Lore", "export this conversation", "post this to Lore", or asks for a link to the current session. Safe to invoke explicitly on request — do not run proactively.
-allowed-tools: Bash
----
-
-# Share to Lore
-
-Exports the Claude Code session you are currently running in to Lore (the team's shared thread library) and prints the URL. Lore dedupes session exports by session ID, so re-sharing the same session is safe — it returns the existing thread.
-
-## When to Use
-
-Run when the user asks to:
-
-- "share this thread / conversation / session"
-- "send this to Lore"
-- "export this to Lore"
-- "get a Lore link for this"
-- "post this to Lore"
-
-Do NOT run this proactively. Only on explicit request.
-
-- "share to #channel" (share to Lore AND post to a Slack channel)
-
-## Command
-
-**Always** pass `--session-id ${CLAUDE_SESSION_ID}` so the CLI exports _this_ session — the one the user just asked to share. Claude Code substitutes `${CLAUDE_SESSION_ID}` with the current session's ID; the CLI will not guess it for you.
-
-Use this command as the default implementation:
-
-```bash
-lore export --session-id ${CLAUDE_SESSION_ID} --visibility workspace
-```
-
-If the user includes a natural-language highlight request after `/share`, pass that request through with `--highlight`. For example, `/share where I made Claude also update the API in addition to UI` should run:
-
-```bash
-lore export --session-id ${CLAUDE_SESSION_ID} --visibility workspace --highlight "where I made Claude also update the API in addition to UI"
-```
-
-Do **not** omit `--session-id` and rely on the cwd-match fallback. The fallback picks the most recent history entry for the current directory, which is frequently a _different_ session (a prior run, a parallel worktree, etc.) — the user then has to retry with the explicit flag. The skill runtime gives you the session ID for free, so always pass it.
-
-If the user wants to share a _different_ session, substitute their ID for `${CLAUDE_SESSION_ID}` in the export command above.
-
-If the user explicitly asks to share publicly (anyone with the link) or to keep the thread private to themselves, change the `--visibility` flag in the export command to `public` or `private` respectively. Default to `workspace` whenever the user just says "share".
-
-## Output
-
-The first command prints a single JSON object on stdout:
-
-```json
-{
-  "thread_id": "th_...",
-  "url": "https://lore.tanagram.ai/thread/th_...",
-  "session_id": "...",
-  "project": "/Users/me/repo",
-  "reused": false,
-  "visibility": "workspace",
-  "clipboard_copied": true,
-  "highlight": {
-    "query": "where I made Claude also update the API in addition to UI",
-    "matched": true,
-    "start_block_id": "tb_...",
-    "end_block_id": null
-  }
-}
-```
-
-- `url` — the shareable Lore link for the session thread. **Always show this to the user as the primary result.**
-- `highlight` — present only when `--highlight` was supplied. When `matched` is true, the `url` already includes the server-selected block anchor or range.
-- `clipboard_copied` — `true` when the URL was copied to the system clipboard (via `pbcopy` on macOS, `wl-copy`/`xclip`/`xsel` on Linux, `clip.exe` on Windows). `false` when no clipboard tool was available. Mention this to the user when `true` so they know they can paste it directly.
-
-## Slack Integration
-
-If the user says "share to #channel", "post to #eng", or includes a Slack channel name (with or without the `#` prefix), do the following **after** the Lore export succeeds:
-
-1. Extract the `thread_id` from the export output.
-2. Strip the leading `#` from the channel name if present.
-3. Read the auth token from `~/.lore/token` (prod) or `~/.lore-dev/token` (dev). If neither exists, tell the user to run `lore login` first.
-4. Determine the API base URL: use `LORE_API_URL` env var if set, otherwise `https://api.lore.tanagram.ai` for prod or `http://localhost:4000` for dev (check which token file exists).
-5. Post to Slack via the API directly:
-
-```bash
-TOKEN=$(cat ~/.lore/token 2>/dev/null || cat ~/.lore-dev/token 2>/dev/null)
-API_BASE="${LORE_API_URL:-https://api.lore.tanagram.ai}"
-curl -s -X POST "$API_BASE/api/slack/post" \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d "{\"channel_name\": \"CHANNEL\", \"thread_id\": \"THREAD_ID\"}"
-```
-
-Replace `CHANNEL` with the channel name (no `#` prefix) and `THREAD_ID` with the `thread_id` from the export output.
-
-If `lore slack post` is available (check with `lore slack --help 2>/dev/null`), you may use that instead:
-
-```bash
-lore slack post CHANNEL --thread-id THREAD_ID
-```
-
-6. If the response contains `"ok":true`, confirm to the user that the thread was posted to the channel.
-7. If it fails with "No Slack installation", tell the user to connect Slack from Account Settings first.
-8. If it fails with a channel error, tell the user the bot may not be in that channel and suggest `/invite @Lore` in Slack.
-
-When Slack posting is requested, the response should look like:
-
-> Shared: https://lore.tanagram.ai/session/th_abc123 (copied to clipboard).
-> Posted to #eng in Slack.
-
-If the user just says "share" without mentioning a channel, skip the Slack step entirely.
-
-## After Running
-
-Echo the session URL back to the user as a clickable link. If `clipboard_copied` is `true`, add a short note that the URL is on their clipboard. Do not list other threads, summarize the conversation, or take any additional action unless the user asks. A minimal response looks like:
-
-> Shared: https://lore.tanagram.ai/thread/th_abc123 (copied to clipboard).
-
-## Failure Modes
-
-- **Not logged in**: the command returns `not logged in — run 'lore login' first`. Tell the user to run `lore login` and try again.
-- **No matching history entry**: this happens when `${CLAUDE_SESSION_ID}` isn't present in `~/.claude/history.jsonl` yet (very fresh session) or when the user asked to share a session that the CLI can't find. Ask the user which session they want to share, or suggest `--session-id <id>` / `--project <path>` with the value they provide.
-
-## What This Does NOT Do
-
-- It does not start the Lore background daemon. For ongoing auto-sync of every session, `lore enable` is the right command.
-- It does not change the thread title, comments, or other metadata. The user can adjust those in the Lore UI after sharing.
-- It does not advance the background daemon's sync cursor. If the daemon is running, it may re-upload the same session on its next cycle — Lore will return the same thread ID, so this is a no-op.

package/skills/share-codex/SKILL.md

@@ -1,102 +0,0 @@
----
-name: share-codex
-description: Share (export) the current Codex session to Lore and get back a shareable URL. Use when the user is running inside Codex and says "share this thread", "send this to Lore", "export this conversation", "post this to Lore", or asks for a link to the current Codex session. Safe to invoke explicitly on request — do not run proactively.
-allowed-tools: Bash
----
-
-# Share Codex session to Lore
-
-Exports the Codex session you are currently running in to Lore (the team's shared thread library) and prints the URL.
-
-Codex stores each session as a JSONL rollout file on disk under
-`~/.codex/sessions/YYYY/MM/DD/rollout-<timestamp>-<uuid>.jsonl`. This skill
-locates the file by the current Codex session ID, then hands it to the lore
-CLI which uploads it as a Codex thread.
-
-## When to Use
-
-Run when the user asks to:
-
-- "share this thread / conversation / session"
-- "send this to Lore"
-- "export this to Lore"
-- "get a Lore link for this"
-- "post this to Lore"
-
-Do NOT run this proactively. Only on explicit request.
-
-## Command
-
-```bash
-SESSION_FILE=$(find "$HOME/.codex/sessions" -name "*${CODEX_SESSION_ID}.jsonl" 2>/dev/null | head -1)
-if [ -z "$SESSION_FILE" ]; then
-  echo "Could not locate Codex session file for session id ${CODEX_SESSION_ID}" >&2
-  exit 1
-fi
-lore share-codex --session-file "$SESSION_FILE" --visibility workspace
-```
-
-`${CODEX_SESSION_ID}` is set by Codex inside the running session. If it is
-empty, ask the user which session they want to share and substitute the ID.
-
-If the user includes a natural-language highlight request after `/share-codex`,
-pass that request through with `--highlight`. For example,
-`/share-codex where I made Codex also update the API in addition to UI` should
-run:
-
-```bash
-lore share-codex --session-file "$SESSION_FILE" --visibility workspace --highlight "where I made Codex also update the API in addition to UI"
-```
-
-If the user explicitly asks to share publicly (anyone with the link) or to
-keep the thread private to themselves, change the `--visibility` flag to
-`public` or `private` respectively. Default to `workspace` whenever the user
-just says "share".
-
-## Output
-
-The command prints a single JSON object on stdout:
-
-```json
-{
-  "thread_id": "th_...",
-  "url": "https://lore.tanagram.ai/thread/th_...",
-  "session_id": "...",
-  "project": "",
-  "reused": false,
-  "visibility": "workspace",
-  "clipboard_copied": true,
-  "highlight": {
-    "query": "where I made Codex also update the API in addition to UI",
-    "matched": true,
-    "start_block_id": "tb_...",
-    "end_block_id": null
-  }
-}
-```
-
-- `url` — the shareable Lore link for the session thread. **Always show this to the user as the primary result.**
-- `highlight` — present only when `--highlight` was supplied. When `matched` is true, the `url` already includes the server-selected block anchor or range.
-- `clipboard_copied` — `true` when the URL was copied to the system clipboard. Mention this when `true` so the user knows they can paste it directly.
-- `project` — intentionally empty for Codex sessions. Codex does not record a project directory in the rollout file.
-
-## After Running
-
-Echo the session URL back to the user as a clickable link. If
-`clipboard_copied` is `true`, add a short note that the URL is on their
-clipboard. Do not list other threads, summarize the conversation, or take any
-additional action unless the user asks. A minimal response looks like:
-
-> Shared: https://lore.tanagram.ai/thread/th_abc123 (copied to clipboard).
-
-## Failure Modes
-
-- **Not logged in**: the command returns `lore is logged out`. Tell the user to run `lore login` and try again.
-- **Session file not found**: the rollout file may not exist yet for very fresh Codex sessions. Ask the user to send another message in Codex (which forces the rollout to flush) and retry.
-- **Lore is offline**: the command surfaces network errors. Relay the message verbatim.
-
-## What This Does NOT Do
-
-- It does not start any background daemon. This skill is a one-shot upload.
-- It does not change the thread title, comments, or other metadata. The user can adjust those in the Lore UI after sharing.
-- No plan export is wired up for Codex. Codex planning is event-stream/UI-first with no clean finalized-plan boundary; plan steps are surfaced by Lore from the session transcript itself.