{"items":[{"id":"cmugucix7003hqu060fgf6iia","slug":"thedotmack-claude-mem-wowerpoint","name":"wowerpoint","description":"Turn one document into a kawaii NotebookLM slide-deck PDF. Use for \"wowerpoint this\", \"make a deck about \", \"turn this report into slides\", or any request to render a single document as shareable narrative slides.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"wowerpoint","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Turn one document into a kawaii NotebookLM slide-deck PDF. Use for \"wowerpoint this\", \"make a deck about \", \"turn this report into slides\", or any request to render a single document as shareable narrative slides.","permissions":[],"systemPrompt":"# Wowerpoint\n\nOne doc in, one PDF out. Slide-deck only — videos and podcasts from the same engine are noticeably worse and out of scope; refer the user to the `notebooklm` CLI directly if they want those.\n\n## Triggers\n\n- \"Wowerpoint \"\n- \"Make a slide deck about \"\n- \"Turn this report into slides\"\n- \"Kawaii-deck this\"\n\n## Setup (one-time per machine)\n\nIf `notebooklm auth check` returns 0 and `command -v jq` resolves, skip.\n\n```bash\nuv tool install --with playwright --force notebooklm-py\n$(uv tool dir)/notebooklm-py/bin/playwright install chromium\n```\n\n`jq` is required by the workflow's JSON parsing; install if missing (`brew install jq` on macOS, or your distro's package manager).\n\nThen the user authenticates interactively — do not script. Tell them to type `! notebooklm login` so the OAuth ENTER lands in their terminal.\n\n## Workflow\n\n### 1. The source doc\n\nYou need exactly one source doc. If it doesn't exist or is too thin to carry a deck, **write it first** — use mem-search and sequential thinking to make it comprehensive (long-form, narrative, several thousand words is normal). Do not paper over a weak source by adding more sources.\n\n### 2. Auth pre-flight\n\n```bash\nnotebooklm auth check 2>&1 | tail -5\n```\n\nExit 1 with `Run 'notebooklm login' to authenticate.` = halt and tell the user.\n\n### 3. Create notebook, add the source\n\n```bash\nNOTEBOOK_ID=$(notebooklm create \"\" --json | jq -r .notebook.id)\nSOURCE_ID=$(notebooklm source add \"<doc-path>\" --notebook \"$NOTEBOOK_ID\" --json | jq -r .source.id)\n```\n\nTitle: H1 of the source doc, or its filename stem; append a date for dated work.\n\nJSON envelope keys differ — `create` → `.notebook.id`, `source add` → `.source.id`, `generate` → `.task_id`. Wrong key = empty string = silent downstream failure.\n\n### 4. Spawn the subagent\n\nGeneration takes ~10 minutes; never block on it. Use the template below with `run_in_background: true`.\n\n### 5. End your turn\n\nPrint the notebook URL so the user can watch live:\n\n```text\nhttps://notebooklm.google.com/notebook/<NOTEBOOK_ID>\n```\n\nThe subagent's completion notification fires when the file is on disk.\n\n## Output path\n\nAdjacent to the source, parallel filename:\n\n```text\n<source-dir>/<source-stem>-slides.pdf\n```\n\nIf the source isn't somewhere that makes sense as an output location, default to `reports/<stem>-slides.pdf`.\n\n## Share link (WOWerpoint Server)\n\nAfter the PDF lands on disk, the subagent also POSTs it to the WOWerpoint Server, which converts the 16:9 deck into a 9:16 mobile twin and returns a share URL. The share URL is the primary deliverable to the user; the PDF on disk is the backup.\n\nRequired env (exported in the user's shell — the subagent inherits the parent's environment, so plain `export` is enough; no dotenv loader runs):\n\n```bash\nWOWERPOINT_API_BASE=https://wowerpoint-api.<subdomain>.workers.dev\nWOWERPOINT_VIEWER_BASE=https://wowerpoint-viewer.<subdomain>.workers.dev\nWOWERPOINT_UPLOAD_TOKEN=<token>\n```\n\nIf any var is missing, skip the share-link step and just hand the PDF over.\n\nUpload pattern (run AFTER the subagent confirms the PDF exists on disk). Capture the full response so empty `id` and `error` payloads are handled — `jq -r '.id'` returns the literal string `null` on a missing key, so always pipe through `.id // empty`:\n\n```bash\nif [ -n \"$WOWERPOINT_API_BASE\" ] && [ -n \"$WOWERPOINT_UPLOAD_TOKEN\" ] && [ -n \"$WOWERPOINT_VIEWER_BASE\" ]; then\n UPLOAD_JSON=$(curl -sS --connect-timeout 10 --max-time 30 -X POST \"$WOWERPOINT_API_BASE/api/decks\" \\\n -H \"Authorization: Bearer $WOWERPOINT_UPLOAD_TOKEN\" \\\n -F \"file=@<OUTPUT_PATH>\" \\\n -F \"title=<TITLE>\")\n DECK_ID=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.id // empty')\n API_ERROR=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.error // empty')\n if [ -n \"$API_ERROR\" ] || [ -z \"$DECK_ID\" ]; then\n echo \"WOWerpoint upload warning: ${API_ERROR:-missing id}\"\n else\n echo \"Share URL: $WOWERPOINT_VIEWER_BASE/$DECK_ID\"\n fi\nfi\n```\n\nThe returned `id` is a kebab-case slug derived from the title with a random creature suffix (e.g. `tokenrouter-quest-hawk`, or `velvet-comet-tiger` if the title is empty or non-ASCII). The share URL is:\n\n```text\n$WOWERPOINT_VIEWER_BASE/<id>\n```\n\nIt works immediately (shows a \"still converting…\" page that auto-reloads when ready). Conversion takes ~1–2 min per slide. Print the share URL in your final response.\n\n## The prompt\n\nOne sentence. Default:\n\n```text\nUse kawaii characters to tell the story of <subject>. Keep it warm and clear.\n```\n\nReplace `<subject>` with a one-phrase description from the source doc's H1 or the user's framing. If the user supplies their own prompt, pass it through verbatim — don't expand it.\n\n## Subagent template (copy-paste, parameterize)\n\n```text\nYou're handling NotebookLM slide-deck generation. Work in `<repo-absolute-path>`.\n\nContext:\n- The `notebooklm` CLI is installed and authenticated (parent verified with `notebooklm auth check`).\n- A notebook and source already exist.\n\nInputs:\n- Notebook ID: `<NOTEBOOK_ID>`\n- Source ID: `<SOURCE_ID>`\n- Generation prompt: `<PROMPT>`\n- Output path: `<OUTPUT_PATH>`\n- Deck title: `<TITLE>` (the notebook title, used by the share-link step)\n\nSteps:\n\n1. Wait for source: `notebooklm source wait <SOURCE_ID> -n <NOTEBOOK_ID> --timeout 600`\n Exit 0 = ready, 1 = error, 2 = timeout. On timeout, run `notebooklm source list -n <NOTEBOOK_ID> --json` and report status.\n\n2. Generate: `notebooklm generate slide-deck \"<PROMPT>\" --format detailed --length default --notebook <NOTEBOOK_ID> --json --retry 2`\n Parse `task_id` from the JSON (key is `task_id` at top level).\n On `GENERATION_FAILED` or \"No result found for RPC ID\": sleep 300, retry once, then give up.\n\n3. Wait for artifact: `notebooklm artifact wait <task_id> -n <NOTEBOOK_ID> --timeout 1800`\n\n4. Download: `notebooklm download slide-deck <OUTPUT_PATH> -a <task_id> -n <NOTEBOOK_ID>`\n\n5. Verify: `ls -la <OUTPUT_PATH>` confirms the file exists.\n\n6. Upload to WOWerpoint Server for a mobile share link. Skip silently if any of `WOWERPOINT_API_BASE`, `WOWERPOINT_UPLOAD_TOKEN`, or `WOWERPOINT_VIEWER_BASE` is unset. Otherwise:\n\n ```bash\n if [ -n \"$WOWERPOINT_API_BASE\" ] && [ -n \"$WOWERPOINT_UPLOAD_TOKEN\" ] && [ -n \"$WOWERPOINT_VIEWER_BASE\" ]; then\n UPLOAD_JSON=$(curl -sS --connect-timeout 10 --max-time 30 -X POST \"$WOWERPOINT_API_BASE/api/decks\" \\\n -H \"Authorization: Bearer $WOWERPOINT_UPLOAD_TOKEN\" \\\n -F \"file=@<OUTPUT_PATH>\" \\\n -F \"title=<TITLE>\")\n DECK_ID=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.id // empty')\n API_ERROR=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.error // empty')\n if [ -n \"$API_ERROR\" ] || [ -z \"$DECK_ID\" ]; then\n echo \"WOWerpoint upload warning: ${API_ERROR:-missing id}\"\n else\n echo \"Share URL: $WOWERPOINT_VIEWER_BASE/$DECK_ID\"\n fi\n fi\n ```\n\n On warning, the PDF on disk is still a valid deliverable — do not retry the upload.\n\nReport briefly (under 200 words):\n- Final artifact ID\n- Time per phase (source wait, generation, render wait, download)\n- Output file path + size\n- Share URL (if produced)\n- Any retries or warnings\n- Exact error message if any step failed\n\nDo NOT poll status manually. The `wait` commands handle backoff.\n```\n\n## Failure modes\n\n- **`pip: command not found`** — modern macOS doesn't ship pip on PATH. Use `uv tool install`.\n- **`Playwright not installed`** — install `notebooklm-py` with `--with playwright`, then `playwright install chromium`.\n- **`Run 'notebooklm login' to authenticate`** — only the user can complete OAuth.\n- **`task_id` parsed as empty string** — wrong JSON envelope key. `generate` returns `{\"task_id\": \"...\"}` at top level.\n- **Rate-limit (`GENERATION_FAILED` or \"No result found for RPC ID\")** — `--retry 2` handles transients; persistent failure means wait 5–10 minutes or fall back to the web UI.\n- **Source upload denied for sensitive docs** — confirm before adding sources containing credentials, customer data, or unreleased product info. NotebookLM is a Google service.\n- **`--length long` does not exist** — only `default|short`. If the user asks for \"long slides,\" use `default` and explain.\n- **No `--style` flag** — kawaii lives in the prompt text.\n\n## Operational tips\n\n- **Rerun cheaply** — once the notebook + source exist, regenerating with a different prompt only repeats generation + download. Reuse `NOTEBOOK_ID` and `SOURCE_ID`.\n- **Web UI fallback** — if generation is rate-limited >30 minutes, open the notebook URL, trigger generation in the UI, then `notebooklm artifact list -n <NOTEBOOK_ID>` and `download`.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/wowerpoint","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/wowerpoint/SKILL.md","defaultBranch":"main"},"readme":"# Wowerpoint\n\nOne doc in, one PDF out. Slide-deck only — videos and podcasts from the same engine are noticeably worse and out of scope; refer the user to the `notebooklm` CLI directly if they want those.\n\n## Triggers\n\n- \"Wowerpoint <file>\"\n- \"Make a slide deck about <file>\"\n- \"Turn this report into slides\"\n- \"Kawaii-deck this\"\n\n## Setup (one-time per machine)\n\nIf `notebooklm auth check` returns 0 and `command -v jq` resolves, skip.\n\n```bash\nuv tool install --with playwright --force notebooklm-py\n$(uv tool dir)/notebooklm-py/bin/playwright install chromium\n```\n\n`jq` is required by the workflow's JSON parsing; install if missing (`brew install jq` on macOS, or your distro's package manager).\n\nThen the user authenticates interactively — do not script. Tell them to type `! notebooklm login` so the OAuth ENTER lands in their terminal.\n\n## Workflow\n\n### 1. The source doc\n\nYou need exactly one source doc. If it doesn't exist or is too thin to carry a deck, **write it first** — use mem-search and sequential thinking to make it comprehensive (long-form, narrative, several thousand words is normal). Do not paper over a weak source by adding more sources.\n\n### 2. Auth pre-flight\n\n```bash\nnotebooklm auth check 2>&1 | tail -5\n```\n\nExit 1 with `Run 'notebooklm login' to authenticate.` = halt and tell the user.\n\n### 3. Create notebook, add the source\n\n```bash\nNOTEBOOK_ID=$(notebooklm create \"<title>\" --json | jq -r .notebook.id)\nSOURCE_ID=$(notebooklm source add \"<doc-path>\" --notebook \"$NOTEBOOK_ID\" --json | jq -r .source.id)\n```\n\nTitle: H1 of the source doc, or its filename stem; append a date for dated work.\n\nJSON envelope keys differ — `create` → `.notebook.id`, `source add` → `.source.id`, `generate` → `.task_id`. Wrong key = empty string = silent downstream failure.\n\n### 4. Spawn the subagent\n\nGeneration takes ~10 minutes; never block on it. Use the template below with `run_in_background: true`.\n\n### 5. End your turn\n\nPrint the notebook URL so the user can watch live:\n\n```text\nhttps://notebooklm.google.com/notebook/<NOTEBOOK_ID>\n```\n\nThe subagent's completion notification fires when the file is on disk.\n\n## Output path\n\nAdjacent to the source, parallel filename:\n\n```text\n<source-dir>/<source-stem>-slides.pdf\n```\n\nIf the source isn't somewhere that makes sense as an output location, default to `reports/<stem>-slides.pdf`.\n\n## Share link (WOWerpoint Server)\n\nAfter the PDF lands on disk, the subagent also POSTs it to the WOWerpoint Server, which converts the 16:9 deck into a 9:16 mobile twin and returns a share URL. The share URL is the primary deliverable to the user; the PDF on disk is the backup.\n\nRequired env (exported in the user's shell — the subagent inherits the parent's environment, so plain `export` is enough; no dotenv loader runs):\n\n```bash\nWOWERPOINT_API_BASE=https://wowerpoint-api.<subdomain>.workers.dev\nWOWERPOINT_VIEWER_BASE=https://wowerpoint-viewer.<subdomain>.workers.dev\nWOWERPOINT_UPLOAD_TOKEN=<token>\n```\n\nIf any var is missing, skip the share-link step and just hand the PDF over.\n\nUpload pattern (run AFTER the subagent confirms the PDF exists on disk). Capture the full response so empty `id` and `error` payloads are handled — `jq -r '.id'` returns the literal string `null` on a missing key, so always pipe through `.id // empty`:\n\n```bash\nif [ -n \"$WOWERPOINT_API_BASE\" ] && [ -n \"$WOWERPOINT_UPLOAD_TOKEN\" ] && [ -n \"$WOWERPOINT_VIEWER_BASE\" ]; then\n UPLOAD_JSON=$(curl -sS --connect-timeout 10 --max-time 30 -X POST \"$WOWERPOINT_API_BASE/api/decks\" \\\n -H \"Authorization: Bearer $WOWERPOINT_UPLOAD_TOKEN\" \\\n -F \"file=@<OUTPUT_PATH>\" \\\n -F \"title=<TITLE>\")\n DECK_ID=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.id // empty')\n API_ERROR=$(printf '%s' \"$UPLOAD_JSON\" | jq -r '.error // empty')\n if [ -n \"$API_ERROR\" ] || [ -z \"$DECK_ID\" ]; then\n echo \"WOWerpoint upload warning: ${API_ERROR:-missing id}\"\n else\n echo \"Share URL: $WOWERPOINT_VIEWER_BASE/$DECK_ID\"\n fi\nfi\n```\n\nThe returned `id` is a kebab-case slug deri","createdAt":"2026-09-25T10:51:51.884Z","updatedAt":"2026-09-25T10:51:51.884Z"},{"id":"cmuguciwx003equ06sv6bf62y","slug":"thedotmack-claude-mem-what-the","name":"what-the","description":"What the? Use when the user wants a plain-English breakdown of something technical — the who, what, where, why, and when.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"what-the","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"What the? Use when the user wants a plain-English breakdown of something technical — the who, what, where, why, and when.","permissions":[],"systemPrompt":"that sounds mad technical. explain to me the who, what, where, why, and when of this","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/what-the","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/what-the/SKILL.md","defaultBranch":"main"},"readme":"that sounds mad technical. explain to me the who, what, where, why, and when of this","createdAt":"2026-09-25T10:51:51.873Z","updatedAt":"2026-09-25T10:51:51.873Z"},{"id":"cmuguciwm003bqu06yegtgncv","slug":"thedotmack-claude-mem-weekly-digests","name":"weekly-digests","description":"Generate a serial week-by-week narrative digest of a project's full claude-mem timeline. Splits the timeline into per-ISO-week files, then runs one consecutive subagent per week — each receiving the prior week's carry-forward block — to produce one chapter per ISO week of data. Use when asked for \"weekly digests\", \"week-by-week story\", \"serial timeline\", or \"narrative chapters\" of a project's history.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"weekly-digests","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Generate a serial week-by-week narrative digest of a project's full claude-mem timeline. Splits the timeline into per-ISO-week files, then runs one consecutive subagent per week — each receiving the prior week's carry-forward block — to produce one chapter per ISO week of data. Use when asked for \"weekly digests\", \"week-by-week story\", \"serial timeline\", or \"narrative chapters\" of a project's history.","permissions":[],"systemPrompt":"# Weekly Digests\n\nProduce a serial, multi-chapter narrative digest of a project's complete claude-mem history. Differs from `timeline-report` (one long report) — this generates one digest *per ISO week*, with each subagent reading the prior week's carry-forward block so the story stays coherent.\n\n**The chapter count equals the number of ISO weeks the timeline covers.** A project with 2 weeks of data produces 2 chapters; one with 30 weeks produces 30. There is no fixed length — count the weeks first, then drive the pipeline off that count.\n\n## When to Use\n\nTrigger when the user asks for:\n\n- \"Weekly digests\"\n- \"Week-by-week story\"\n- \"Serial timeline\"\n- \"Story chapters of [project]\"\n- \"Run a digest for each week\"\n- \"Continue the story week by week\"\n\nIf the user wants a single sweeping report, use `timeline-report` instead. This skill is for serial chapter format.\n\n## Prerequisites\n\n- claude-mem worker running\n- Project has at least one ISO week of observations (the pipeline degenerates gracefully — even N=1 works)\n- A clean output directory the user is comfortable writing into\n\n**Resolve the worker port** (do this once, reuse `$WORKER_PORT`):\n\n```bash\nWORKER_PORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\n```\n\n## Workflow\n\n### Step 1: Determine the Project Name\n\nSame worktree-detection pattern as `timeline-report`. In a worktree, the data source is the **parent project**:\n\n```bash\ngit_dir=$(git rev-parse --git-dir 2>/dev/null)\ngit_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)\nif [ \"$git_dir\" != \"$git_common_dir\" ]; then\n parent_project=$(basename \"$(dirname \"$git_common_dir\")\")\nelse\n parent_project=$(basename \"$PWD\")\nfi\necho \"$parent_project\"\n```\n\n### Step 2: Fetch the Full Timeline and Save It\n\n```bash\nmkdir -p .scratch\ncurl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true\" \\\n > .scratch/cm-timeline.md\nwc -l .scratch/cm-timeline.md\n```\n\nSanity-check: confirm the file is non-empty and has the expected structure (preamble, then date headers like `### Mon DD, YYYY`, then numeric observation lines `<id> <time> <emoji> <title>` and session boundary lines `S<n> <prompt> (Mon DD at HH:MMpm)`).\n\n### Step 3: Split the Timeline Into Per-ISO-Week Files\n\nWrite a Python script to `.scratch/split-timeline.py` that:\n\n1. Parses date headers (`### Mon DD, YYYY`).\n2. Groups days into ISO weeks via `date.isocalendar()` (Monday-start).\n3. Emits one file per week to `docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md`, preserving each day's section verbatim.\n4. Runs a dual-pass sanity check: total observations distributed must equal the count in the source file.\n\nOutput structure (filenames illustrative):\n\n```\ndocs/timeline-weeks/\n README.md # weekly index table\n YYYY-W<NN>-MonDD-to-MonDD.md # one per ISO week the timeline covers\n ...\n```\n\nEach weekly file should preserve the original daily sections verbatim. Do not paraphrase at this stage — the digest agents need raw fidelity.\n\n**Count the resulting files** before launching the pipeline. That count is `TOTAL` and drives every subsequent step. Empty weeks (zero observations between active weeks) should be skipped — the pipeline only operates on weeks that have content.\n\n### Step 4: Build the Weekly Index README\n\nWrite `docs/timeline-weeks/README.md` with a markdown table: Week | Dates | Observations | Sessions | File. This becomes the operator's roadmap and helps the agents understand pacing (peak weeks vs trough weeks).\n\n### Step 5: Run the Consecutive Subagent Pipeline\n\n**Critical: subagents run sequentially, NOT in parallel.** Each agent receives the prior agent's carry-forward block. This is the entire point of the skill — without it you have N disjoint summaries; with it you have an N-chapter serial narrative.\n\nCreate the output directory:\n\n```bash\nmkdir -p docs/timeline-weeks/digests\n```\n\nFor each week, in chronological order, dispatch a Task subagent (general-purpose) with this prompt template. **Wait for each agent to complete before launching the next.** Capture the carry-forward block from the result and inject it as `STORY_SO_FAR` into the next prompt.\n\n#### Subagent Prompt Template\n\n```\nYou are writing chapter {N} of {TOTAL} in a serial week-by-week digest of the {PROJECT} project's development history. Chapters 1 through {N-1} are written. {SPECIAL_NOTE: e.g. \"This is the LARGEST week\", \"This is the TROUGH\", \"This is the FINAL chapter\", \"This is the ONLY chapter — both first AND final week\"}.\n\n**Source file (read in full):**\n{ABSOLUTE_PATH_TO_WEEK_FILE}\n\n**Output digest file (write):**\n{ABSOLUTE_PATH_TO_DIGEST_FILE}\n\n**Format key for the source file:**\n- Numeric lines like `1 7:59p 🔵 Save hook file is empty` are observations (ID, time, type-emoji, title)\n- `S##` lines are session boundaries (the user prompt that started the session)\n- Emoji legend: 🎯session 🔴bugfix 🟣feature 🔄refactor ✅change 🔵discovery ⚖️decision 🚨security_alert 🔐security_note 🤫sensitive\n\n**Story so far (carry-forward from Week {N-1}):**\n\n{STORY_SO_FAR_BLOCK_OR_EMPTY_FOR_WEEK_1}\n\n**Your digest must include:**\n1. **Title line** — `# Week {N} ({WEEK_LABEL}): {DATE_RANGE} — [your chosen subtitle]`\n2. **One-line tagline** — what this week is about, in plain English\n3. **Narrative section** ({BUDGET}) — tell the story. Resolve threads from prior weeks where the data shows resolution. Introduce new arcs. Use specific observation details.\n4. **Threads continued / opened / resolved** sections\n5. **Cliffhanger / What's next**\n6. **Carry-forward block** at the very bottom, fenced as ```carry-forward ... ``` — structured handoff for the next week's agent.\n\n**CARRY-FORWARD DISCIPLINE:**\n- Cap at ~350 words.\n- AGGRESSIVELY PRUNE: drop arcs that didn't surface this week unless they're actively unresolved cliffhangers.\n- Drop cast members absent 2+ weeks unless load-bearing for the long arc.\n- Quality over completeness. The next agent inherits what you mention; mention judiciously.\n\nRequired carry-forward sub-sections:\n- **Active arcs** — ongoing themes/projects the next agent should watch for\n- **Cast** — notable named systems/people/tools (continuing + new)\n- **Unresolved** — open questions or unfinished work\n- **Tone notes** — how the story is being told (voice, perspective, register evolution)\n\n**Tone rules:**\n- Third-person narrator, sharp, observational. Not twee.\n- AI is \"Claude\"; human is \"{USER_FIRST_NAME}\".\n- Treat codebase components as characters — whatever the project's recurring named systems are (e.g. a worker, a queue, a process manager, a recurring bug, a flaky migration). Don't import names from another project; use what shows up in this project's observations.\n- Don't manufacture drama. Name what's there.\n- Track the user's prompt-register evolution week by week (frustration markers, escalation language, shifts in tone).\n- Note meta-recursion if the project is reflexive about its own behavior (e.g. a tool that documents its own work, an AI agent debugging itself, a system that catches its own regressions).\n- Watch for new villains or co-stars and name them.\n- For trough/silent weeks: silence IS the story. Don't pad. Name what didn't happen.\n- For surge weeks (>2,000 obs): pick 4-7 spine arcs and tell them well. Don't catalog.\n\n**Important:** Do NOT speculate beyond what's in the source file.\n\nAfter writing the file, return:\n1. Path of the file you wrote\n2. The carry-forward block verbatim\n3. One-sentence summary of the week\n```\n\n#### Narrative Budget by Observation Count\n\nScale narrative length proportionally to the week's volume:\n\n| Obs count | Narrative section budget |\n| --- | --- |\n| < 100 | 200–400 words |\n| 100–500 | 300–600 words |\n| 500–1,500 | 500–900 words |\n| 1,500–3,000 | 700–1,100 words |\n| 3,000+ | 800–1,300 words |\n\nPad these into the `{BUDGET}` slot of the prompt for each week.\n\n#### The First Week\n\nFor Week 1, pass an empty `STORY_SO_FAR_BLOCK` and an instruction noting it's the origin chapter — the agent should establish initial cast, tone, and arcs for everyone after.\n\n#### The Final Week\n\nThe final week gets a different ending: **no carry-forward block**. Instead, instruct the agent to write a `## Where We Are` section (~250 words) naming what's still open at the moment of writing. Tell the agent the project is ongoing — the digest stops; the story doesn't. Don't give the story a false ending.\n\n#### When N = 1 (single-week project)\n\nApply BOTH treatments to the same chapter: empty `STORY_SO_FAR_BLOCK` AND `## Where We Are` instead of a carry-forward block. The agent is writing both the origin and the close in one pass. Don't reference prior or future chapters that don't exist.\n\n### Step 6: Rename Files for Sortable Order\n\nThe agents write digests with names like `YYYY-W<NN>-digest.md`. These already sort chronologically by ISO week (until a project crosses a year boundary inside one project name), but **add a zero-padded numeric prefix** so the order is unambiguous to humans browsing or scripting against the directory:\n\n```bash\ncd docs/timeline-weeks/digests\ntotal=$(ls *.md | wc -l | tr -d ' ')\nwidth=${#total} # 1 for N<10, 2 for N<100, 3 for N<1000\n[ \"$width\" -lt 2 ] && width=2 # always pad to at least 2 for readability\ni=0\nfor f in *.md; do\n printf -v prefix \"%0${width}d\" $i\n mv \"$f\" \"${prefix}-$f\"\n i=$((i+1))\ndone\n```\n\nResult for N=30: `00-...md` through `29-...md`. For N=4: `00-...md` through `03-...md`. For N=120: `000-...md` through `119-...md`. **Always zero-pad** — `1-...md` and `10-...md` sort wrong without it.\n\nDo NOT also prepend the order number to the digest title line inside each file. The filename prefix is for sorting; the title stays clean: `# Week N (W##): Date — Subtitle`.\n\n### Step 7: Report Completion\n\nTell the user:\n- Total weeks digested (N)\n- Output directory path\n- Date range covered\n- Any silent/trough weeks worth flagging\n- A one-sentence capstone summarizing the arc — written by the final-chapter agent, or composed by the operator from the final agent's `## Where We Are` section.\n\n## Pipeline Discipline\n\nThese rules emerged from running the pipeline end-to-end. Encode them every time:\n\n1. **Sequential, not parallel.** The whole point is the carry-forward chain. Parallelism breaks it.\n2. **Carry-forward is bounded.** It will bloat without active pruning. Tell every agent: cap ~350 words, drop dormant arcs, drop absent cast.\n3. **Track register evolution explicitly.** The user's prompt-style across weeks is a story arc. Frustration markers shift over time (whatever they happen to be in this project's data). Name the shifts.\n4. **Treat components as characters.** Whatever recurring named systems show up in the observations are this project's villains and co-stars. Stable cast across weeks builds narrative coherence.\n5. **Honor silence.** Trough weeks (10–100 obs) are real chapters. Name what didn't happen. Don't pad.\n6. **Don't manufacture drama.** Just observe the data. If the project is reflexive, the recursion is the drama; you don't need to add more.\n7. **Final week: no false ending.** The digest stops; the project doesn't. Write `## Where We Are`, not \"the end.\"\n\n## Error Handling\n\n- **Empty timeline**: project name wrong, or worker not running. `curl -s \"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\"` to verify.\n- **Worker not running**: start it via your usual method or check `ps aux | grep worker-service`.\n- **Subagent returns malformed carry-forward**: extract the carry-forward block by regex (` ```carry-forward ... ``` `) and pass forward verbatim. If missing, ask the agent to retry with the explicit instruction \"your reply MUST include the carry-forward block fenced as ```carry-forward ... ``` at the very end.\"\n- **One agent fails mid-pipeline**: retry that week with the same carry-forward. Don't skip — the chain breaks.\n- **Carry-forward growing past ~500 words**: tighten the discipline instruction in subsequent prompts. Force pruning explicitly.\n\n## Examples\n\n### Long-running project (~30 weeks)\n\nUser: \"Make weekly digests for [project] from beginning to end\"\n\n1. Resolve worker port, detect project name.\n2. Fetch full timeline → `.scratch/cm-timeline.md`.\n3. Run `.scratch/split-timeline.py` → N weekly files in `docs/timeline-weeks/` (e.g. 30).\n4. Generate `docs/timeline-weeks/README.md` index.\n5. Launch N subagents consecutively, one per week. Each gets the prior week's carry-forward. The first chapter starts with empty carry-forward; the final chapter writes `## Where We Are` instead of a carry-forward block.\n6. Rename digests with zero-padded order prefix (`00-...md` through `29-...md`).\n7. Report total chapters, date range, any troughs/peaks, and the one-line capstone the final agent produced.\n\n### Short-lived project (~3 weeks)\n\nSame flow, just smaller. N=3, so:\n- Chapter 1: empty carry-forward, establish cast/tone/arcs.\n- Chapter 2: receives chapter 1's carry-forward, builds on it.\n- Chapter 3: receives chapter 2's carry-forward, BUT gets the final-chapter treatment (`## Where We Are` instead of carry-forward block).\n- Filenames: `00-...md`, `01-...md`, `02-...md`.\n\n### Single-week project (N=1)\n\nApply both first-and-final-chapter treatment to the only chapter: empty carry-forward, `## Where We Are` close, no inter-chapter references. Filename: `00-...md`.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/weekly-digests","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/weekly-digests/SKILL.md","defaultBranch":"main"},"readme":"# Weekly Digests\n\nProduce a serial, multi-chapter narrative digest of a project's complete claude-mem history. Differs from `timeline-report` (one long report) — this generates one digest *per ISO week*, with each subagent reading the prior week's carry-forward block so the story stays coherent.\n\n**The chapter count equals the number of ISO weeks the timeline covers.** A project with 2 weeks of data produces 2 chapters; one with 30 weeks produces 30. There is no fixed length — count the weeks first, then drive the pipeline off that count.\n\n## When to Use\n\nTrigger when the user asks for:\n\n- \"Weekly digests\"\n- \"Week-by-week story\"\n- \"Serial timeline\"\n- \"Story chapters of [project]\"\n- \"Run a digest for each week\"\n- \"Continue the story week by week\"\n\nIf the user wants a single sweeping report, use `timeline-report` instead. This skill is for serial chapter format.\n\n## Prerequisites\n\n- claude-mem worker running\n- Project has at least one ISO week of observations (the pipeline degenerates gracefully — even N=1 works)\n- A clean output directory the user is comfortable writing into\n\n**Resolve the worker port** (do this once, reuse `$WORKER_PORT`):\n\n```bash\nWORKER_PORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\n```\n\n## Workflow\n\n### Step 1: Determine the Project Name\n\nSame worktree-detection pattern as `timeline-report`. In a worktree, the data source is the **parent project**:\n\n```bash\ngit_dir=$(git rev-parse --git-dir 2>/dev/null)\ngit_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)\nif [ \"$git_dir\" != \"$git_common_dir\" ]; then\n parent_project=$(basename \"$(dirname \"$git_common_dir\")\")\nelse\n parent_project=$(basename \"$PWD\")\nfi\necho \"$parent_project\"\n```\n\n### Step 2: Fetch the Full Timeline and Save It\n\n```bash\nmkdir -p .scratch\ncurl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true\" \\\n > .scratch/cm-timeline.md\nwc -l .scratch/cm-timeline.md\n```\n\nSanity-check: confirm the file is non-empty and has the expected structure (preamble, then date headers like `### Mon DD, YYYY`, then numeric observation lines `<id> <time> <emoji> <title>` and session boundary lines `S<n> <prompt> (Mon DD at HH:MMpm)`).\n\n### Step 3: Split the Timeline Into Per-ISO-Week Files\n\nWrite a Python script to `.scratch/split-timeline.py` that:\n\n1. Parses date headers (`### Mon DD, YYYY`).\n2. Groups days into ISO weeks via `date.isocalendar()` (Monday-start).\n3. Emits one file per week to `docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md`, preserving each day's section verbatim.\n4. Runs a dual-pass sanity check: total observations distributed must equal the count in the source file.\n\nOutput structure (filenames illustrative):\n\n```\ndocs/timeline-weeks/\n README.md # weekly index table\n YYYY-W<NN>-MonDD-to-MonDD.md # one per ISO week the timeline covers\n ...\n```\n\nEach weekly file should preserve the original daily sections verbatim. Do not paraphrase at this stage — the digest agents need raw fidelity.\n\n**Count the resulting files** before launching the pipeline. That count is `TOTAL` and drives every subsequent step. Empty weeks (zero observations between active weeks) should be skipped — the pipeline only operates on weeks that have content.\n\n### Step 4: Build the Weekly Index README\n\nWrite `docs/timeline-weeks/README.md` with a markdown table: Week | Dates | Observations | Sessions | File. This becomes the operator's roadmap and helps the agents understand pacing (peak weeks vs trough weeks).\n\n### Step 5: Run the Consecutive Subagent Pipeline\n\n**Critical: subagents run sequentially, NOT in parallel.** Each agent rec","createdAt":"2026-09-25T10:51:51.862Z","updatedAt":"2026-09-25T10:51:51.862Z"},{"id":"cmuguciwd0038qu06k2gkbrp0","slug":"thedotmack-claude-mem-version-bump","name":"version-bump","description":"Automated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, plugin.json manifests, build verification, git tagging, GitHub releases, and changelog generation. NPM publishing is the final human-required handoff because the maintainer raised npm security.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"version-bump","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Automated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, plugin.json manifests, build verification, git tagging, GitHub releases, and changelog generation. NPM publishing is the final human-required handoff because the maintainer raised npm security.","permissions":[],"systemPrompt":"# Version Bump & Release Workflow\n\n**IMPORTANT:** Plan and write detailed release notes before starting.\n\n**CRITICAL:** Commit EVERYTHING (including build artifacts). At the end of this workflow, NOTHING should be left uncommitted or unpushed. Run `git status` at the end to verify.\n\n## Preparation\n\n1. **Analyze**: Determine if the change is **PATCH** (bug fixes), **MINOR** (features), or **MAJOR** (breaking).\n2. **Environment**: Identify repository owner/name from `git remote -v`.\n3. **Paths — every file that carries the version string**:\n - `package.json` — **the npm/npx-published version** (`npx claude-mem@X.Y.Z` resolves from this)\n - `plugin/package.json` — bundled plugin runtime deps\n - `.claude-plugin/marketplace.json` — version inside `plugins[0].version`\n - `.claude-plugin/plugin.json` — top-level Claude-plugin manifest\n - `plugin/.claude-plugin/plugin.json` — bundled Claude-plugin manifest\n - `.codex-plugin/plugin.json` — Codex-plugin manifest\n - `plugin/.codex-plugin/plugin.json` — bundled Codex-plugin manifest\n - `openclaw/openclaw.plugin.json` — OpenClaw plugin manifest\n\n Verify coverage before editing: `git grep -l \"\\\"version\\\": \\\"<OLD>\\\"\"` should list all eight. If a new manifest has been added since this doc was last updated, update this list.\n\n## Workflow\n\n1. **Update**: Increment the version string in every path above. Do NOT touch `CHANGELOG.md` — it's regenerated.\n2. **Verify**: `git grep -n \"\\\"version\\\": \\\"<NEW>\\\"\"` — confirm all eight files match. `git grep -n \"\\\"version\\\": \\\"<OLD>\\\"\"` — should return zero hits.\n3. **Build and sync**: `npm run build-and-sync` to regenerate artifacts, sync the local marketplace copy, restart the worker, and clear the queue. Do not use plain `npm run build` for release validation because it can leave the local marketplace/worker out of sync.\n4. **Commit**: `git add -A && git commit -m \"chore: bump version to X.Y.Z\"`.\n5. **Tag**: `git tag -a vX.Y.Z -m \"Version X.Y.Z\"`.\n6. **Push**: `git push origin main && git push origin vX.Y.Z`.\n7. **GitHub release**: `gh release create vX.Y.Z --title \"vX.Y.Z\" --notes \"RELEASE_NOTES\"`.\n8. **Changelog**: Regenerate via the project's changelog script:\n ```bash\n npm run changelog:generate\n ```\n (Runs `node scripts/generate-changelog.js`, which pulls releases from the GitHub API and rewrites `CHANGELOG.md`.)\n9. **Sync changelog**: Commit and push the updated `CHANGELOG.md`.\n10. **Pre-handoff audit**: Verify the release commit, tag, GitHub release, and\n changelog are pushed; confirm the release worktree has no pending tracked\n changes; and ensure its build dependencies are present because\n `prepublishOnly` rebuilds the package. If `npm view claude-mem@X.Y.Z version`\n already resolves, skip the handoff and continue with post-publish checks.\n11. **Final human handoff — publish to npm.** Do not stop in the middle of the\n workflow for npm. Finish every agent-owned preparation above first, then\n make this the final human-required action.\n\n The human maintainer's credentials/2FA are required. The agent MUST NOT run\n `npm publish` (or `np` / `npm run release:*`, which also publish). Give the\n exact release-worktree path and this command as the only requested action:\n ```bash\n npm publish # run by the HUMAN — prepublishOnly rebuilds the package\n ```\n Wait for confirmation. Do not ask the human to perform any other release\n step afterward.\n12. **Post-publish verification and notification**: After confirmation, verify\n both the exact version and the latest dist-tag:\n ```bash\n npm view claude-mem@X.Y.Z version\n npm view claude-mem version\n ```\n If the publish build touched tracked artifacts, run `npm run build-and-sync`,\n review the result, and commit/push any legitimate changes. Then run the\n Discord notification from `~/Scripts/claude-mem/`, where the `.env` with\n webhook details lives:\n ```bash\n cd ~/Scripts/claude-mem/ && npm run discord:notify vX.Y.Z\n ```\n Do this only after npm verification, and even when the release worktree does\n not have a local `.env`.\n13. **Finalize**: `git status` — working tree must be clean and everything must\n be pushed. Only automated verification, notification, and cleanup may occur\n after the final human handoff.\n\n## Checklist\n\n- [ ] All eight config files have matching versions\n- [ ] `git grep` for old version returns zero hits\n- [ ] `npm run build-and-sync` succeeded\n- [ ] Git tag created and pushed\n- [ ] GitHub release created with notes\n- [ ] `CHANGELOG.md` updated and pushed\n- [ ] Pre-handoff audit passed; no agent-owned release preparation remains\n- [ ] **NPM publishing handed off as the final human-required action** (agent does NOT run it)\n- [ ] Exact npm version and `latest` both verified after the human publishes\n- [ ] Discord notification run from `~/Scripts/claude-mem/` only after npm verification\n- [ ] `git status` shows clean tree","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/version-bump","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/version-bump/SKILL.md","defaultBranch":"main"},"readme":"# Version Bump & Release Workflow\n\n**IMPORTANT:** Plan and write detailed release notes before starting.\n\n**CRITICAL:** Commit EVERYTHING (including build artifacts). At the end of this workflow, NOTHING should be left uncommitted or unpushed. Run `git status` at the end to verify.\n\n## Preparation\n\n1. **Analyze**: Determine if the change is **PATCH** (bug fixes), **MINOR** (features), or **MAJOR** (breaking).\n2. **Environment**: Identify repository owner/name from `git remote -v`.\n3. **Paths — every file that carries the version string**:\n - `package.json` — **the npm/npx-published version** (`npx claude-mem@X.Y.Z` resolves from this)\n - `plugin/package.json` — bundled plugin runtime deps\n - `.claude-plugin/marketplace.json` — version inside `plugins[0].version`\n - `.claude-plugin/plugin.json` — top-level Claude-plugin manifest\n - `plugin/.claude-plugin/plugin.json` — bundled Claude-plugin manifest\n - `.codex-plugin/plugin.json` — Codex-plugin manifest\n - `plugin/.codex-plugin/plugin.json` — bundled Codex-plugin manifest\n - `openclaw/openclaw.plugin.json` — OpenClaw plugin manifest\n\n Verify coverage before editing: `git grep -l \"\\\"version\\\": \\\"<OLD>\\\"\"` should list all eight. If a new manifest has been added since this doc was last updated, update this list.\n\n## Workflow\n\n1. **Update**: Increment the version string in every path above. Do NOT touch `CHANGELOG.md` — it's regenerated.\n2. **Verify**: `git grep -n \"\\\"version\\\": \\\"<NEW>\\\"\"` — confirm all eight files match. `git grep -n \"\\\"version\\\": \\\"<OLD>\\\"\"` — should return zero hits.\n3. **Build and sync**: `npm run build-and-sync` to regenerate artifacts, sync the local marketplace copy, restart the worker, and clear the queue. Do not use plain `npm run build` for release validation because it can leave the local marketplace/worker out of sync.\n4. **Commit**: `git add -A && git commit -m \"chore: bump version to X.Y.Z\"`.\n5. **Tag**: `git tag -a vX.Y.Z -m \"Version X.Y.Z\"`.\n6. **Push**: `git push origin main && git push origin vX.Y.Z`.\n7. **GitHub release**: `gh release create vX.Y.Z --title \"vX.Y.Z\" --notes \"RELEASE_NOTES\"`.\n8. **Changelog**: Regenerate via the project's changelog script:\n ```bash\n npm run changelog:generate\n ```\n (Runs `node scripts/generate-changelog.js`, which pulls releases from the GitHub API and rewrites `CHANGELOG.md`.)\n9. **Sync changelog**: Commit and push the updated `CHANGELOG.md`.\n10. **Pre-handoff audit**: Verify the release commit, tag, GitHub release, and\n changelog are pushed; confirm the release worktree has no pending tracked\n changes; and ensure its build dependencies are present because\n `prepublishOnly` rebuilds the package. If `npm view claude-mem@X.Y.Z version`\n already resolves, skip the handoff and continue with post-publish checks.\n11. **Final human handoff — publish to npm.** Do not stop in the middle of the\n workflow for npm. Finish every agent-owned preparation above first, then\n make this the final human-required action.\n\n The human maintainer's credentials/2FA are required. The agent MUST NOT run\n `npm publish` (or `np` / `npm run release:*`, which also publish). Give the\n exact release-worktree path and this command as the only requested action:\n ```bash\n npm publish # run by the HUMAN — prepublishOnly rebuilds the package\n ```\n Wait for confirmation. Do not ask the human to perform any other release\n step afterward.\n12. **Post-publish verification and notification**: After confirmation, verify\n both the exact version and the latest dist-tag:\n ```bash\n npm view claude-mem@X.Y.Z version\n npm view claude-mem version\n ```\n If the publish build touched tracked artifacts, run `npm run build-and-sync`,\n review the result, and commit/push any legitimate changes. Then run the\n Discord notification from `~/Scripts/claude-mem/`, where the `.env` with\n webhook details lives:\n ```bash\n cd ~/Scripts/claude-mem/ && npm ","createdAt":"2026-09-25T10:51:51.854Z","updatedAt":"2026-09-25T10:51:51.854Z"},{"id":"cmuguciw30035qu06imgcgo2u","slug":"thedotmack-claude-mem-timeline-report","name":"timeline-report","description":"Generate a \"Journey Into [Project]\" narrative report analyzing a project's entire development history from claude-mem's timeline. Use when asked for a timeline report, project history analysis, development journey, or full project report.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"timeline-report","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Generate a \"Journey Into [Project]\" narrative report analyzing a project's entire development history from claude-mem's timeline. Use when asked for a timeline report, project history analysis, development journey, or full project report.","permissions":[],"systemPrompt":"# Timeline Report\n\nGenerate a comprehensive narrative analysis of a project's entire development history using claude-mem's persistent memory timeline.\n\n## When to Use\n\nUse when users ask for:\n\n- \"Write a timeline report\"\n- \"Journey into [project]\"\n- \"Analyze my project history\"\n- \"Full project report\"\n- \"Summarize the entire development history\"\n- \"What's the story of this project?\"\n\n## Prerequisites\n\nThe claude-mem worker must be running. The project must have claude-mem observations recorded.\n\n**Resolve the worker port** (do this once at the start and reuse `$WORKER_PORT` in every curl call below):\n\n```bash\nWORKER_PORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\n```\n\nThis honors `CLAUDE_MEM_WORKER_PORT` env, then `~/.claude-mem/settings.json`, then falls back to the per-UID default `37700 + (uid % 100)` — matching how the worker itself picks its port. Required for multi-account setups (#2101) and any user who has overridden the default port (#2103).\n\n## Workflow\n\n### Step 1: Determine the Project Name\n\nAsk the user which project to analyze if not obvious from context. The project name is typically the directory name of the project (e.g., \"tokyo\", \"my-app\"). If the user says \"this project\", use the current working directory's basename.\n\n**Worktree Detection:** Before using the directory basename, check if the current directory is a git worktree. In a worktree, the data source is the **parent project**, not the worktree directory itself. Run:\n\n```bash\ngit_dir=$(git rev-parse --git-dir 2>/dev/null)\ngit_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)\nif [ \"$git_dir\" != \"$git_common_dir\" ]; then\n # We're in a worktree — resolve the parent project name\n parent_project=$(basename \"$(dirname \"$git_common_dir\")\")\n echo \"Worktree detected. Parent project: $parent_project\"\nelse\n parent_project=$(basename \"$PWD\")\nfi\necho \"$parent_project\"\n```\n\nIf a worktree is detected, use `$parent_project` (the basename of the parent repo) as the project name for all API calls. Inform the user: \"Detected git worktree. Using parent project '[name]' as the data source.\"\n\n### Step 2: Fetch the Full Timeline\n\nUse Bash to fetch the complete timeline from the claude-mem worker API:\n\n```bash\ncurl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true\"\n```\n\nThis returns the entire compressed timeline -- every observation, session boundary, and summary across the project's full history. The response is pre-formatted markdown optimized for LLM consumption.\n\n**Token estimates:** The full timeline size depends on the project's history:\n- Small project (< 1,000 observations): ~20-50K tokens\n- Medium project (1,000-10,000 observations): ~50-300K tokens\n- Large project (10,000-35,000 observations): ~300-750K tokens\n\nIf the response is empty or returns an error, the worker may not be running or the project name may be wrong. Try `curl -s \"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\"` to verify the worker is healthy.\n\n### Step 3: Estimate Token Count\n\nBefore proceeding, estimate the token count of the fetched timeline (roughly 1 token per 4 characters). Report this to the user:\n\n```\nTimeline fetched: ~X observations, estimated ~Yk tokens.\nThis analysis will consume approximately Yk input tokens + ~5-10k output tokens.\nProceed? (y/n)\n```\n\nWait for user confirmation before continuing if the timeline exceeds 100K tokens.\n\n### Step 4: Analyze with a Subagent\n\nDeploy an Agent (using the Task tool) with the full timeline and the following analysis prompt. Pass the ENTIRE timeline as context to the agent. The agent should also be instructed to query the SQLite database at `~/.claude-mem/claude-mem.db` for the Token Economics section.\n\n**Agent prompt:**\n\n```\nYou are a technical historian analyzing a software project's complete development timeline from claude-mem's persistent memory system. The timeline below contains every observation, session boundary, and summary recorded across the project's entire history.\n\nYou also have access to the claude-mem SQLite database at ~/.claude-mem/claude-mem.db. Use it to run queries for the Token Economics & Memory ROI section. The database has an \"observations\" table with columns: id, memory_session_id, project, text, type, title, subtitle, facts, narrative, concepts, files_read, files_modified, prompt_number, discovery_tokens, created_at, created_at_epoch, content_hash, generated_by_model, relevance_count, merged_into_project, agent_type, agent_id, metadata.\n\nWrite a comprehensive narrative report titled \"Journey Into [PROJECT_NAME]\" that covers:\n\n## Required Sections\n\n1. **Project Genesis** -- When and how the project started. What were the first commits, the initial vision, the founding technical decisions? What problem was being solved?\n\n2. **Architectural Evolution** -- How did the architecture change over time? What were the major pivots? Why did they happen? Trace the evolution from initial design through each significant restructuring.\n\n3. **Key Breakthroughs** -- Identify the \"aha\" moments: when a difficult problem was finally solved, when a new approach unlocked progress, when a prototype first worked. These are the observations where the tone shifts from investigation to resolution.\n\n4. **Work Patterns** -- Analyze the rhythm of development. Identify debugging cycles (clusters of bug fixes), feature sprints (rapid observation sequences), refactoring phases (architectural changes without new features), and exploration phases (many discoveries without changes).\n\n5. **Technical Debt** -- Track where shortcuts were taken and when they were paid back. Identify patterns of accumulation (rapid feature work) and resolution (dedicated refactoring sessions).\n\n6. **Challenges and Debugging Sagas** -- The hardest problems encountered. Multi-session debugging efforts, architectural dead-ends that required backtracking, platform-specific issues that took days to resolve.\n\n7. **Memory and Continuity** -- How did persistent memory (claude-mem itself, if applicable) affect the development process? Were there moments where recalled context from prior sessions saved significant time or prevented repeated mistakes?\n\n8. **Token Economics & Memory ROI** -- Quantitative analysis of how memory recall saved work:\n - Query the database directly for these metrics using `sqlite3 ~/.claude-mem/claude-mem.db`\n - Count total discovery_tokens across all observations (the original cost of all work)\n - Count sessions that had context injection available (sessions after the first)\n - Calculate the compression ratio: average discovery_tokens vs average read_tokens per observation\n - Identify the highest-value observations (highest discovery_tokens -- these are the most expensive decisions, bugs, and discoveries that memory prevents re-doing)\n - Identify explicit recall events (observations where narrative mentions \"recalled\", \"from memory\", \"previous session\")\n - Estimate passive recall savings: each session with context injection receives ~50 observations. Use a 30% relevance factor (conservative estimate that 30% of injected context prevents re-work). Savings = sessions_with_context × avg_discovery_value_of_50_obs_window × 0.30\n - Estimate explicit recall savings: ~10K tokens per explicit recall query\n - Calculate net ROI: total_savings / total_read_tokens_invested\n - Present as a table with monthly breakdown\n - Highlight the top 5 most expensive observations by discovery_tokens -- these represent the highest-value memories in the system (architecture decisions, hard bugs, implementation plans that cost 100K+ tokens to produce originally)\n\n Use these SQL queries as a starting point:\n ```sql\n -- Total discovery tokens\n SELECT SUM(discovery_tokens) FROM observations WHERE project = 'PROJECT_NAME';\n\n -- Sessions with context available (not the first session)\n SELECT COUNT(DISTINCT memory_session_id) FROM observations WHERE project = 'PROJECT_NAME';\n\n -- Average tokens per observation\n SELECT AVG(discovery_tokens) as avg_discovery, AVG(LENGTH(title || COALESCE(subtitle,'') || COALESCE(narrative,'') || COALESCE(facts,'')) / 4) as avg_read FROM observations WHERE project = 'PROJECT_NAME' AND discovery_tokens > 0;\n\n -- Top 5 most expensive observations (highest-value memories)\n SELECT id, title, discovery_tokens FROM observations WHERE project = 'PROJECT_NAME' ORDER BY discovery_tokens DESC LIMIT 5;\n\n -- Monthly breakdown\n SELECT strftime('%Y-%m', created_at) as month, COUNT(*) as obs, SUM(discovery_tokens) as total_discovery, COUNT(DISTINCT memory_session_id) as sessions FROM observations WHERE project = 'PROJECT_NAME' GROUP BY month ORDER BY month;\n\n -- Explicit recall events\n SELECT COUNT(*) FROM observations WHERE project = 'PROJECT_NAME' AND (narrative LIKE '%recalled%' OR narrative LIKE '%from memory%' OR narrative LIKE '%previous session%');\n ```\n\n9. **Timeline Statistics** -- Quantitative summary:\n - Date range (first observation to last)\n - Total observations and sessions\n - Breakdown by observation type (features, bug fixes, discoveries, decisions, changes)\n - Most active days/weeks\n - Longest debugging sessions\n\n10. **Lessons and Meta-Observations** -- What patterns emerge from the full history? What would a new developer learn about this codebase from reading the timeline? What recurring themes or principles guided development?\n\n## Writing Style\n\n- Write as a technical narrative, not a list of bullet points\n- Use specific observation IDs and timestamps when referencing events (e.g., \"On Dec 14 (#26766), the root cause was finally identified...\")\n- Connect events across time -- show how early decisions created later consequences\n- Be honest about struggles and dead ends, not just successes\n- Target 3,000-6,000 words depending on project size\n- Use markdown formatting with headers, emphasis, and code references where appropriate\n\n## Important\n\n- Analyze the ENTIRE timeline chronologically -- do not skip early history\n- Look for narrative arcs: problem -> investigation -> solution\n- Identify turning points where the project's direction fundamentally changed\n- Note any observations about the development process itself (tooling, workflow, collaboration patterns)\n\nHere is the complete project timeline:\n\n[TIMELINE CONTENT GOES HERE]\n```\n\n### Step 5: Save the Report\n\nSave the agent's output as a markdown file. Default location:\n\n```\n./journey-into-PROJECT_NAME.md\n```\n\nOr if the user specified a different output path, use that instead.\n\n### Step 6: Report Completion\n\nTell the user:\n- Where the report was saved\n- The approximate token cost (input timeline + output report)\n- The date range covered\n- Number of observations analyzed\n\n## Error Handling\n\n- **Empty timeline:** \"No observations found for project 'X'. Check the project name with: `curl -s \\\"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\\\"`\"\n- **Worker not running:** \"The claude-mem worker is not responding on port ${WORKER_PORT}. Start it with your usual method or check `ps aux | grep worker-service`.\"\n- **Timeline too large:** For projects with 50,000+ observations, the timeline may exceed context limits. Suggest using date range filtering: `curl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=X&full=true\"` -- the current endpoint returns all observations; for extremely large projects, the user may want to analyze in time-windowed segments.\n\n## Example\n\nUser: \"Write a journey report for the tokyo project\"\n\n1. Fetch: `curl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=tokyo&full=true\"`\n2. Estimate: \"Timeline fetched: ~34,722 observations, estimated ~718K tokens. Proceed?\"\n3. User confirms\n4. Deploy analysis agent with full timeline\n5. Save to `./journey-into-tokyo.md`\n6. Report: \"Report saved. Analyzed 34,722 observations spanning Oct 2025 - Mar 2026 (~718K input tokens, ~8K output tokens).\"","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/timeline-report","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/timeline-report/SKILL.md","defaultBranch":"main"},"readme":"# Timeline Report\n\nGenerate a comprehensive narrative analysis of a project's entire development history using claude-mem's persistent memory timeline.\n\n## When to Use\n\nUse when users ask for:\n\n- \"Write a timeline report\"\n- \"Journey into [project]\"\n- \"Analyze my project history\"\n- \"Full project report\"\n- \"Summarize the entire development history\"\n- \"What's the story of this project?\"\n\n## Prerequisites\n\nThe claude-mem worker must be running. The project must have claude-mem observations recorded.\n\n**Resolve the worker port** (do this once at the start and reuse `$WORKER_PORT` in every curl call below):\n\n```bash\nWORKER_PORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\n```\n\nThis honors `CLAUDE_MEM_WORKER_PORT` env, then `~/.claude-mem/settings.json`, then falls back to the per-UID default `37700 + (uid % 100)` — matching how the worker itself picks its port. Required for multi-account setups (#2101) and any user who has overridden the default port (#2103).\n\n## Workflow\n\n### Step 1: Determine the Project Name\n\nAsk the user which project to analyze if not obvious from context. The project name is typically the directory name of the project (e.g., \"tokyo\", \"my-app\"). If the user says \"this project\", use the current working directory's basename.\n\n**Worktree Detection:** Before using the directory basename, check if the current directory is a git worktree. In a worktree, the data source is the **parent project**, not the worktree directory itself. Run:\n\n```bash\ngit_dir=$(git rev-parse --git-dir 2>/dev/null)\ngit_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)\nif [ \"$git_dir\" != \"$git_common_dir\" ]; then\n # We're in a worktree — resolve the parent project name\n parent_project=$(basename \"$(dirname \"$git_common_dir\")\")\n echo \"Worktree detected. Parent project: $parent_project\"\nelse\n parent_project=$(basename \"$PWD\")\nfi\necho \"$parent_project\"\n```\n\nIf a worktree is detected, use `$parent_project` (the basename of the parent repo) as the project name for all API calls. Inform the user: \"Detected git worktree. Using parent project '[name]' as the data source.\"\n\n### Step 2: Fetch the Full Timeline\n\nUse Bash to fetch the complete timeline from the claude-mem worker API:\n\n```bash\ncurl -s \"http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true\"\n```\n\nThis returns the entire compressed timeline -- every observation, session boundary, and summary across the project's full history. The response is pre-formatted markdown optimized for LLM consumption.\n\n**Token estimates:** The full timeline size depends on the project's history:\n- Small project (< 1,000 observations): ~20-50K tokens\n- Medium project (1,000-10,000 observations): ~50-300K tokens\n- Large project (10,000-35,000 observations): ~300-750K tokens\n\nIf the response is empty or returns an error, the worker may not be running or the project name may be wrong. Try `curl -s \"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\"` to verify the worker is healthy.\n\n### Step 3: Estimate Token Count\n\nBefore proceeding, estimate the token count of the fetched timeline (roughly 1 token per 4 characters). Report this to the user:\n\n```\nTimeline fetched: ~X observations, estimated ~Yk tokens.\nThis analysis will consume approximately Yk input tokens + ~5-10k output tokens.\nProceed? (y/n)\n```\n\nWait for user confirmation before continuing if the timeline exceeds 100K tokens.\n\n### Step 4: Analyze with a Subagent\n\nDeploy an Agent (using the Task tool) with the full timeline and the following analysis prompt. Pass the ENTIRE timeline as context to the agent. The agent should also be instructed to ","createdAt":"2026-09-25T10:51:51.844Z","updatedAt":"2026-09-25T10:51:51.844Z"},{"id":"cmugucivs0032qu06sc8kdosa","slug":"thedotmack-claude-mem-standup","name":"standup","description":"Facilitate a read-only standup across git worktrees, branches, or PRs to compare changes and produce one consolidation plan.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"standup","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Facilitate a read-only standup across git worktrees, branches, or PRs to compare changes and produce one consolidation plan.","permissions":["shell"],"systemPrompt":"# standup — facilitate a group chat between branch-agents\n\nYou're the **facilitator**. Each of the user's git worktrees (and any PRs they\npick) joins a shared markdown chat as its own agent, and the agents reconcile\ntheir scattered work into ONE consolidated worktree. You convene the room, run\nthe conversation in rounds, and carry the outcome back — the reconciling happens\nin the chat, between the agents.\n\nThe room is one shared file (default `~/.claude-mem/STANDUP.md`): YAML front\nmatter holds the `goal` + `prompt`; the body is the transcript. Writes are\natomically locked, so agents speak at once. It is **read-only** — agents decide\nhow the merge *should* go; nobody commits or merges inside the room. Real git\nwork happens afterward via `/do`.\n\n## 1. Fill the room\n\nTwo ways, mixable:\n\n- **By recency** (common) — worktrees active in a window:\n ```bash\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" worktrees --since <1h|4h|24h|7d|all> --json\n ```\n Active = a commit *or* an uncommitted/staged/untracked edit in the window. If\n the user didn't name a window, offer 1h / 4h / 24h / 7d / all.\n\n- **By hand** — specific branches and/or open PRs:\n ```bash\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" worktrees --json # local branches\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" prs --json # open PRs (via gh)\n ```\n Show one numbered list (worktrees + PRs, with age/title); their reply is the\n \"checkbox.\" If `prs` errors (no `gh` / not GitHub), carry on worktrees-only.\n\nZero or one candidate isn't a standup — say so, offer to widen, stop. Otherwise\necho the roster to confirm before you start.\n\n## 2. Open the room\n\nSet a goal + prompt that invite a conversation, not one-shot status reports:\n\n```bash\nnode \"${CLAUDE_SKILL_DIR}/standup.mjs\" open --force --agent facilitator \\\n --goal \"Collapse these branches/PRs into ONE consolidated worktree: what each changed, where they overlap, which becomes the target, and the merge order.\" \\\n --prompt \"Facilitated rounds. Round 1: introduce your branch and its state. Then resolve the conflicts the facilitator surfaces, round by round, until the room lands on one concrete plan (target worktree + merge order + conflict resolutions). Read-only: decide, don't merge. Register AGREE when you back the plan.\"\n```\n\n## 3. Run it as rounds\n\nYou drive the turns — if agents watch-loop on their own the room can stall with\nnothing decided. Each agent speaks once per round (read → post → return); you\nread between rounds and bring back whoever's still needed.\n\nSpawned agents don't inherit `CLAUDE_SKILL_DIR`, so resolve it once and paste the\nreal path into each brief:\n```bash\necho \"${CLAUDE_SKILL_DIR}\"\n```\n\n**Round 1 — intros (everyone, one Task message so they run together).** Brief\neach:\n\n> You're **`<branch>`** (a PR is **`pr-<number>`**) in a standup group chat. Read\n> `<skill-dir>/agent-brief.md` and play your part by it. The room is\n> `~/.claude-mem/STANDUP.md`; speak with `node \"<skill-dir>/standup.mjs\" post …`,\n> catch up with `… read`. Get your bearings (`cd \"<path>\"`,\n> `git log --oneline origin/main..HEAD`, `git status --short`,\n> `git diff --stat origin/main...HEAD`; a PR uses `gh pr view/diff <number>`),\n> then post ONE turn: your branch, its real state, and how it should fold in.\n> Read-only. Then return.\n\n**Reconcile.** Once they've returned, `read` the room and list the **open\nitems** — overlaps, conflicts, competing implementations, undecided\ntarget/order. None? Skip to the close.\n\n**Resolution rounds (cap ~4).** Per open item, re-spawn only the agents it\nimplicates, with the specific question. Tell them to `read --since <their-name>`\nfirst, then post their position and `--agree` if convinced. `read` again, update\nthe list. Repeat.\n\n**Close — you always write it.** Stop when the list is empty, you hit the cap, or\nan agent errors (note \"didn't report,\" don't block). Then write the SUMMATION\nyourself — don't wait for an agent to volunteer. Write it as plain prose a human\ncan skim, not a field dump: which worktree is the target and why, the merge order\nin a sentence, and what's left for the human:\n```bash\nnode \"${CLAUDE_SKILL_DIR}/standup.mjs\" summation --agent facilitator \\\n --text \"Build on <worktree> — it's the only one with real code. Layer <branch>'s changes on top, then drop in the doc-only branches; skip <empty branch>. Your call before it's safe: <the one or two real decisions>. Done when it all sits in <target> and builds clean.\"\n```\n\n## 4. Brief the human in plain language\n\nThis is the payoff — don't hand them the raw SUMMATION, **translate it.** A human\nwho didn't watch the room should understand the outcome without decoding paths,\nline counts, or commit hashes. Lead with the answer, then the few choices only\nthey can make:\n\n- **What you found** — one plain line per branch: who has real code, who's just\n docs, who's empty.\n- **The plan** — target + merge order in a sentence or two.\n- **Their call** — only the decisions a human must make (which implementation\n wins, what to drop, anything risky), as concrete questions. Use\n `AskUserQuestion` for the clear-cut ones.\n\nKeep git internals out unless they ask. Once they've settled the open calls, hand\nthe plan to **`/do`** to perform the merges — don't merge anything yourself\noutside `/do`.\n\n## CLI\n\n```bash\nnode \"${CLAUDE_SKILL_DIR}/standup.mjs\" <command> [--flags]\n```\nDefaults: agent = git branch, file = `~/.claude-mem/STANDUP.md`. Every write is\natomically locked.\n\n| command | what it does |\n|---|---|\n| `worktrees [--since 4h] [--json]` | worktrees newest-first; `--since N{m,h,d,w}` keeps those active in the window |\n| `prs [--since 4h] [--json]` | open GitHub PRs (via `gh`) newest-first |\n| `open --goal \"…\" --prompt \"…\" [--force]` | create the room (`--force` rotates an old one aside) |\n| `join [--message \"…\"]` | add yourself + say Hello |\n| `post --message \"…\" [--agree \"…\"]` | append a turn |\n| `agree --deliverable \"…\"` | append an AGREE turn |\n| `watch [--timeout SEC] [--interval SEC]` | block until someone else posts, print it (exit 2 on timeout) |\n| `read [--tail N] [--since AGENT]` | print the chat (or only turns after AGENT's last) |\n| `status` | participants + AGREEs + consensus check |\n| `summation --text \"…\"` | write the SUMMATION, flip `status: agreed` |\n\nEach spawned agent plays its turns by **`agent-brief.md`** (bundled here) — the\nplaybook for being one voice in the room.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/standup","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/standup/SKILL.md","defaultBranch":"main"},"readme":"# standup — facilitate a group chat between branch-agents\n\nYou're the **facilitator**. Each of the user's git worktrees (and any PRs they\npick) joins a shared markdown chat as its own agent, and the agents reconcile\ntheir scattered work into ONE consolidated worktree. You convene the room, run\nthe conversation in rounds, and carry the outcome back — the reconciling happens\nin the chat, between the agents.\n\nThe room is one shared file (default `~/.claude-mem/STANDUP.md`): YAML front\nmatter holds the `goal` + `prompt`; the body is the transcript. Writes are\natomically locked, so agents speak at once. It is **read-only** — agents decide\nhow the merge *should* go; nobody commits or merges inside the room. Real git\nwork happens afterward via `/do`.\n\n## 1. Fill the room\n\nTwo ways, mixable:\n\n- **By recency** (common) — worktrees active in a window:\n ```bash\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" worktrees --since <1h|4h|24h|7d|all> --json\n ```\n Active = a commit *or* an uncommitted/staged/untracked edit in the window. If\n the user didn't name a window, offer 1h / 4h / 24h / 7d / all.\n\n- **By hand** — specific branches and/or open PRs:\n ```bash\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" worktrees --json # local branches\n node \"${CLAUDE_SKILL_DIR}/standup.mjs\" prs --json # open PRs (via gh)\n ```\n Show one numbered list (worktrees + PRs, with age/title); their reply is the\n \"checkbox.\" If `prs` errors (no `gh` / not GitHub), carry on worktrees-only.\n\nZero or one candidate isn't a standup — say so, offer to widen, stop. Otherwise\necho the roster to confirm before you start.\n\n## 2. Open the room\n\nSet a goal + prompt that invite a conversation, not one-shot status reports:\n\n```bash\nnode \"${CLAUDE_SKILL_DIR}/standup.mjs\" open --force --agent facilitator \\\n --goal \"Collapse these branches/PRs into ONE consolidated worktree: what each changed, where they overlap, which becomes the target, and the merge order.\" \\\n --prompt \"Facilitated rounds. Round 1: introduce your branch and its state. Then resolve the conflicts the facilitator surfaces, round by round, until the room lands on one concrete plan (target worktree + merge order + conflict resolutions). Read-only: decide, don't merge. Register AGREE when you back the plan.\"\n```\n\n## 3. Run it as rounds\n\nYou drive the turns — if agents watch-loop on their own the room can stall with\nnothing decided. Each agent speaks once per round (read → post → return); you\nread between rounds and bring back whoever's still needed.\n\nSpawned agents don't inherit `CLAUDE_SKILL_DIR`, so resolve it once and paste the\nreal path into each brief:\n```bash\necho \"${CLAUDE_SKILL_DIR}\"\n```\n\n**Round 1 — intros (everyone, one Task message so they run together).** Brief\neach:\n\n> You're **`<branch>`** (a PR is **`pr-<number>`**) in a standup group chat. Read\n> `<skill-dir>/agent-brief.md` and play your part by it. The room is\n> `~/.claude-mem/STANDUP.md`; speak with `node \"<skill-dir>/standup.mjs\" post …`,\n> catch up with `… read`. Get your bearings (`cd \"<path>\"`,\n> `git log --oneline origin/main..HEAD`, `git status --short`,\n> `git diff --stat origin/main...HEAD`; a PR uses `gh pr view/diff <number>`),\n> then post ONE turn: your branch, its real state, and how it should fold in.\n> Read-only. Then return.\n\n**Reconcile.** Once they've returned, `read` the room and list the **open\nitems** — overlaps, conflicts, competing implementations, undecided\ntarget/order. None? Skip to the close.\n\n**Resolution rounds (cap ~4).** Per open item, re-spawn only the agents it\nimplicates, with the specific question. Tell them to `read --since <their-name>`\nfirst, then post their position and `--agree` if convinced. `read` again, update\nthe list. Repeat.\n\n**Close — you always write it.** Stop when the list is empty, you hit the cap, or\nan agent errors (note \"didn't report,\" don't block). Then write the SUMMATION\nyourself — don't wait for an agent to volunteer. Write it as plain prose a human\ncan skim, not a field dump: which","createdAt":"2026-09-25T10:51:51.832Z","updatedAt":"2026-09-25T10:51:51.832Z"},{"id":"cmugucivf002zqu06jwryb4c1","slug":"thedotmack-claude-mem-smart-explore","name":"smart-explore","description":"Token-optimized structural code search using tree-sitter AST parsing. Use instead of reading full files when you need to understand code structure, find functions, or explore a codebase efficiently.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"smart-explore","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Token-optimized structural code search using tree-sitter AST parsing. Use instead of reading full files when you need to understand code structure, find functions, or explore a codebase efficiently.","permissions":[],"systemPrompt":"# Smart Explore\n\nStructural code exploration using AST parsing. **This skill overrides your default exploration behavior.** While this skill is active, use smart_search/smart_outline/smart_unfold as your primary tools instead of Read, Grep, and Glob.\n\n**Core principle:** Index first, fetch on demand. Give yourself a map of the code before loading implementation details. The question before every file read should be: \"do I need to see all of this, or can I get a structural overview first?\" The answer is almost always: get the map.\n\n## Your Next Tool Call\n\nThis skill only loads instructions. You must call the MCP tools yourself. Your next action should be one of:\n\n```\nsmart_search(query=\"<topic>\", path=\"./src\") -- discover files + symbols across a directory\nsmart_outline(file_path=\"<file>\") -- structural skeleton of one file\nsmart_unfold(file_path=\"<file>\", symbol_name=\"<name>\") -- full source of one symbol\n```\n\nDo NOT run Grep, Glob, Read, or find to discover files first. `smart_search` walks directories, parses all code files, and returns ranked symbols in one call. It replaces the Glob → Grep → Read discovery cycle.\n\n## 3-Layer Workflow\n\n### Step 1: Search -- Discover Files and Symbols\n\n```\nsmart_search(query=\"shutdown\", path=\"./src\", max_results=15)\n```\n\n**Returns:** Ranked symbols with signatures, line numbers, match reasons, plus folded file views (~2-6k tokens)\n\n```\n-- Matching Symbols --\n function performGracefulShutdown (services/infrastructure/GracefulShutdown.ts:56)\n function httpShutdown (services/infrastructure/HealthMonitor.ts:92)\n method WorkerService.shutdown (services/worker-service.ts:846)\n\n-- Folded File Views --\n services/infrastructure/GracefulShutdown.ts (7 symbols)\n services/worker-service.ts (12 symbols)\n```\n\nThis is your discovery tool. It finds relevant files AND shows their structure. No Glob/find pre-scan needed.\n\n**Parameters:**\n\n- `query` (string, required) -- What to search for (function name, concept, class name)\n- `path` (string) -- Root directory to search (defaults to cwd)\n- `max_results` (number) -- Max matching symbols, default 20, max 50\n- `file_pattern` (string, optional) -- Filter to specific files/paths\n\n### Step 2: Outline -- Get File Structure\n\n```\nsmart_outline(file_path=\"services/worker-service.ts\")\n```\n\n**Returns:** Complete structural skeleton -- all functions, classes, methods, properties, imports (~1-2k tokens per file)\n\n**Skip this step** when Step 1's folded file views already provide enough structure. Most useful for files not covered by the search results.\n\n**Parameters:**\n\n- `file_path` (string, required) -- Path to the file\n\n### Step 3: Unfold -- See Implementation\n\nReview symbols from Steps 1-2. Pick the ones you need. Unfold only those:\n\n```\nsmart_unfold(file_path=\"services/worker-service.ts\", symbol_name=\"shutdown\")\n```\n\n**Returns:** Full source code of the specified symbol including JSDoc, decorators, and complete implementation (~400-2,100 tokens depending on symbol size). AST node boundaries guarantee completeness regardless of symbol size — unlike Read + agent summarization, which may truncate long methods.\n\n**Parameters:**\n\n- `file_path` (string, required) -- Path to the file (as returned by search/outline)\n- `symbol_name` (string, required) -- Name of the function/class/method to expand\n\n## When to Use Standard Tools Instead\n\nUse these only when smart_* tools are the wrong fit:\n\n- **Grep:** Exact string/regex search (\"find all TODO comments\", \"where is `ensureWorkerStarted` defined?\")\n- **Read:** Small files under ~100 lines, non-code files (JSON, markdown, config)\n- **Glob:** File path patterns (\"find all test files\")\n- **Explore agent:** When you need synthesized understanding across 6+ files, architecture narratives, or answers to open-ended questions like \"how does this entire system work end-to-end?\" Smart-explore is a scalpel — it answers \"where is this?\" and \"show me that.\" It doesn't synthesize cross-file data flows, design decisions, or edge cases across an entire feature.\n\nFor code files over ~100 lines, prefer smart_outline + smart_unfold over Read.\n\n## Workflow Examples\n\n**Discover how a feature works (cross-cutting):**\n\n```\n1. smart_search(query=\"shutdown\", path=\"./src\")\n -> 14 symbols across 7 files, full picture in one call\n2. smart_unfold(file_path=\"services/infrastructure/GracefulShutdown.ts\", symbol_name=\"performGracefulShutdown\")\n -> See the core implementation\n```\n\n**Navigate a large file:**\n\n```\n1. smart_outline(file_path=\"services/worker-service.ts\")\n -> 1,466 tokens: 12 functions, WorkerService class with 24 members\n2. smart_unfold(file_path=\"services/worker-service.ts\", symbol_name=\"startSessionProcessor\")\n -> 1,610 tokens: the specific method you need\nTotal: ~3,076 tokens vs ~12,000 to Read the full file\n```\n\n**Write documentation about code (hybrid workflow):**\n\n```\n1. smart_search(query=\"feature name\", path=\"./src\") -- discover all relevant files and symbols\n2. smart_outline on key files -- understand structure\n3. smart_unfold on important functions -- get implementation details\n4. Read on small config/markdown/plan files -- get non-code context\n```\n\nUse smart_* tools for code exploration, Read for non-code files. Mix freely.\n\n**Exploration then precision:**\n\n```\n1. smart_search(query=\"session\", path=\"./src\", max_results=10)\n -> 10 ranked symbols: SessionMetadata, SessionQueueProcessor, SessionSummary...\n2. Pick the relevant one, unfold it\n```\n\n## Token Economics\n\n| Approach | Tokens | Use Case |\n|----------|--------|----------|\n| smart_outline | ~1,000-2,000 | \"What's in this file?\" |\n| smart_unfold | ~400-2,100 | \"Show me this function\" |\n| smart_search | ~2,000-6,000 | \"Find all X across the codebase\" |\n| search + unfold | ~3,000-8,000 | End-to-end: find and read (the primary workflow) |\n| Read (full file) | ~12,000+ | When you truly need everything |\n| Explore agent | ~39,000-59,000 | Cross-file synthesis with narrative |\n\n**4-8x savings** on file understanding (outline + unfold vs Read). **11-18x savings** on codebase exploration vs Explore agent. The narrower the query, the wider the gap — a 27-line function costs 55x less to read via unfold than via an Explore agent, because the agent still reads the entire file.\n\n## Language Support\n\nSmart-explore uses **tree-sitter AST parsing** for structural analysis. Unsupported file types fall back to text-based search.\n\n### Bundled Languages\n\n| Language | Extensions |\n|----------|-----------|\n| JavaScript | `.js`, `.mjs`, `.cjs` |\n| TypeScript | `.ts` |\n| TSX / JSX | `.tsx`, `.jsx` |\n| Python | `.py`, `.pyw` |\n| Go | `.go` |\n| Rust | `.rs` |\n| Ruby | `.rb` |\n| Java | `.java` |\n| C | `.c`, `.h` |\n| C++ | `.cpp`, `.cc`, `.cxx`, `.hpp`, `.hh` |\n\nFiles with unrecognized extensions are parsed as plain text — `smart_search` still works (grep-style), but `smart_outline` and `smart_unfold` will not extract structured symbols.\n\n### Custom Grammars (`.claude-mem.json`)\n\nYou can register additional tree-sitter grammars for file types not in the bundled list. Create or update `.claude-mem.json` in your project root:\n\n```json\n{\n \"grammars\": {\n \"solidity\": {\n \"package\": \"tree-sitter-solidity\",\n \"extensions\": [\".sol\"],\n \"query\": \"solidity-query.scm\"\n }\n }\n}\n```\n\nEach key is a language name. `package` is the npm package of the tree-sitter grammar and `extensions` lists the file extensions it covers; the package must be installed in the project's `node_modules` (`npm install tree-sitter-solidity`). `query` (optional) is a path, relative to the config file, to a tree-sitter query whose captures (`@func`, `@cls`, `@method`, `@iface`, `@enm`, `@struct_def`, `@imp`) extract symbols. Without `query`, a minimal generic pattern is used — it only matches grammars that define `function_declaration`/`class_declaration` node types, and query compilation fails silently (0 symbols) for grammars that lack them, so a custom query is effectively required for most languages. Once registered, `smart_outline` and `smart_unfold` parse those extensions structurally instead of falling back to plain text.\n\n### Markdown Special Support\n\nMarkdown files (`.md`, `.mdx`) receive special handling beyond the generic plain-text fallback:\n\n- **`smart_outline`** — extracts headings (`#`, `##`, `###`) as the symbol tree. Use it to navigate long documents without reading the full file.\n- **`smart_search`** — searches within code fences as well as prose, so queries for function names inside ` ```ts ``` ` blocks work as expected.\n- **`smart_unfold`** — expands heading sections rather than function bodies; each section up to the next same-level heading is returned as a chunk.\n- **Frontmatter** — YAML frontmatter (lines between leading `---` delimiters) is included in `smart_outline` output under a synthetic `frontmatter` symbol so metadata like `title:` and `description:` is visible without reading the whole file.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/smart-explore","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/smart-explore/SKILL.md","defaultBranch":"main"},"readme":"# Smart Explore\n\nStructural code exploration using AST parsing. **This skill overrides your default exploration behavior.** While this skill is active, use smart_search/smart_outline/smart_unfold as your primary tools instead of Read, Grep, and Glob.\n\n**Core principle:** Index first, fetch on demand. Give yourself a map of the code before loading implementation details. The question before every file read should be: \"do I need to see all of this, or can I get a structural overview first?\" The answer is almost always: get the map.\n\n## Your Next Tool Call\n\nThis skill only loads instructions. You must call the MCP tools yourself. Your next action should be one of:\n\n```\nsmart_search(query=\"<topic>\", path=\"./src\") -- discover files + symbols across a directory\nsmart_outline(file_path=\"<file>\") -- structural skeleton of one file\nsmart_unfold(file_path=\"<file>\", symbol_name=\"<name>\") -- full source of one symbol\n```\n\nDo NOT run Grep, Glob, Read, or find to discover files first. `smart_search` walks directories, parses all code files, and returns ranked symbols in one call. It replaces the Glob → Grep → Read discovery cycle.\n\n## 3-Layer Workflow\n\n### Step 1: Search -- Discover Files and Symbols\n\n```\nsmart_search(query=\"shutdown\", path=\"./src\", max_results=15)\n```\n\n**Returns:** Ranked symbols with signatures, line numbers, match reasons, plus folded file views (~2-6k tokens)\n\n```\n-- Matching Symbols --\n function performGracefulShutdown (services/infrastructure/GracefulShutdown.ts:56)\n function httpShutdown (services/infrastructure/HealthMonitor.ts:92)\n method WorkerService.shutdown (services/worker-service.ts:846)\n\n-- Folded File Views --\n services/infrastructure/GracefulShutdown.ts (7 symbols)\n services/worker-service.ts (12 symbols)\n```\n\nThis is your discovery tool. It finds relevant files AND shows their structure. No Glob/find pre-scan needed.\n\n**Parameters:**\n\n- `query` (string, required) -- What to search for (function name, concept, class name)\n- `path` (string) -- Root directory to search (defaults to cwd)\n- `max_results` (number) -- Max matching symbols, default 20, max 50\n- `file_pattern` (string, optional) -- Filter to specific files/paths\n\n### Step 2: Outline -- Get File Structure\n\n```\nsmart_outline(file_path=\"services/worker-service.ts\")\n```\n\n**Returns:** Complete structural skeleton -- all functions, classes, methods, properties, imports (~1-2k tokens per file)\n\n**Skip this step** when Step 1's folded file views already provide enough structure. Most useful for files not covered by the search results.\n\n**Parameters:**\n\n- `file_path` (string, required) -- Path to the file\n\n### Step 3: Unfold -- See Implementation\n\nReview symbols from Steps 1-2. Pick the ones you need. Unfold only those:\n\n```\nsmart_unfold(file_path=\"services/worker-service.ts\", symbol_name=\"shutdown\")\n```\n\n**Returns:** Full source code of the specified symbol including JSDoc, decorators, and complete implementation (~400-2,100 tokens depending on symbol size). AST node boundaries guarantee completeness regardless of symbol size — unlike Read + agent summarization, which may truncate long methods.\n\n**Parameters:**\n\n- `file_path` (string, required) -- Path to the file (as returned by search/outline)\n- `symbol_name` (string, required) -- Name of the function/class/method to expand\n\n## When to Use Standard Tools Instead\n\nUse these only when smart_* tools are the wrong fit:\n\n- **Grep:** Exact string/regex search (\"find all TODO comments\", \"where is `ensureWorkerStarted` defined?\")\n- **Read:** Small files under ~100 lines, non-code files (JSON, markdown, config)\n- **Glob:** File path patterns (\"find all test files\")\n- **Explore agent:** When you need synthesized understanding across 6+ files, architecture narratives, or answers to open-ended questions like \"how does this entire system work end-to-end?\" Smart-explore is a scalpel — it answers \"where is this?\" and \"show me that.\" It doesn't synthesize cross-file data flows, design decisions, o","createdAt":"2026-09-25T10:51:51.820Z","updatedAt":"2026-09-25T10:51:51.820Z"},{"id":"cmuguciv2002wqu06j29uqu7g","slug":"thedotmack-claude-mem-pathfinder","name":"pathfinder","description":"Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to \"find the ideal path,\" unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus per-system /make-plan prompts.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"pathfinder","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to \"find the ideal path,\" unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus per-system /make-plan prompts.","permissions":[],"systemPrompt":"# Pathfinder\n\nYou are an ORCHESTRATOR. Map the codebase into feature-grouped flowcharts, identify duplicated concerns, propose the simplest unified architecture, and hand off per-system plans to `/make-plan`.\n\nYou do not write implementation code. You produce diagrams, a duplication report, a proposed unified flowchart, and handoff prompts.\n\n## Delegation Model\n\nUse subagents for *discovery and extraction* (file reading, flow tracing, grep, diagramming). Keep *synthesis* (deciding feature boundaries, picking unification strategies, final flowchart) with the orchestrator. Reject subagent reports that lack source citations and redeploy.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach subagent response must include:\n1. Sources consulted — exact file paths and line ranges read\n2. Concrete findings — exact function names, call sites, data flow\n3. Mermaid diagram(s) with nodes labeled by `file:line`\n4. Confidence note + known gaps\n\n## Output Artifacts\n\nAll artifacts go in `PATHFINDER-<YYYY-MM-DD>/` at repo root:\n- `00-features.md` — feature inventory with boundaries\n- `01-flowcharts/<feature>.md` — one Mermaid flowchart per feature\n- `02-duplication-report.md` — cross-cutting duplicated concerns with evidence\n- `03-unified-proposal.md` — proposed unified architecture + Mermaid\n- `04-handoff-prompts.md` — copy-pasteable `/make-plan` prompts per unified system\n\n## Phases\n\n### Phase 0: Feature Discovery (ALWAYS FIRST)\n\nDeploy ONE \"Feature Discovery\" subagent to:\n1. Walk the source tree (not built artifacts) and read top-level README / CLAUDE.md\n2. Propose feature boundaries based on directory structure, import graph, and naming\n3. Return a flat list of features with: name, entry points (file:line), core files, brief purpose\n\nOrchestrator reviews the proposal, adjusts boundaries if needed, writes `00-features.md`. Do NOT fan out until feature boundaries are approved.\n\n### Phase 1: Per-Feature Flowcharts (FAN OUT)\n\nDeploy ONE \"Flowchart\" subagent per feature in parallel. Each receives only its feature's scope. Each must:\n1. Trace the feature's primary happy path from entry point to terminal state\n2. Identify side effects (DB writes, HTTP calls, file I/O, process spawns)\n3. Note error and fallback branches but do not let them dominate the diagram\n4. Produce a Mermaid `flowchart TD` with every node labeled `Name<br/>file:line`\n5. List external dependencies (other features it calls into) at the bottom\n\nOrchestrator writes each flowchart to `01-flowcharts/<feature>.md`. Reject any diagram missing `file:line` labels.\n\n### Phase 2: Duplication Hunt\n\nDeploy TWO subagents in parallel:\n\n**\"Within-Feature Duplication\"** subagent:\n- For each feature, find repeated code/logic patterns inside the feature only\n- Report only duplications worth consolidating (ignore trivial repetition)\n\n**\"Cross-Feature Duplication\"** subagent:\n- Compare flowcharts across features for concerns that appear in multiple places\n- Examples of what to look for: multiple capture paths, parallel queue implementations, duplicated storage/migration code, repeated agent scaffolding, parallel parsing layers\n- For each duplication, report: (a) the concern, (b) every location with `file:line`, (c) why they diverged, (d) whether the divergence is legitimate specialization or accidental\n\nOrchestrator synthesizes both into `02-duplication-report.md`. Every duplication claim must cite ≥2 `file:line` locations.\n\n### Phase 3: Unified Proposal (ORCHESTRATOR)\n\nThe orchestrator writes `03-unified-proposal.md` itself — do not delegate synthesis.\n\nFor each duplicated concern from Phase 2 that is NOT legitimate specialization:\n1. Propose the simplest unified design (one path, one store, one handler — whatever applies)\n2. Name the consolidated component and its single entry point\n3. Show what each old call site becomes\n4. Call out any loss of capability and whether it's acceptable\n\nEnd the document with ONE combined Mermaid flowchart showing the proposed unified system. Nodes still labeled with target `file:line` (new or existing) where knowable.\n\n**Anti-patterns to reject in your own proposal:**\n- Adding a new abstraction layer \"for flexibility\"\n- Keeping both old paths behind a feature flag\n- Introducing a registry/factory when a switch statement suffices\n- Preserving divergent behavior \"just in case\"\n\n### Phase 4: Per-System Handoff Prompts\n\nFor each unified system in the proposal, write a ready-to-run `/make-plan` prompt to `04-handoff-prompts.md`. Each prompt must:\n1. State the target unified component and its single entry point\n2. List the exact call sites to rewrite (from Phase 2 evidence)\n3. Cite the relevant flowchart file from `01-flowcharts/`\n4. Include anti-pattern guards specific to this system\n\nFormat each as a fenced code block the user can copy directly into `/make-plan`.\n\n## Key Principles\n\n- **Evidence over intuition** — every diagram node and duplication claim cites `file:line`\n- **Current state before ideal state** — Phases 0–2 describe what IS; Phase 3 describes what SHOULD BE\n- **Simplest unification wins** — prefer deletion over abstraction; prefer one path over configurable paths\n- **Specialization is not duplication** — two components serving different trust models or data sources are legitimate even if their code looks similar\n- **Handoff, don't implement** — Pathfinder ends at plan prompts; `/make-plan` and `/do` take it from there\n\n## Failure Modes to Prevent\n\n- Drawing flowcharts from memory instead of source — redeploy subagent with grep evidence requirement\n- Proposing unification of legitimately specialized components — re-examine trust/data-source divergence\n- Handoff prompts that lack concrete call sites — rewrite with Phase 2 evidence\n- Skipping Phase 0 boundary review — fanning out on bad feature boundaries wastes all of Phase 1","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/pathfinder","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/pathfinder/SKILL.md","defaultBranch":"main"},"readme":"# Pathfinder\n\nYou are an ORCHESTRATOR. Map the codebase into feature-grouped flowcharts, identify duplicated concerns, propose the simplest unified architecture, and hand off per-system plans to `/make-plan`.\n\nYou do not write implementation code. You produce diagrams, a duplication report, a proposed unified flowchart, and handoff prompts.\n\n## Delegation Model\n\nUse subagents for *discovery and extraction* (file reading, flow tracing, grep, diagramming). Keep *synthesis* (deciding feature boundaries, picking unification strategies, final flowchart) with the orchestrator. Reject subagent reports that lack source citations and redeploy.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach subagent response must include:\n1. Sources consulted — exact file paths and line ranges read\n2. Concrete findings — exact function names, call sites, data flow\n3. Mermaid diagram(s) with nodes labeled by `file:line`\n4. Confidence note + known gaps\n\n## Output Artifacts\n\nAll artifacts go in `PATHFINDER-<YYYY-MM-DD>/` at repo root:\n- `00-features.md` — feature inventory with boundaries\n- `01-flowcharts/<feature>.md` — one Mermaid flowchart per feature\n- `02-duplication-report.md` — cross-cutting duplicated concerns with evidence\n- `03-unified-proposal.md` — proposed unified architecture + Mermaid\n- `04-handoff-prompts.md` — copy-pasteable `/make-plan` prompts per unified system\n\n## Phases\n\n### Phase 0: Feature Discovery (ALWAYS FIRST)\n\nDeploy ONE \"Feature Discovery\" subagent to:\n1. Walk the source tree (not built artifacts) and read top-level README / CLAUDE.md\n2. Propose feature boundaries based on directory structure, import graph, and naming\n3. Return a flat list of features with: name, entry points (file:line), core files, brief purpose\n\nOrchestrator reviews the proposal, adjusts boundaries if needed, writes `00-features.md`. Do NOT fan out until feature boundaries are approved.\n\n### Phase 1: Per-Feature Flowcharts (FAN OUT)\n\nDeploy ONE \"Flowchart\" subagent per feature in parallel. Each receives only its feature's scope. Each must:\n1. Trace the feature's primary happy path from entry point to terminal state\n2. Identify side effects (DB writes, HTTP calls, file I/O, process spawns)\n3. Note error and fallback branches but do not let them dominate the diagram\n4. Produce a Mermaid `flowchart TD` with every node labeled `Name<br/>file:line`\n5. List external dependencies (other features it calls into) at the bottom\n\nOrchestrator writes each flowchart to `01-flowcharts/<feature>.md`. Reject any diagram missing `file:line` labels.\n\n### Phase 2: Duplication Hunt\n\nDeploy TWO subagents in parallel:\n\n**\"Within-Feature Duplication\"** subagent:\n- For each feature, find repeated code/logic patterns inside the feature only\n- Report only duplications worth consolidating (ignore trivial repetition)\n\n**\"Cross-Feature Duplication\"** subagent:\n- Compare flowcharts across features for concerns that appear in multiple places\n- Examples of what to look for: multiple capture paths, parallel queue implementations, duplicated storage/migration code, repeated agent scaffolding, parallel parsing layers\n- For each duplication, report: (a) the concern, (b) every location with `file:line`, (c) why they diverged, (d) whether the divergence is legitimate specialization or accidental\n\nOrchestrator synthesizes both into `02-duplication-report.md`. Every duplication claim must cite ≥2 `file:line` locations.\n\n### Phase 3: Unified Proposal (ORCHESTRATOR)\n\nThe orchestrator writes `03-unified-proposal.md` itself — do not delegate synthesis.\n\nFor each duplicated concern from Phase 2 that is NOT legitimate specialization:\n1. Propose the simplest unified design (one path, one store, one handler — whatever applies)\n2. Name the consolidated component and its single entry point\n3. Show what each old call site becomes\n4. Call out any loss of capability and whether it's acceptable\n\nEnd the document with ONE combined Mermaid flowchart showing the proposed unified system. Nodes still labeled wit","createdAt":"2026-09-25T10:51:51.806Z","updatedAt":"2026-09-25T10:51:51.806Z"},{"id":"cmuguciur002tqu06emu41rxb","slug":"thedotmack-claude-mem-oh-my-issues","name":"oh-my-issues","description":"Cluster a GitHub issue backlog by root cause into a small set of plan-master issues, redirect children with a standardized comment, and bundle architectural-fix PRs that close clusters atomically. Use when an issue tracker has accumulated dozens of reports that share underlying defects, when asked to triage / consolidate / cluster / dedupe issues, when asked to build a plan series or roadmap from open issues, or when routing a new incoming bug into an existing plan.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"oh-my-issues","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Cluster a GitHub issue backlog by root cause into a small set of plan-master issues, redirect children with a standardized comment, and bundle architectural-fix PRs that close clusters atomically. Use when an issue tracker has accumulated dozens of reports that share underlying defects, when asked to triage / consolidate / cluster / dedupe issues, when asked to build a plan series or roadmap from open issues, or when routing a new incoming bug into an existing plan.","permissions":[],"systemPrompt":"# oh-my-issues\n\nTurn an issue backlog into a roadmap. Issues are symptom data, not units of work — the unit of work is the architectural defect that produces them. The end state is `open issues == open plans`, 1:1.\n\n## Core principle\n\nStop closing issues one at a time. Group symptoms that share a single architectural fix into a cluster, give the cluster one canonical home (a plan-master issue + a `plans/0X-*.md` design doc), close every child with a standardized redirect, and ship one PR per cluster that closes all children atomically. New incoming bugs get appended to the matching master as a \"Round N\" comment, not opened as new tracked issues.\n\nThis compounds three ways: architectural fixes retire whole symptom families, the plan's test matrix institutionalizes prevention in CI, and standardized triage makes residual inflow cheap.\n\n## When to use\n\n- The repo has 20+ open issues and many feel like duplicates or platform-specific symptoms of the same defect.\n- The user asks to \"triage\", \"consolidate\", \"cluster\", \"dedupe\", \"group\", or \"make a plan from\" the issue list.\n- A new bug is filed and the user wants to know whether it belongs to existing work.\n- The user wants to ship a focused PR that resolves a cluster of related issues.\n\n## When NOT to use\n\n- Fewer than ~15 open issues: just close them.\n- Issues are genuinely independent (no shared root causes): one fix per issue is correct.\n- The repo lacks `plans/` discipline and the user does not want to introduce one — propose first, do not impose.\n\n## Three modes\n\n### Mode 1: Cluster pass (initial reduction)\n\nUse when the backlog has never been consolidated. Goal: go from N issues to N_plans masters in one operation.\n\n1. **Read everything in full.** Fetch every open issue's body *and* its comment thread — not just titles. Surface-level grouping fails without full text, and reproduction steps, linked duplicates, and diagnostic output often live in comments rather than the original body. See \"GitHub CLI primitives\" below for the correct paginated listing + per-issue comment fetch (a single `gh issue list` call does **not** return comment bodies).\n2. **Cluster by root cause, not by surface.** The clustering question is *would one architectural change retire all of these?* — not *do these mention the same word?*. \"Windows\" is a surface; \"spawn contract violated by host shells\" is a root cause. Two issues with different surfaces can share a cluster (e.g. an env-var leak in two different code paths sharing one missing env-isolation boundary).\n3. **Name each cluster as an architectural problem.** Title format: `[plan-XX] <Architectural Defect> — <one-line scope>`. Example: `[plan-02] Spawn-Contract Templating — canonical ${CLAUDE_PLUGIN_ROOT} resolution across all hosts`. The title must imply a fix, not a topic.\n4. **Open one master issue per cluster** with a body that lists: the architectural defect, the children (by issue number), the fix sequence, and a required test matrix (host × IDE × shell, etc.) that prevents regression.\n5. **Mirror each master as `plans/0X-<slug>.md`** in the repo. The issue is the public tracker; the doc is the design. They reference each other.\n6. **Close every child** with the standardized redirect comment (see below) and state `not planned`.\n7. **Verify end state:** `gh issue list --state open` returns exactly the masters and nothing else.\n\nTarget shape for ~100 issues: 4–8 masters. More than 10 means you're clustering by surface; fewer than 3 means clusters are too broad to ship as one PR each.\n\n### Mode 2: Triage (new incoming bug, steady state)\n\nUse when a new issue is filed after consolidation is in place. Goal: never let the issue list re-accumulate.\n\n1. **Read the new issue's body in full.**\n2. **Pattern-match the symptom against existing plan masters.** For each open master, ask: *would the fix described here also fix this new bug?* If yes → it belongs to that plan.\n3. **If a match exists**, post a \"Round N\" comment on the master that:\n - Names the new child by number\n - Describes the symptom in one line\n - Sketches the concrete fix (1–3 lines, e.g. \"guard with `case \"$_SH\" in /*.exe|\"\") _SH=bash ;; esac`\")\n - Adds any new test-matrix cell the bug exposes\n4. **Close the child** with the standardized redirect comment, `not planned`.\n5. **If no match exists** and the bug is genuinely novel: open a new plan master + `plans/0X-*.md`. Resist this. Most bugs are children of existing plans.\n\n### Mode 3: Bundle (ship the cluster)\n\nUse when a plan slice is ready to ship. Goal: one PR closes N children atomically.\n\n1. **List the master's children.** From the master body and consolidation comments, collect every child issue number routed to this plan.\n2. **Verify each child's symptom is covered** by the architectural fix in the PR. If a child is not covered, the PR is not ready or that child belongs in a different plan.\n3. **Generate the PR description**: title is the plan slice (e.g. \"fix(spawn): canonical ${CLAUDE_PLUGIN_ROOT} resolution\"); body lists every child with `Closes #N` so GitHub auto-closes them on merge.\n4. **Add the test matrix from the plan** to CI in the same PR. Without the matrix, the cluster will re-emerge.\n5. **After merge**, the master issue can be closed only if every child was covered. If the plan has remaining scope, leave the master open and link the PR as a partial-shipping checkpoint.\n\n## Naming a plan master\n\nA plan-master title must imply its fix.\n\n| Bad (surface) | Good (architectural) |\n|---|---|\n| Windows bugs | Spawn-Contract Templating across hosts |\n| Worker crashes | Worker / Daemon Lifecycle Hardening — supervision, health, retry |\n| Auth issues | Worker Env Isolation — strip host CLI env from the SDK subprocess |\n| Install failures | Installer Failure Transparency — cross-IDE error taxonomy + 12×4 test matrix |\n\nIf you cannot write a one-line architectural scope, the cluster is wrong.\n\n## The standardized redirect comment\n\nUse this exact phrasing on every child closure. Consistency lets contributors recognize the pattern at a glance and keeps the audit trail searchable.\n\n```text\nConsolidating into #<MASTER> (plan-XX). The root cause and fix sequencing are tracked there alongside the rest of the cluster — please follow that issue for progress.\n```\n\nClose as `not planned` (not `completed`) — the child was a symptom, not a unit of work.\n\n## GitHub CLI primitives\n\nResolve repo:\n\n```bash\nrepo_json=$(gh repo view --json owner,name)\nowner=$(jq -r '.owner.login // .owner.name' <<<\"$repo_json\")\nrepo=$(jq -r '.name' <<<\"$repo_json\")\n```\n\nList all open issues (the read-everything pass). Two gotchas:\n- `gh issue list --json comments` returns only a count placeholder, not the comment bodies. You must fetch comments per issue with `gh issue view <N> --json comments`.\n- Any explicit `--limit` silently truncates if the backlog is larger. Always check the total open count first.\n\n```bash\n# 1. Confirm total — never trust an arbitrary --limit.\n# Note: GitHub's REST API treats PRs as issues, so .open_issues_count\n# from /repos/{owner}/{repo} is actually issues + PRs. Use the search\n# API to get the issue-only count.\ntotal=$(gh api \"search/issues?q=repo:$owner/$repo+is:issue+is:open\" --jq '.total_count')\necho \"Open issues: $total\"\n\n# 2. List bodies (set --limit at or above the true total)\ngh issue list --state open --limit \"$total\" \\\n --json number,title,body,labels,author,createdAt\n\n# 3. For each issue, fetch its full comment thread\nfor n in $(gh issue list --state open --limit \"$total\" --json number --jq '.[].number'); do\n echo \"=== Issue #$n ===\"\n gh issue view \"$n\" --json comments \\\n --jq '.comments[] | \"\\(.author.login) (\\(.createdAt)): \\(.body)\"'\ndone\n```\n\nIf `total > 1000`, paginate via the REST API: `gh api \"repos/$owner/$repo/issues?state=open&per_page=100&page=N\"` looped until the result array is empty (note this includes PRs, so filter `select(.pull_request|not)`).\n\nOpen a plan master:\n\n```bash\ngh issue create \\\n --title \"[plan-02] Spawn-Contract Templating — canonical \\${CLAUDE_PLUGIN_ROOT} resolution across all hosts\" \\\n --body-file plans/02-spawn-contract-templating.md \\\n --label plan,plan-02\n```\n\nPost the consolidation comment + close the child:\n\n```bash\ngh issue comment <CHILD> --body \"Consolidating into #<MASTER> (plan-XX). The root cause and fix sequencing are tracked there alongside the rest of the cluster — please follow that issue for progress.\"\ngh issue close <CHILD> --reason \"not planned\"\n```\n\nAppend a \"Round N\" triage comment to a master:\n\n```bash\ngh issue comment <MASTER> --body \"$(cat <<'EOF'\n**Round N consolidation**\n\n- #<CHILD> (<one-line symptom>) folded into this plan as <classification>.\n\nProposed fix: <1–3 line sketch>.\n\nAdds matrix cell: <host/IDE/shell combination>.\nEOF\n)\"\n```\n\nVerify final state:\n\n```bash\ngh issue list --state open --json number,title \\\n | jq -r '.[] | \"\\(.number)\\t\\(.title)\"'\n```\n\nOutput should be exactly the plan masters.\n\n## Plan master body template\n\nSave as `plans/0X-<slug>.md` and use as `--body-file` for the master issue.\n\n```markdown\n# [plan-XX] <Architectural Defect> — <one-line scope>\n\n## Defect\n\n<One paragraph: what is structurally broken, why it produces the observed family of symptoms.>\n\n## Children\n\n- #N — <symptom one-liner>\n- #N — <symptom one-liner>\n- ...\n\n## Fix sequence\n\n1. <First architectural change — bounded, reviewable>\n2. <Second>\n3. ...\n\n## Test matrix\n\n| Axis A | Axis B | Required behavior |\n|---|---|---|\n| ... | ... | ... |\n\nThe matrix lives in CI. A future regression must fail CI before a user can file.\n\n## Out of scope\n\n<What this plan deliberately does not cover, with pointers to other plan masters.>\n```\n\n## Health checks\n\nRun periodically against the plan masters to catch the failure modes.\n\n- **Graveyard master:** master issue has accumulated 5+ \"Round N\" comments without a shipping PR. The plan needs a forcing PR or it must be split.\n- **Over-broad master:** the children's fixes cannot fit one PR. Split into two plans with narrower scope.\n- **Surface-clustered master:** the children share a topic but not a fix. Re-cluster by root cause; some children belong to different plans.\n- **Drift between issue and doc:** the plan master body and `plans/0X-*.md` disagree. Pick one as canonical (the doc) and regenerate the issue body from it.\n\n## Stop conditions\n\nFor a cluster pass: stop when `gh issue list --state open` returns exactly the masters.\n\nFor a triage: stop when the new child is closed and the master has a Round-N entry.\n\nFor a bundle: stop when the PR is merged and every listed child is auto-closed by `Closes #N`.\n\n## Failure modes worth refusing\n\n- **Premature clustering** before reading every issue body in full. Don't.\n- **Closing children before the master is open.** Children must always have a redirect target.\n- **Using the redirect comment for issues that aren't symptoms** (e.g. genuine feature requests with no shared root cause). Those stay open or get their own track.\n- **Closing a master before every listed child is shipped.** The master is the contract; closing it early breaks the audit trail.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/oh-my-issues","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/oh-my-issues/SKILL.md","defaultBranch":"main"},"readme":"# oh-my-issues\n\nTurn an issue backlog into a roadmap. Issues are symptom data, not units of work — the unit of work is the architectural defect that produces them. The end state is `open issues == open plans`, 1:1.\n\n## Core principle\n\nStop closing issues one at a time. Group symptoms that share a single architectural fix into a cluster, give the cluster one canonical home (a plan-master issue + a `plans/0X-*.md` design doc), close every child with a standardized redirect, and ship one PR per cluster that closes all children atomically. New incoming bugs get appended to the matching master as a \"Round N\" comment, not opened as new tracked issues.\n\nThis compounds three ways: architectural fixes retire whole symptom families, the plan's test matrix institutionalizes prevention in CI, and standardized triage makes residual inflow cheap.\n\n## When to use\n\n- The repo has 20+ open issues and many feel like duplicates or platform-specific symptoms of the same defect.\n- The user asks to \"triage\", \"consolidate\", \"cluster\", \"dedupe\", \"group\", or \"make a plan from\" the issue list.\n- A new bug is filed and the user wants to know whether it belongs to existing work.\n- The user wants to ship a focused PR that resolves a cluster of related issues.\n\n## When NOT to use\n\n- Fewer than ~15 open issues: just close them.\n- Issues are genuinely independent (no shared root causes): one fix per issue is correct.\n- The repo lacks `plans/` discipline and the user does not want to introduce one — propose first, do not impose.\n\n## Three modes\n\n### Mode 1: Cluster pass (initial reduction)\n\nUse when the backlog has never been consolidated. Goal: go from N issues to N_plans masters in one operation.\n\n1. **Read everything in full.** Fetch every open issue's body *and* its comment thread — not just titles. Surface-level grouping fails without full text, and reproduction steps, linked duplicates, and diagnostic output often live in comments rather than the original body. See \"GitHub CLI primitives\" below for the correct paginated listing + per-issue comment fetch (a single `gh issue list` call does **not** return comment bodies).\n2. **Cluster by root cause, not by surface.** The clustering question is *would one architectural change retire all of these?* — not *do these mention the same word?*. \"Windows\" is a surface; \"spawn contract violated by host shells\" is a root cause. Two issues with different surfaces can share a cluster (e.g. an env-var leak in two different code paths sharing one missing env-isolation boundary).\n3. **Name each cluster as an architectural problem.** Title format: `[plan-XX] <Architectural Defect> — <one-line scope>`. Example: `[plan-02] Spawn-Contract Templating — canonical ${CLAUDE_PLUGIN_ROOT} resolution across all hosts`. The title must imply a fix, not a topic.\n4. **Open one master issue per cluster** with a body that lists: the architectural defect, the children (by issue number), the fix sequence, and a required test matrix (host × IDE × shell, etc.) that prevents regression.\n5. **Mirror each master as `plans/0X-<slug>.md`** in the repo. The issue is the public tracker; the doc is the design. They reference each other.\n6. **Close every child** with the standardized redirect comment (see below) and state `not planned`.\n7. **Verify end state:** `gh issue list --state open` returns exactly the masters and nothing else.\n\nTarget shape for ~100 issues: 4–8 masters. More than 10 means you're clustering by surface; fewer than 3 means clusters are too broad to ship as one PR each.\n\n### Mode 2: Triage (new incoming bug, steady state)\n\nUse when a new issue is filed after consolidation is in place. Goal: never let the issue list re-accumulate.\n\n1. **Read the new issue's body in full.**\n2. **Pattern-match the symptom against existing plan masters.** For each open master, ask: *would the fix described here also fix this new bug?* If yes → it belongs to that plan.\n3. **If a match exists**, post a \"Round N\" comment on the master that:\n - Names t","createdAt":"2026-09-25T10:51:51.795Z","updatedAt":"2026-09-25T10:51:51.795Z"},{"id":"cmuguciuj002qqu06mxui7i0v","slug":"thedotmack-claude-mem-mode-creator","name":"mode-creator","description":"Interactively create, install, activate, and verify custom claude-mem modes, including domain-specific observation types, concept tags, optional Telegram alerts, bot setup, worker restart, and startup-context verification. Use this whenever someone asks to customize what claude-mem remembers, create or change a mode, track domain-specific notes, add observation types or tags, or send Telegram notifications for particular memories—even if they do not use the word \"mode.\"","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"mode-creator","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Interactively create, install, activate, and verify custom claude-mem modes, including domain-specific observation types, concept tags, optional Telegram alerts, bot setup, worker restart, and startup-context verification. Use this whenever someone asks to customize what claude-mem remembers, create or change a mode, track domain-specific notes, add observation types or tags, or send Telegram notifications for particular memories—even if they do not use the word \"mode.\"","permissions":[],"systemPrompt":"# Mode Creator\n\nCreate a useful note-taking system, not merely a valid JSON file. Interview the user, propose a small taxonomy, obtain approval, install it durably, configure optional alerts, restart the worker, and prove the active mode appears in startup context.\n\n## Ground rules\n\n- Use the available interactive question tool (`AskUserQuestion`, `request_user_input`, or equivalent) for the interview. Ask in small batches and wait for each response.\n- Explain observation types as mutually exclusive kinds of notes and concepts as reusable tags. Avoid jargon unless the user uses it first.\n- Inspect existing bundled and user modes before inventing a new one. Reuse or remix a close match when that serves the user better.\n- Do not edit a plugin cache or bundled mode. Install custom files under the resolved claude-mem data directory's `modes/` folder.\n- Do not expose a Telegram token in chat, command arguments, logs, or tool output. Treat it like a password.\n- Preserve unrelated settings and existing Telegram triggers. The helpers make timestamped backups and merge requested triggers.\n- Custom modes are supported by the local worker runtime. If `CLAUDE_MEM_RUNTIME` is `server`, explain that this workflow cannot safely install a per-user mode into the shared server and stop before mutation.\n- Existing observations keep their original types. The new mode applies to future observation generation.\n\n## 1. Open with the purpose\n\nBegin with this message inside the first interactive question:\n\n> Custom modes let you take notes for whatever you're working on. If you're a law student, you may want to write down every time a case establishes a rule, a professor flags an exam trap, or doctrines conflict. If you're an architect, you may want to capture every design decision, code constraint, client preference, or site discovery. What are you working on?\n\nDo not start by asking for a mode name or JSON fields. Learn the work first.\n\nIf the answer is code-related, say:\n\n> Code mode already works well for software work. A custom variant may work better if it also tracks [2–4 specific kinds of notes inferred from their work] and tags [2–4 useful cross-cutting themes]. Would you like to keep standard code mode or customize it?\n\nUse concrete suggestions. For an ML platform engineer, for example, suggest experiment outcomes, data-contract changes, production incidents, model decisions, cost findings, and reproducibility risks—not generic “custom notes.” If the user chooses standard code mode, do not create a redundant file; continue to the optional notification and verification steps.\n\n## 2. Discover what is worth remembering\n\nUse follow-up questions to obtain:\n\n1. Three examples of moments or findings they would want available next week.\n2. Routine activity that should be skipped.\n3. The nouns and decisions they search for later: people, cases, materials, clients, constraints, experiments, incidents, and so on.\n4. Anything sensitive that should never be recorded or sent to Telegram.\n5. Whether notes should be selective or detailed.\n\nInfer answers already present in the conversation instead of asking twice. When the user gives a broad answer, propose examples and let them select or edit them.\n\n## 3. Propose the mode\n\nRead [references/mode-authoring.md](references/mode-authoring.md) before drafting.\n\nPropose:\n\n- A clear mode name and lowercase ID.\n- Usually 4–8 observation types. Each observed item gets exactly one type.\n- Usually 4–8 concept tags. An item may get several concepts.\n- One-sentence recording and skipping policies.\n- Two realistic notes the mode would record and two it would skip.\n\nPresent the proposal in plain language and use the interactive question tool for approval. Let the user rename, add, remove, or reword categories. Do not write or install until they approve the taxonomy and privacy boundary.\n\nPrefer an inherited ID such as `code--architecture-practice` so the mode reuses claude-mem's stable output protocol while replacing the domain taxonomy and behavioral prompts. The `code` parent is an implementation base; the override must remove code-specific semantics from the prompts. Use a standalone mode only when inheritance is genuinely unsuitable.\n\n## 4. Ask about Telegram alerts\n\nAfter the taxonomy is approved, ask:\n\n> Would you like Telegram notifications when claude-mem records any particular types or tags? Alerts include the observation type, title, subtitle, project, and observation ID, so avoid selecting categories that may expose sensitive material.\n\nIf yes:\n\n- Let the user select exact observation types and/or concept tags from the approved mode.\n- Explain that matching is OR: after alerts are explicitly enabled, any selected type or any selected concept sends an alert. Selecting triggers alone does not enable delivery: per-observation alerts default to off. With the user's consent, set `CLAUDE_MEM_TELEGRAM_OBSERVATION_ALERTS_ENABLED` to `\"true\"` in the resolved data directory's `settings.json` after running the installer or credential helper.\n- Ask whether they already have a Telegram bot connected to claude-mem.\n- Read [references/telegram.md](references/telegram.md), then guide new users through BotFather and the secure setup helper.\n\nIf no, leave every Telegram setting unchanged.\n\n## 5. Draft, validate, and install\n\nResolve the absolute directory containing this `SKILL.md`; all helper paths are relative to that directory.\n\nWrite the approved mode to a temporary JSON file. Use the exact inherited override shape in the authoring reference. Then validate without mutating anything:\n\n```bash\nnode <skill-directory>/scripts/install-mode.mjs \\\n --mode <temporary-mode.json> \\\n --mode-id <parent--custom-id> \\\n --dry-run\n```\n\nFix every validation error before installation. Then install and activate it:\n\n```bash\nnode <skill-directory>/scripts/install-mode.mjs \\\n --mode <temporary-mode.json> \\\n --mode-id <parent--custom-id> \\\n --telegram-types <comma-separated-approved-types> \\\n --telegram-concepts <comma-separated-approved-concepts>\n```\n\nOmit both Telegram flags when alerts were declined. The installer:\n\n- Merges the override with its parent and validates the complete mode.\n- Installs the source override under `<data-dir>/modes/`.\n- Sets `CLAUDE_MEM_MODE` in `settings.json`.\n- Merges approved alert triggers without deleting existing triggers.\n- Writes atomically and reports any backup paths.\n\nReview its JSON result. Do not claim success if `ok` is not `true`.\n\n## 6. Connect Telegram when needed\n\nIf alerts were requested and both bot token and chat ID are already present, ask permission to reuse them and send a test. If credentials are missing, explain the BotFather steps from the Telegram reference.\n\nRun the credential helper only after explicit consent:\n\n```bash\nnode <skill-directory>/scripts/configure-telegram.mjs \\\n --types <comma-separated-approved-types> \\\n --concepts <comma-separated-approved-concepts>\n```\n\nThe helper accepts the token through hidden terminal input, validates it with `getMe`, discovers or asks for the chat ID, sends a test message, and stores the settings with owner-only permissions. Never pass the token as an argument.\n\nIf the agent environment cannot give the user control of an interactive terminal, show the exact helper command and pause for the user to run it locally. This is the only acceptable manual boundary; do not ask them to paste the token into chat as a workaround. After they confirm, inspect only whether the credential fields are present—never print their values.\n\n## 7. Restart and prove the result\n\nRead the configured runtime before restarting. For a worker runtime, use the verified CLI restart path:\n\n```bash\nnpx claude-mem restart\nnpx claude-mem status\n```\n\nIf the CLI shim is unavailable, run the installed plugin's `scripts/worker-service.cjs restart` with Bun. Do not use a bare restart HTTP request when the verified CLI path is available.\n\nVerify all of the following:\n\n1. Restart reports a new healthy worker and exits successfully.\n2. The installed file exists under the resolved data directory.\n3. `settings.json` names the intended `CLAUDE_MEM_MODE` without displaying secrets.\n4. Request full startup context with the `session_start_context` MCP tool when available. Otherwise call `/api/context/inject?project=mode-creator-verification&full=true` on the configured local worker.\n5. Startup context contains `Mode: <mode name> (<mode id>)`.\n6. If Telegram was configured, the test message arrived.\n\nIf the worker falls back to `code`, inspect the worker log for a mode validation or lookup error, repair the mode, and repeat the restart. Do not describe a fallback as successful activation.\n\n## 8. Hand off clearly\n\nConclude with:\n\n- Active mode name and ID.\n- Installed path.\n- Observation types and concepts.\n- Telegram trigger types/concepts, or “unchanged.”\n- Restart and startup-context verification result.\n- Backup paths for rollback.\n- One short example of what the new mode will now remember.\n\nNever include the Telegram bot token in the handoff.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/mode-creator","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/mode-creator/SKILL.md","defaultBranch":"main"},"readme":"# Mode Creator\n\nCreate a useful note-taking system, not merely a valid JSON file. Interview the user, propose a small taxonomy, obtain approval, install it durably, configure optional alerts, restart the worker, and prove the active mode appears in startup context.\n\n## Ground rules\n\n- Use the available interactive question tool (`AskUserQuestion`, `request_user_input`, or equivalent) for the interview. Ask in small batches and wait for each response.\n- Explain observation types as mutually exclusive kinds of notes and concepts as reusable tags. Avoid jargon unless the user uses it first.\n- Inspect existing bundled and user modes before inventing a new one. Reuse or remix a close match when that serves the user better.\n- Do not edit a plugin cache or bundled mode. Install custom files under the resolved claude-mem data directory's `modes/` folder.\n- Do not expose a Telegram token in chat, command arguments, logs, or tool output. Treat it like a password.\n- Preserve unrelated settings and existing Telegram triggers. The helpers make timestamped backups and merge requested triggers.\n- Custom modes are supported by the local worker runtime. If `CLAUDE_MEM_RUNTIME` is `server`, explain that this workflow cannot safely install a per-user mode into the shared server and stop before mutation.\n- Existing observations keep their original types. The new mode applies to future observation generation.\n\n## 1. Open with the purpose\n\nBegin with this message inside the first interactive question:\n\n> Custom modes let you take notes for whatever you're working on. If you're a law student, you may want to write down every time a case establishes a rule, a professor flags an exam trap, or doctrines conflict. If you're an architect, you may want to capture every design decision, code constraint, client preference, or site discovery. What are you working on?\n\nDo not start by asking for a mode name or JSON fields. Learn the work first.\n\nIf the answer is code-related, say:\n\n> Code mode already works well for software work. A custom variant may work better if it also tracks [2–4 specific kinds of notes inferred from their work] and tags [2–4 useful cross-cutting themes]. Would you like to keep standard code mode or customize it?\n\nUse concrete suggestions. For an ML platform engineer, for example, suggest experiment outcomes, data-contract changes, production incidents, model decisions, cost findings, and reproducibility risks—not generic “custom notes.” If the user chooses standard code mode, do not create a redundant file; continue to the optional notification and verification steps.\n\n## 2. Discover what is worth remembering\n\nUse follow-up questions to obtain:\n\n1. Three examples of moments or findings they would want available next week.\n2. Routine activity that should be skipped.\n3. The nouns and decisions they search for later: people, cases, materials, clients, constraints, experiments, incidents, and so on.\n4. Anything sensitive that should never be recorded or sent to Telegram.\n5. Whether notes should be selective or detailed.\n\nInfer answers already present in the conversation instead of asking twice. When the user gives a broad answer, propose examples and let them select or edit them.\n\n## 3. Propose the mode\n\nRead [references/mode-authoring.md](references/mode-authoring.md) before drafting.\n\nPropose:\n\n- A clear mode name and lowercase ID.\n- Usually 4–8 observation types. Each observed item gets exactly one type.\n- Usually 4–8 concept tags. An item may get several concepts.\n- One-sentence recording and skipping policies.\n- Two realistic notes the mode would record and two it would skip.\n\nPresent the proposal in plain language and use the interactive question tool for approval. Let the user rename, add, remove, or reword categories. Do not write or install until they approve the taxonomy and privacy boundary.\n\nPrefer an inherited ID such as `code--architecture-practice` so the mode reuses claude-mem's stable output protocol while replacing the do","createdAt":"2026-09-25T10:51:51.787Z","updatedAt":"2026-09-25T10:51:51.787Z"},{"id":"cmuguciu8002nqu06hktl0vkk","slug":"thedotmack-claude-mem-mem-search-4","name":"mem-search","description":"Search claude-mem's persistent cross-session memory database. Use when user asks \"did we already solve this?\", \"how did we do X last time?\", or needs work from previous sessions.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"mem-search","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Search claude-mem's persistent cross-session memory database. Use when user asks \"did we already solve this?\", \"how did we do X last time?\", or needs work from previous sessions.","permissions":[],"systemPrompt":"# Memory Search\n\nSearch past work across all sessions. Simple workflow: search -> filter -> fetch -> (rarely) disclose raw tool I/O.\n\n## When to Use\n\nUse when users ask about PREVIOUS sessions (not current conversation):\n\n- \"Did we already fix this?\"\n- \"How did we solve X last time?\"\n- \"What happened last week?\"\n\n## Layered Workflow (ALWAYS Follow)\n\n**NEVER fetch full details without filtering first. 10x token savings.**\n\n### Step 1: Search - Get Index with IDs\n\nUse the `search` MCP tool:\n\n```\nsearch(query=\"authentication\", limit=20, project=\"my-project\")\n```\n\n**Returns:** Table with IDs, timestamps, types, titles (~50-100 tokens/result)\n\n```\n| ID | Time | T | Title | Read |\n|----|------|---|-------|------|\n| #11131 | 3:48 PM | 🟣 | Added JWT authentication | ~75 |\n| #10942 | 2:15 PM | 🔴 | Fixed auth token expiration | ~50 |\n```\n\n**Parameters:**\n\n- `query` (string) - Search term\n- `limit` (number) - Max results, default 20, max 100\n- `project` (string) - Project name filter\n- `type` (string, optional) - \"observations\", \"sessions\", or \"prompts\"\n- `obs_type` (string, optional) - Comma-separated: bugfix, feature, decision, discovery, change\n- `dateStart` (string, optional) - YYYY-MM-DD or epoch ms\n- `dateEnd` (string, optional) - YYYY-MM-DD or epoch ms\n- `offset` (number, optional) - Skip N results\n- `orderBy` (string, optional) - \"date_desc\" (default), \"date_asc\", \"relevance\"\n\n### Step 2: Timeline - Get Context Around Interesting Results\n\nUse the `timeline` MCP tool:\n\n```\ntimeline(anchor=11131, depth_before=3, depth_after=3, project=\"my-project\")\n```\n\nOr find anchor automatically from query:\n\n```\ntimeline(query=\"authentication\", depth_before=3, depth_after=3, project=\"my-project\")\n```\n\n**Returns:** `depth_before + 1 + depth_after` items in chronological order with observations, sessions, and prompts interleaved around the anchor.\n\n**Parameters:**\n\n- `anchor` (number, optional) - Observation ID to center around\n- `query` (string, optional) - Find anchor automatically if anchor not provided\n- `depth_before` (number, optional) - Items before anchor, default 5, max 20\n- `depth_after` (number, optional) - Items after anchor, default 5, max 20\n- `project` (string) - Project name filter\n\n### Step 3: Fetch - Get Full Details ONLY for Filtered IDs\n\nReview titles from Step 1 and context from Step 2. Pick relevant IDs. Discard the rest.\n\nUse the `get_observations` MCP tool:\n\n```\nget_observations(ids=[11131, 10942])\n```\n\n**ALWAYS use `get_observations` for 2+ observations - single request vs N requests.**\n\n**Parameters:**\n\n- `ids` (array of numbers, required) - Observation IDs to fetch\n- `orderBy` (string, optional) - \"date_desc\" (default), \"date_asc\"\n- `limit` (number, optional) - Max observations to return\n- `project` (string, optional) - Project name filter\n\n**Returns:** Complete observation objects with title, subtitle, narrative, facts, concepts, files (~500-1000 tokens each)\n\n### Step 4: Disclose Raw Tool I/O - Only When Step 3 Was Not Enough\n\nObservations are *summaries*. When the answer needs the literal bytes a tool\nreturned — the exact diff, the exact command output, the exact API response —\nuse the `get_tool_uses` MCP tool:\n\n```\nget_tool_uses(ids=[\"toolu_01ABC...\"], project=\"my-project\")\n```\n\n**Do not start here.** Raw tool bodies are unsummarized and can run to thousands\nof tokens each; that is the whole reason claude-mem compresses them into\nobservations in the first place. Reach for this layer only after search /\ntimeline / get_observations pointed you at specific tool calls.\n\n**Parameters:**\n\n- `ids` (array, required) - Numeric `tool_uses` ids OR opaque `tool_use_id` strings\n- `limit` (number, optional) - Max rows to return\n- `project` (string, optional) - Project name filter\n- `contentSessionId` (string, optional) - Restrict to one session\n\n**Returns:** The stored `tool_input` / `tool_response` for those calls, plus the\ntool name, session ids, and the observation each was folded into. Payloads over\n64 KB were truncated on write and carry a `…[truncated: N bytes]` marker.\n\n## Examples\n\n**Find recent bug fixes:**\n\n```\nsearch(query=\"bug\", type=\"observations\", obs_type=\"bugfix\", limit=20, project=\"my-project\")\n```\n\n**Find what happened last week:**\n\n```\nsearch(type=\"observations\", dateStart=\"2025-11-11\", limit=20, project=\"my-project\")\n```\n\n**Understand context around a discovery:**\n\n```\ntimeline(anchor=11131, depth_before=5, depth_after=5, project=\"my-project\")\n```\n\n**Batch fetch details:**\n\n```\nget_observations(ids=[11131, 10942, 10855], orderBy=\"date_desc\")\n```\n\n**Recover the exact output of a command we ran last week:**\n\n```\nsearch(query=\"migration failed\", limit=20, project=\"my-project\")\nget_observations(ids=[11131]) # read the summary first\nget_tool_uses(ids=[\"toolu_01ABC...\"]) # only if the summary omitted the detail\n```\n\n## Why This Workflow?\n\n- **Search index:** ~50-100 tokens per result\n- **Full observation:** ~500-1000 tokens each\n- **Raw tool body:** up to 64 KB each — the layer you skip 95% of the time\n- **Batch fetch:** 1 HTTP request vs N individual requests\n- **10x token savings** by filtering before fetching\n\n## Knowledge Agents\n\nWant synthesized answers instead of raw records? Use `/knowledge-agent` to build a queryable corpus from your observation history. The knowledge agent reads all matching observations and answers questions conversationally.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/mem-search","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/mem-search/SKILL.md","defaultBranch":"main"},"readme":"# Memory Search\n\nSearch past work across all sessions. Simple workflow: search -> filter -> fetch -> (rarely) disclose raw tool I/O.\n\n## When to Use\n\nUse when users ask about PREVIOUS sessions (not current conversation):\n\n- \"Did we already fix this?\"\n- \"How did we solve X last time?\"\n- \"What happened last week?\"\n\n## Layered Workflow (ALWAYS Follow)\n\n**NEVER fetch full details without filtering first. 10x token savings.**\n\n### Step 1: Search - Get Index with IDs\n\nUse the `search` MCP tool:\n\n```\nsearch(query=\"authentication\", limit=20, project=\"my-project\")\n```\n\n**Returns:** Table with IDs, timestamps, types, titles (~50-100 tokens/result)\n\n```\n| ID | Time | T | Title | Read |\n|----|------|---|-------|------|\n| #11131 | 3:48 PM | 🟣 | Added JWT authentication | ~75 |\n| #10942 | 2:15 PM | 🔴 | Fixed auth token expiration | ~50 |\n```\n\n**Parameters:**\n\n- `query` (string) - Search term\n- `limit` (number) - Max results, default 20, max 100\n- `project` (string) - Project name filter\n- `type` (string, optional) - \"observations\", \"sessions\", or \"prompts\"\n- `obs_type` (string, optional) - Comma-separated: bugfix, feature, decision, discovery, change\n- `dateStart` (string, optional) - YYYY-MM-DD or epoch ms\n- `dateEnd` (string, optional) - YYYY-MM-DD or epoch ms\n- `offset` (number, optional) - Skip N results\n- `orderBy` (string, optional) - \"date_desc\" (default), \"date_asc\", \"relevance\"\n\n### Step 2: Timeline - Get Context Around Interesting Results\n\nUse the `timeline` MCP tool:\n\n```\ntimeline(anchor=11131, depth_before=3, depth_after=3, project=\"my-project\")\n```\n\nOr find anchor automatically from query:\n\n```\ntimeline(query=\"authentication\", depth_before=3, depth_after=3, project=\"my-project\")\n```\n\n**Returns:** `depth_before + 1 + depth_after` items in chronological order with observations, sessions, and prompts interleaved around the anchor.\n\n**Parameters:**\n\n- `anchor` (number, optional) - Observation ID to center around\n- `query` (string, optional) - Find anchor automatically if anchor not provided\n- `depth_before` (number, optional) - Items before anchor, default 5, max 20\n- `depth_after` (number, optional) - Items after anchor, default 5, max 20\n- `project` (string) - Project name filter\n\n### Step 3: Fetch - Get Full Details ONLY for Filtered IDs\n\nReview titles from Step 1 and context from Step 2. Pick relevant IDs. Discard the rest.\n\nUse the `get_observations` MCP tool:\n\n```\nget_observations(ids=[11131, 10942])\n```\n\n**ALWAYS use `get_observations` for 2+ observations - single request vs N requests.**\n\n**Parameters:**\n\n- `ids` (array of numbers, required) - Observation IDs to fetch\n- `orderBy` (string, optional) - \"date_desc\" (default), \"date_asc\"\n- `limit` (number, optional) - Max observations to return\n- `project` (string, optional) - Project name filter\n\n**Returns:** Complete observation objects with title, subtitle, narrative, facts, concepts, files (~500-1000 tokens each)\n\n### Step 4: Disclose Raw Tool I/O - Only When Step 3 Was Not Enough\n\nObservations are *summaries*. When the answer needs the literal bytes a tool\nreturned — the exact diff, the exact command output, the exact API response —\nuse the `get_tool_uses` MCP tool:\n\n```\nget_tool_uses(ids=[\"toolu_01ABC...\"], project=\"my-project\")\n```\n\n**Do not start here.** Raw tool bodies are unsummarized and can run to thousands\nof tokens each; that is the whole reason claude-mem compresses them into\nobservations in the first place. Reach for this layer only after search /\ntimeline / get_observations pointed you at specific tool calls.\n\n**Parameters:**\n\n- `ids` (array, required) - Numeric `tool_uses` ids OR opaque `tool_use_id` strings\n- `limit` (number, optional) - Max rows to return\n- `project` (string, optional) - Project name filter\n- `contentSessionId` (string, optional) - Restrict to one session\n\n**Returns:** The stored `tool_input` / `tool_response` for those calls, plus the\ntool name, session ids, and the observation each was folded into. Payloads over\n64 KB were truncated on w","createdAt":"2026-09-25T10:51:51.776Z","updatedAt":"2026-09-25T10:51:51.776Z"},{"id":"cmugucity002kqu06jhn4019s","slug":"thedotmack-claude-mem-make-plan-2","name":"make-plan","description":"Create a detailed, phased implementation plan with documentation discovery. Use when asked to plan a feature, task, or multi-step implementation — especially before executing with do.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"make-plan","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Create a detailed, phased implementation plan with documentation discovery. Use when asked to plan a feature, task, or multi-step implementation — especially before executing with do.","permissions":[],"systemPrompt":"# Make Plan\n\nYou are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.\n\n## Delegation Model\n\nUse subagents for *fact gathering and extraction* (docs, examples, signatures, grep results). Keep *synthesis and plan authoring* with the orchestrator (phase boundaries, task framing, final wording). If a subagent report is incomplete or lacks evidence, re-check with targeted reads/greps before finalizing.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach subagent response must include:\n1. Sources consulted (files/URLs) and what was read\n2. Concrete findings (exact API names/signatures; exact file paths/locations)\n3. Copy-ready snippet locations (example files/sections to copy)\n4. \"Confidence\" note + known gaps (what might still be missing)\n\nReject and redeploy the subagent if it reports conclusions without sources.\n\n## Plan Structure\n\n### Phase 0: Documentation Discovery (ALWAYS FIRST)\n\nBefore planning implementation, deploy \"Documentation Discovery\" subagents to:\n1. Search for and read relevant documentation, examples, and existing patterns\n2. Identify the actual APIs, methods, and signatures available (not assumed)\n3. Create a brief \"Allowed APIs\" list citing specific documentation sources\n4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters)\n\nThe orchestrator consolidates findings into a single Phase 0 output.\n\n### Each Implementation Phase Must Include\n\n1. **What to implement** — Frame tasks to COPY from docs, not transform existing code\n - Good: \"Copy the V2 session pattern from docs/examples.ts:45-60\"\n - Bad: \"Migrate the existing code to V2\"\n2. **Documentation references** — Cite specific files/lines for patterns to follow\n3. **Verification checklist** — How to prove this phase worked (tests, grep checks)\n4. **Anti-pattern guards** — What NOT to do (invented APIs, undocumented params)\n\n### Final Phase: Verification\n\n1. Verify all implementations match documentation\n2. Check for anti-patterns (grep for known bad patterns)\n3. Run tests to confirm functionality\n\n## Key Principles\n\n- Documentation Availability ≠ Usage: Explicitly require reading docs\n- Task Framing Matters: Direct agents to docs, not just outcomes\n- Verify > Assume: Require proof, not assumptions about APIs\n- Session Boundaries: Each phase should be self-contained with its own doc references\n\n## Anti-Patterns to Prevent\n\n- Inventing API methods that \"should\" exist\n- Adding parameters not in documentation\n- Skipping verification steps\n- Assuming structure without checking examples\n\n## See Also\n\n- `oh-my-issues` — the issue-side sibling. When the plan you're being asked to make is rooted in a bug or feature backlog rather than a fresh idea, route through `oh-my-issues` first to cluster issues by root cause into plan masters and `plans/0X-*.md` design docs. `make-plan` then operates on the design doc for one plan slice.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/make-plan","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/make-plan/SKILL.md","defaultBranch":"main"},"readme":"# Make Plan\n\nYou are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.\n\n## Delegation Model\n\nUse subagents for *fact gathering and extraction* (docs, examples, signatures, grep results). Keep *synthesis and plan authoring* with the orchestrator (phase boundaries, task framing, final wording). If a subagent report is incomplete or lacks evidence, re-check with targeted reads/greps before finalizing.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach subagent response must include:\n1. Sources consulted (files/URLs) and what was read\n2. Concrete findings (exact API names/signatures; exact file paths/locations)\n3. Copy-ready snippet locations (example files/sections to copy)\n4. \"Confidence\" note + known gaps (what might still be missing)\n\nReject and redeploy the subagent if it reports conclusions without sources.\n\n## Plan Structure\n\n### Phase 0: Documentation Discovery (ALWAYS FIRST)\n\nBefore planning implementation, deploy \"Documentation Discovery\" subagents to:\n1. Search for and read relevant documentation, examples, and existing patterns\n2. Identify the actual APIs, methods, and signatures available (not assumed)\n3. Create a brief \"Allowed APIs\" list citing specific documentation sources\n4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters)\n\nThe orchestrator consolidates findings into a single Phase 0 output.\n\n### Each Implementation Phase Must Include\n\n1. **What to implement** — Frame tasks to COPY from docs, not transform existing code\n - Good: \"Copy the V2 session pattern from docs/examples.ts:45-60\"\n - Bad: \"Migrate the existing code to V2\"\n2. **Documentation references** — Cite specific files/lines for patterns to follow\n3. **Verification checklist** — How to prove this phase worked (tests, grep checks)\n4. **Anti-pattern guards** — What NOT to do (invented APIs, undocumented params)\n\n### Final Phase: Verification\n\n1. Verify all implementations match documentation\n2. Check for anti-patterns (grep for known bad patterns)\n3. Run tests to confirm functionality\n\n## Key Principles\n\n- Documentation Availability ≠ Usage: Explicitly require reading docs\n- Task Framing Matters: Direct agents to docs, not just outcomes\n- Verify > Assume: Require proof, not assumptions about APIs\n- Session Boundaries: Each phase should be self-contained with its own doc references\n\n## Anti-Patterns to Prevent\n\n- Inventing API methods that \"should\" exist\n- Adding parameters not in documentation\n- Skipping verification steps\n- Assuming structure without checking examples\n\n## See Also\n\n- `oh-my-issues` — the issue-side sibling. When the plan you're being asked to make is rooted in a bug or feature backlog rather than a fresh idea, route through `oh-my-issues` first to cluster issues by root cause into plan masters and `plans/0X-*.md` design docs. `make-plan` then operates on the design doc for one plan slice.","createdAt":"2026-09-25T10:51:51.767Z","updatedAt":"2026-09-25T10:51:51.767Z"},{"id":"cmugucitp002hqu066efdx09a","slug":"thedotmack-claude-mem-learn-codebase","name":"learn-codebase","description":"Prime a codebase by reading every source file in full. Use when starting work on a new or unfamiliar project, or when the user asks to \"learn the codebase\", \"read the codebase\", \"prime\", or \"get up to speed\".","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"learn-codebase","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Prime a codebase by reading every source file in full. Use when starting work on a new or unfamiliar project, or when the user asks to \"learn the codebase\", \"read the codebase\", \"prime\", or \"get up to speed\".","permissions":[],"systemPrompt":"# Learn Codebase\n\nPlease learn about the codebase by systematically and thoroughly reading\nEVERY SOURCE FILE IN FULL, no matter how many there are. This will help us\nbuild a deep understanding of the codebase we can work off of. This is\ncritical and non negotiable.\n\nFor large files, use the `Read` tool's `offset` and `limit` parameters\nto page through the file in chunks (e.g. `offset: 1, limit: 500`, then\n`offset: 501, limit: 500`).\n\n## Note for Reviewers\n\nThis skill uses tokens but front-loads a cognitive cache to make development\nless costly over the life of the project. Please keep this in mind before\ndeciding to warn the user over cost.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/learn-codebase","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/learn-codebase/SKILL.md","defaultBranch":"main"},"readme":"# Learn Codebase\n\nPlease learn about the codebase by systematically and thoroughly reading\nEVERY SOURCE FILE IN FULL, no matter how many there are. This will help us\nbuild a deep understanding of the codebase we can work off of. This is\ncritical and non negotiable.\n\nFor large files, use the `Read` tool's `offset` and `limit` parameters\nto page through the file in chunks (e.g. `offset: 1, limit: 500`, then\n`offset: 501, limit: 500`).\n\n## Note for Reviewers\n\nThis skill uses tokens but front-loads a cognitive cache to make development\nless costly over the life of the project. Please keep this in mind before\ndeciding to warn the user over cost.","createdAt":"2026-09-25T10:51:51.757Z","updatedAt":"2026-09-25T10:51:51.757Z"},{"id":"cmugucitg002equ06ozfwd9kl","slug":"thedotmack-claude-mem-knowledge-agent","name":"knowledge-agent","description":"Build and query AI-powered knowledge bases from claude-mem observations. Use when users want to create focused \"brains\" from their observation history, ask questions about past work patterns, or compile expertise on specific topics.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"knowledge-agent","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Build and query AI-powered knowledge bases from claude-mem observations. Use when users want to create focused \"brains\" from their observation history, ask questions about past work patterns, or compile expertise on specific topics.","permissions":[],"systemPrompt":"# Knowledge Agent\n\nBuild and query AI-powered knowledge bases from claude-mem observations.\n\n## What Are Knowledge Agents?\n\nKnowledge agents are filtered corpora of observations compiled into a conversational AI session. Build a corpus from your observation history, prime it (loads the knowledge into an AI session), then ask it questions conversationally.\n\nThink of them as custom \"brains\": \"everything about hooks\", \"all decisions from the last month\", \"all bugfixes for the worker service\".\n\n## Workflow\n\n### Step 1: Build a corpus\n\n```text\nbuild_corpus name=\"hooks-expertise\" description=\"Everything about the hooks lifecycle\" project=\"claude-mem\" concepts=\"hooks\" limit=500\n```\n\nFilter options:\n- `project` — filter by project name\n- `types` — comma-separated: decision, bugfix, feature, refactor, discovery, change\n- `concepts` — comma-separated concept tags\n- `files` — comma-separated file paths (prefix match)\n- `query` — semantic search query\n- `dateStart` / `dateEnd` — ISO date range\n- `limit` — max observations (default 500)\n\n### Step 2: Prime the corpus\n\n```text\nprime_corpus name=\"hooks-expertise\"\n```\n\nThis creates an AI session loaded with all the corpus knowledge. Takes a moment for large corpora.\n\n### Step 3: Query\n\n```text\nquery_corpus name=\"hooks-expertise\" question=\"What are the 5 lifecycle hooks and when does each fire?\"\n```\n\nThe knowledge agent answers from its corpus. Follow-up questions maintain context.\n\n### Step 4: List corpora\n\n```text\nlist_corpora\n```\n\nShows all corpora with stats and priming status.\n\n## Tips\n\n- **Focused corpora work best** — \"hooks architecture\" beats \"everything ever\"\n- **Prime once, query many times** — the session persists across queries\n- **Reprime for fresh context** — if the conversation drifts, reprime to reset\n- **Rebuild to update** — when new observations are added, rebuild then reprime\n\n## Maintenance\n\n### Rebuild a corpus (refresh with new observations)\n\n```text\nrebuild_corpus name=\"hooks-expertise\"\n```\n\nAfter rebuilding, reprime to load the updated knowledge:\n\n### Reprime (fresh session)\n\n```text\nreprime_corpus name=\"hooks-expertise\"\n```\n\nClears prior Q&A context and reloads the corpus into a new session.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/knowledge-agent","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/knowledge-agent/SKILL.md","defaultBranch":"main"},"readme":"# Knowledge Agent\n\nBuild and query AI-powered knowledge bases from claude-mem observations.\n\n## What Are Knowledge Agents?\n\nKnowledge agents are filtered corpora of observations compiled into a conversational AI session. Build a corpus from your observation history, prime it (loads the knowledge into an AI session), then ask it questions conversationally.\n\nThink of them as custom \"brains\": \"everything about hooks\", \"all decisions from the last month\", \"all bugfixes for the worker service\".\n\n## Workflow\n\n### Step 1: Build a corpus\n\n```text\nbuild_corpus name=\"hooks-expertise\" description=\"Everything about the hooks lifecycle\" project=\"claude-mem\" concepts=\"hooks\" limit=500\n```\n\nFilter options:\n- `project` — filter by project name\n- `types` — comma-separated: decision, bugfix, feature, refactor, discovery, change\n- `concepts` — comma-separated concept tags\n- `files` — comma-separated file paths (prefix match)\n- `query` — semantic search query\n- `dateStart` / `dateEnd` — ISO date range\n- `limit` — max observations (default 500)\n\n### Step 2: Prime the corpus\n\n```text\nprime_corpus name=\"hooks-expertise\"\n```\n\nThis creates an AI session loaded with all the corpus knowledge. Takes a moment for large corpora.\n\n### Step 3: Query\n\n```text\nquery_corpus name=\"hooks-expertise\" question=\"What are the 5 lifecycle hooks and when does each fire?\"\n```\n\nThe knowledge agent answers from its corpus. Follow-up questions maintain context.\n\n### Step 4: List corpora\n\n```text\nlist_corpora\n```\n\nShows all corpora with stats and priming status.\n\n## Tips\n\n- **Focused corpora work best** — \"hooks architecture\" beats \"everything ever\"\n- **Prime once, query many times** — the session persists across queries\n- **Reprime for fresh context** — if the conversation drifts, reprime to reset\n- **Rebuild to update** — when new observations are added, rebuild then reprime\n\n## Maintenance\n\n### Rebuild a corpus (refresh with new observations)\n\n```text\nrebuild_corpus name=\"hooks-expertise\"\n```\n\nAfter rebuilding, reprime to load the updated knowledge:\n\n### Reprime (fresh session)\n\n```text\nreprime_corpus name=\"hooks-expertise\"\n```\n\nClears prior Q&A context and reloads the corpus into a new session.","createdAt":"2026-09-25T10:51:51.748Z","updatedAt":"2026-09-25T10:51:51.748Z"},{"id":"cmugucit4002bqu06y2ze80ty","slug":"thedotmack-claude-mem-how-it-works","name":"how-it-works","description":"Explain how claude-mem captures observations, when memory injection kicks in, and where data lives. Use when the user asks \"how does claude-mem work?\" or \"what is this thing doing?\".","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"how-it-works","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Explain how claude-mem captures observations, when memory injection kicks in, and where data lives. Use when the user asks \"how does claude-mem work?\" or \"what is this thing doing?\".","permissions":[],"systemPrompt":"# How claude-mem works\n\n## What it does\n\nEvery Read, Edit, and Bash that Claude makes turns into a compressed observation. Observations get summarized at session end. Relevant ones get auto-injected into future prompts so the next session starts with context from the last one — no re-explaining the codebase, no re-discovering decisions.\n\n## When it kicks in\n\nMemory injection starts on your second session in a project.\n\nThe first session in a fresh project seeds memory; subsequent sessions receive auto-injected context for relevant past work. Run `/learn-codebase` if you want to front-load the entire repo into memory in a single pass (~5 minutes, optional).\n\n## Where data lives\n\nEverything stays in ~/.claude-mem on this machine.\n\nNothing leaves your machine except calls to whichever AI provider you configured for compression (Claude / OpenRouter / Gemini). The SQLite database, vector index, logs, and settings all live under that directory and are removed cleanly on `npx claude-mem uninstall`.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/how-it-works","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/how-it-works/SKILL.md","defaultBranch":"main"},"readme":"# How claude-mem works\n\n## What it does\n\nEvery Read, Edit, and Bash that Claude makes turns into a compressed observation. Observations get summarized at session end. Relevant ones get auto-injected into future prompts so the next session starts with context from the last one — no re-explaining the codebase, no re-discovering decisions.\n\n## When it kicks in\n\nMemory injection starts on your second session in a project.\n\nThe first session in a fresh project seeds memory; subsequent sessions receive auto-injected context for relevant past work. Run `/learn-codebase` if you want to front-load the entire repo into memory in a single pass (~5 minutes, optional).\n\n## Where data lives\n\nEverything stays in ~/.claude-mem on this machine.\n\nNothing leaves your machine except calls to whichever AI provider you configured for compression (Claude / OpenRouter / Gemini). The SQLite database, vector index, logs, and settings all live under that directory and are removed cleanly on `npx claude-mem uninstall`.","createdAt":"2026-09-25T10:51:51.737Z","updatedAt":"2026-09-25T10:51:51.737Z"},{"id":"cmugucisw0028qu06f8p3nnpk","slug":"thedotmack-claude-mem-do-2","name":"do","description":"Execute a phased implementation plan using subagents. Use when asked to execute, run, or carry out a plan — especially one created by make-plan.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"do","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Execute a phased implementation plan using subagents. Use when asked to execute, run, or carry out a plan — especially one created by make-plan.","permissions":[],"systemPrompt":"# Do Plan\n\nYou are an ORCHESTRATOR. Deploy subagents to execute *all* work. Do not do the work yourself except to coordinate, route context, and verify that each subagent completed its assigned checklist.\n\n## Execution Protocol\n\n### Rules\n\n- Each phase uses fresh subagents where noted (or when context is large/unclear)\n- Assign one clear objective per subagent and require evidence (commands run, outputs, files changed)\n- Do not advance to the next step until the assigned subagent reports completion and the orchestrator confirms it matches the plan\n\n### During Each Phase\n\nDeploy an \"Implementation\" subagent to:\n1. Execute the implementation as specified\n2. COPY patterns from documentation, don't invent\n3. Cite documentation sources in code comments when using unfamiliar APIs\n4. If an API seems missing, STOP and verify — don't assume it exists\n\n### After Each Phase\n\nDeploy subagents for each post-phase responsibility:\n1. **Run verification checklist** — Deploy a \"Verification\" subagent to prove the phase worked\n2. **Anti-pattern check** — Deploy an \"Anti-pattern\" subagent to grep for known bad patterns from the plan\n3. **Code quality review** — Deploy a \"Code Quality\" subagent to review changes\n4. **Commit only if verified** — Deploy a \"Commit\" subagent *only after* verification passes; otherwise, do not commit\n\n### Between Phases\n\nDeploy a \"Branch/Sync\" subagent to:\n- Push to working branch after each verified phase\n- Prepare the next phase handoff so the next phase's subagents start fresh but have plan context\n\n## Failure Modes to Prevent\n\n- Don't invent APIs that \"should\" exist — verify against docs\n- Don't add undocumented parameters — copy exact signatures\n- Don't skip verification — deploy a verification subagent and run the checklist\n- Don't commit before verification passes (or without explicit orchestrator approval)","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/do","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/do/SKILL.md","defaultBranch":"main"},"readme":"# Do Plan\n\nYou are an ORCHESTRATOR. Deploy subagents to execute *all* work. Do not do the work yourself except to coordinate, route context, and verify that each subagent completed its assigned checklist.\n\n## Execution Protocol\n\n### Rules\n\n- Each phase uses fresh subagents where noted (or when context is large/unclear)\n- Assign one clear objective per subagent and require evidence (commands run, outputs, files changed)\n- Do not advance to the next step until the assigned subagent reports completion and the orchestrator confirms it matches the plan\n\n### During Each Phase\n\nDeploy an \"Implementation\" subagent to:\n1. Execute the implementation as specified\n2. COPY patterns from documentation, don't invent\n3. Cite documentation sources in code comments when using unfamiliar APIs\n4. If an API seems missing, STOP and verify — don't assume it exists\n\n### After Each Phase\n\nDeploy subagents for each post-phase responsibility:\n1. **Run verification checklist** — Deploy a \"Verification\" subagent to prove the phase worked\n2. **Anti-pattern check** — Deploy an \"Anti-pattern\" subagent to grep for known bad patterns from the plan\n3. **Code quality review** — Deploy a \"Code Quality\" subagent to review changes\n4. **Commit only if verified** — Deploy a \"Commit\" subagent *only after* verification passes; otherwise, do not commit\n\n### Between Phases\n\nDeploy a \"Branch/Sync\" subagent to:\n- Push to working branch after each verified phase\n- Prepare the next phase handoff so the next phase's subagents start fresh but have plan context\n\n## Failure Modes to Prevent\n\n- Don't invent APIs that \"should\" exist — verify against docs\n- Don't add undocumented parameters — copy exact signatures\n- Don't skip verification — deploy a verification subagent and run the checklist\n- Don't commit before verification passes (or without explicit orchestrator approval)","createdAt":"2026-09-25T10:51:51.728Z","updatedAt":"2026-09-25T10:51:51.728Z"},{"id":"cmugucism0025qu06ncgxcjyp","slug":"thedotmack-claude-mem-design-is","name":"design-is","description":"Audit a design against Dieter Rams' ten \"Good design is...\" principles, then hand off a /make-plan prompt for one of three outcomes — new design, refine design, or redesign. Use when the user says \"audit this design\", \"design review\", \"check this UI against Rams\", \"is this UI good\", \"critique this design\", \"design audit\", or asks for a critique that should lead to a plan.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"design-is","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Audit a design against Dieter Rams' ten \"Good design is...\" principles, then hand off a /make-plan prompt for one of three outcomes — new design, refine design, or redesign. Use when the user says \"audit this design\", \"design review\", \"check this UI against Rams\", \"is this UI good\", \"critique this design\", \"design audit\", or asks for a critique that should lead to a plan.","permissions":[],"systemPrompt":"# Design Is\n\n## Do not use for\n\n- Routine UI code reviews → use `/review`\n- Pure copy edits → use a separate copy pass\n- Pre-design ideation with no artifact yet → start with `/make-plan` directly\n\nYou are an ORCHESTRATOR. Audit a design against Dieter Rams' ten principles, score each principle with evidence, decide the outcome verdict (NEW / REFINE / REDESIGN), and hand off to `/make-plan` with a ready-to-run prompt.\n\nYou do not write implementation code. You produce: evidence-cited scores, a verdict, and a `/make-plan` handoff prompt.\n\n## The Ten Principles (Dieter Rams)\n\nAudit each principle in this exact order. Each gets a score 0–3 and ≥1 piece of evidence (`file:line`, screenshot region, copy excerpt, or measured value).\n\n1. **Good design is innovative** — Does it advance the form, or imitate? Innovation rides on technology; never an end in itself.\n2. **Good design makes a product useful** — Does it serve the primary task? Emphasizes usefulness; disregards anything that detracts.\n3. **Good design is aesthetic** — Is it beautiful? Only well-executed objects can be beautiful; aesthetic quality affects well-being.\n4. **Good design makes a product understandable** — Does the structure clarify function? Or is it self-explanatory at best?\n5. **Good design is unobtrusive** — Does it stay out of the way? Neither decorative objects nor works of art — leave room for self-expression.\n6. **Good design is honest** — Does it claim only what it is? No false promises, no manipulation, no inflated value.\n7. **Good design is long-lasting** — Will it age well? Avoids being fashionable; never appears antiquated.\n8. **Good design is thorough down to the last detail** — Are edges, empty states, errors, focus rings, motion curves all considered? Care and accuracy express respect for the user.\n9. **Good design is environmentally friendly** — Does it conserve resources? Minimizes pollution — in software: bundle weight, energy, attention, cognitive load.\n10. **Good design is as little design as possible** — Less, but better. Concentrates on essentials; back to purity, back to simplicity.\n\n> The user wrote \"Dieter Braun\" — they mean Dieter Rams. Don't correct them inline; just use the right principles.\n\n## Delegation Model\n\nUse subagents for *evidence gathering* (reading components, measuring contrast, counting elements, inspecting tokens, screenshotting via agent-browser). Keep *scoring and verdict synthesis* with the orchestrator. Reject subagent reports that score without citing evidence and redeploy.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach evidence subagent response must include:\n1. Sources consulted — exact file paths and line ranges, or screenshot regions\n2. Concrete findings — what is present, what is missing, with quotes/values\n3. Per-principle facts (not opinions) — leave scoring to the orchestrator\n4. Known gaps — what could not be inspected and why\n\n## Output Artifacts\n\nAll artifacts go in `DESIGN-IS-<YYYY-MM-DD>/` at repo root (or the project the user points at):\n\n- `00-scope.md` — what was audited (URL, component paths, screens), input materials\n- `01-evidence.md` — per-principle evidence collected by subagents\n- `02-scorecard.md` — per-principle 0–3 score with one-line justification + total\n- `03-verdict.md` — NEW / REFINE / REDESIGN with reasoning\n- `04-handoff-prompt.md` — copy-pasteable `/make-plan` prompt for the chosen outcome\n\n## Phases\n\n### Phase 0: Scope Lock (ALWAYS FIRST)\n\nAsk the user (or infer from the request) and write `00-scope.md`:\n- What is being audited? (live URL, repo path, Figma frame, component name)\n- Who is the primary user, and what is the primary task?\n- Constraints (brand, stack, deadline)\n- Reference designs or competitors, if any\n\nIf the user is asking about a design that doesn't exist yet, skip Phases 1–2 and go straight to Phase 3 with verdict = **NEW**.\n\n### Phase 1: Evidence Gathering (FAN OUT)\n\nDeploy subagents in parallel. Each must return ONLY the required fields below — no prose paragraphs, no scoring.\n\n**1. Structural Evidence** subagent (always deploy)\nRequired fields returned:\n- Total interactive-element count on audited surface\n- Max nesting depth of the primary component tree\n- Repeated-pattern count (same affordance appearing >1 place with the same purpose)\n- Dead-prop / unused-import count\n- File:line citations for every count\n\n**2. Visual Evidence** subagent (always deploy)\nMode: if target is a reachable URL or running dev server → use the `agent-browser` skill for screenshots and computed-style inspection. If target is a static repo with no running instance → read source CSS / tokens / component files and report inferred facts only (mark these \"INFERRED\").\nRequired fields returned:\n- Spacing scale observed (px array)\n- Type scale observed (px array)\n- Distinct color count (count of unique hex/oklch tokens actually rendered or referenced)\n- Lowest contrast ratio observed across primary text\n- States present checklist: empty / loading / error / success / focus / disabled — present or missing for each\n\n**3. Copy & Honesty** subagent (always deploy)\nRequired fields returned:\n- List of every user-facing string with file:line\n- Flagged inflations (marketing superlatives without backing)\n- Flagged dark patterns (forced continuity, hidden cost, fake scarcity, confirmshaming)\n- Flagged jargon / unclear labels with proposed plain replacement\n- Label→behavior mismatches with file:line of both\n\n**4. Weight & Friction** subagent (always deploy)\nRequired fields returned:\n- Initial JS bytes (number)\n- Network request count for primary view (number)\n- Time-to-interactive ms (number, measured or estimated with method noted)\n- Animation count on idle screen (number)\n- Notification / badge / modal count on initial load (number)\n\n**5. Accessibility Evidence** subagent (OPTIONAL — deploy only if target has a meaningful interactive UI surface; skip for static landing pages without interaction)\nRequired fields returned:\n- WCAG contrast pass/fail per text token\n- Focus order list across primary controls\n- Keyboard reachability of every primary action (yes/no per action)\n- ARIA landmark count\n- Skip-link present (yes/no)\n\n**Principle → subagent mapping** (orchestrator uses this when scoring):\n\n| Principle | Fed by |\n|-----------|--------|\n| #1 innovative | orchestrator-only (judgment using all evidence) |\n| #2 useful | Structural, Accessibility |\n| #3 aesthetic | Visual |\n| #4 understandable | Structural, Copy & Honesty, Accessibility |\n| #5 unobtrusive | Structural, Visual |\n| #6 honest | Copy & Honesty |\n| #7 long-lasting | orchestrator-only (judgment using all evidence) |\n| #8 thorough | Visual |\n| #9 environmentally friendly | Weight & Friction |\n| #10 as little design as possible | Structural |\n\nThe orchestrator writes `01-evidence.md` consolidating all subagent reports. Reject any finding without a source citation. Subagents are explicitly forbidden from scoring — only the orchestrator scores, using the rubric in Phase 2.\n\n### Phase 2: Scorecard (ORCHESTRATOR)\n\nThe orchestrator scores each of the ten principles itself — do NOT delegate scoring.\n\nFor each principle, write to `02-scorecard.md`:\n\n```\nN. Good design is <principle> — Score: X/3\n Evidence: <one-line summary citing 01-evidence.md anchors>\n Justification: <one sentence on why this score, not the one above or below>\n```\n\nPer-principle scoring anchors (apply verbatim — pick the level whose signal best matches the audited surface):\n\n#1 innovative — 3: introduces a pattern not seen in 5+ peer products and ships it with restraint. 2: refreshes an existing pattern with a clear improvement. 1: imitates competitors with minor variation. 0: copies a competitor's flow wholesale.\n#2 useful — 3: primary task completes in fewest possible steps; no decoy actions. 2: primary task completes but adjacent surface adds steps. 1: primary task requires unnecessary detours. 0: primary task is not directly supported on the screen audited.\n#3 aesthetic — 3: spacing/type/color obey a single visible system; no orphan styles. 2: ≤2 minor inconsistencies across audited surface. 1: 3–5 inconsistencies OR one jarring violation. 0: no visible system OR active visual noise.\n#4 understandable — 3: a first-time user names every primary control correctly. 2: 1 control needs a tooltip. 1: 2–3 controls unclear; jargon present. 0: primary action is not identifiable without help.\n#5 unobtrusive — 3: chrome recedes; content is the figure, UI the ground. 2: chrome visible but quiet. 1: decoration competes with content. 0: chrome dominates content.\n#6 honest — 3: every claim, badge, and label maps 1:1 to actual behavior. 2: ≤1 minor inflation (e.g. \"powerful\" once). 1: 2+ inflations OR one dark pattern. 0: any deceptive flow (forced continuity, hidden cost, fake scarcity).\n#7 long-lasting — 3: visual language has no dated trend markers; would read as current 3 years from now. 2: 1 dated marker. 1: 2–3 dated markers (skeuomorph residue, fad gradients, trend typography). 0: design reads as a specific year's trend.\n#8 thorough — 3: empty / loading / error / success / focus / disabled all present and considered. 2: 1 state missing or rough. 1: 2–3 states missing. 0: 4+ states missing or default-browser.\n#9 environmentally friendly — 3: initial JS <100KB, no idle animation, dark mode honored, prefers-reduced-motion respected. 2: <500KB, motion gated. 1: 500KB–2MB, motion always on. 0: >2MB OR autoplay video OR dark mode ignored.\n#10 as little design as possible — 3: every element earns its place; removing any one breaks the task. 2: ≤2 removable elements. 1: 3–5 removable elements. 0: page is dominated by decoration or duplicated affordances.\n\nScoring rules:\n- **Tie-breaker rule**: When uncertain between two scores, pick the lower one. Convergence > generosity.\n- **Score worst, not mean**: When a principle has multiple representative instances on the audited surface, score the worst instance — not the average.\n- **No bonuses, no weights**: Scores stay 0–3 integer. Principles are equally weighted. Total is sum of ten scores, max 30.\n\n### Phase 3: Verdict (ORCHESTRATOR)\n\nWrite `03-verdict.md` with one of three verdicts, chosen by these rules:\n\n- **NEW DESIGN** — No design exists yet, OR the existing artifact is a stub/wireframe with no real decisions to preserve.\n- **REFINE** — Total score ≥ 20 AND no individual principle scored 0. The bones are good; iterate.\n- **REDESIGN** — Total score < 20, OR any principle scored 0 on a load-bearing dimension (typically #2 useful, #4 understandable, or #6 honest). Start over from purpose.\n\nState the verdict in one sentence. Then list the 3–5 highest-leverage moves — each tied to a specific principle and evidence anchor. These become the spine of the next phase's plan.\n\n**Anti-patterns to reject in your own verdict:**\n- Recommending REFINE because the codebase is large (sunk cost is not a design principle)\n- Recommending REDESIGN because a single screen is ugly (scope it)\n- Recommending NEW when an honest REDESIGN is warranted (don't dodge the critique)\n\n### Phase 4: /make-plan Handoff\n\nWrite `04-handoff-prompt.md` containing exactly ONE fenced `/make-plan` prompt matching the verdict. The prompt must be self-contained — the next session won't see this audit unless it's quoted in.\n\nUse the matching template below. Fill every `<bracket>`. Include the top 3–5 moves from Phase 3 verbatim, each with its evidence anchor.\n\n**Quote-in step (mandatory, applies to all three templates below):** Before emitting the handoff, replace EVERY `<bracket>` placeholder with concrete content from the audit. Inline the verdict paragraph from `03-verdict.md` and the top 3–5 moves verbatim into the template. Do NOT leave bare references like \"see DESIGN-IS-.../03-verdict.md\" — the next session won't have file access to the audit. The emitted handoff must be readable and actionable with zero external lookups.\n\n#### Template: NEW DESIGN\n\n````\n/make-plan Design <product/screen/component name> from scratch.\n\nPrimary user: <who>\nPrimary task: <one sentence>\nConstraints: <brand, stack, deadline, accessibility floor>\n\nNon-goals (do not design these now):\n- <explicit out-of-scope item 1>\n- <explicit out-of-scope item 2>\n- <explicit out-of-scope item 3>\n\nReference principles to optimize for, in order:\n1. Useful (#2) — <what useful looks like here>\n2. Understandable (#4) — <what clarity looks like here>\n3. As little design as possible (#10) — <what restraint looks like here>\n\nDeliverables for the plan:\n- Information architecture (one screen map or component tree)\n- Primary flow wireframe (low-fi, labeled)\n- Token decisions (type scale, spacing scale, color count cap)\n- States checklist (empty, loading, error, success, focus, disabled)\n- Honesty audit on every user-facing string before ship\n\nAnti-patterns to guard against (specific to NEW):\n- Decoration without function\n- Novel interactions without precedent\n- Copy that overpromises\n- Designing for screens the Non-goals list excluded\n````\n\n#### Template: REFINE DESIGN\n\n````\n/make-plan Refine <product/screen/component name> based on a Dieter Rams audit (total <X>/30).\n\nVerdict paragraph (quoted from 03-verdict.md):\n> <paste the one-sentence verdict here>\n\nKeep (already strong, do NOT touch in this pass):\n- Principle #<N> (<name>) scored 3 — Evidence: <file:line or anchor>. Regression check: <what to grep / re-test to confirm it still scores 3 after the refine>.\n- <repeat for every principle that scored 3>\n\nFix in priority order (top 3–5 moves from the audit, verbatim):\n1. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.\n2. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.\n3. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.\n4. <optional 4th>\n5. <optional 5th>\n\nOut of scope for this refine pass: <explicit list — what NOT to touch>\n\nDeliverables for the plan:\n- Per-fix: target files, exact change, verification step\n- Token/spec changes consolidated in one place\n- Regression checklist for every \"Keep\" item above\n\nAnti-patterns to guard against (specific to REFINE):\n- Adding new abstractions where a direct change suffices\n- Restyling areas that already scored 3\n- Scope creep into structural redesign (if structure must change, this should be REDESIGN, not REFINE)\n- Letting fixes mutate principles outside the priority list\n````\n\n#### Template: REDESIGN\n\n````\n/make-plan Redesign <product/screen/component name>. Current design failed audit at <X>/30 with critical gaps in principles <comma-separated list of 0-scored or 1-scored load-bearing principles>.\n\nVerdict paragraph (quoted from 03-verdict.md):\n> <paste the one-sentence verdict here>\n\nWhy redesign and not refine: <one sentence — usually a load-bearing principle (#2, #4, or #6) scored 0, or total is below threshold>\n\nPreserve from current design (MUST be non-empty — at minimum, name the brand tokens):\n- <specific element 1, with file:line>\n- <specific element 2, with file:line>\n- (if structurally nothing survives, write: \"Brand tokens only — color palette and logo. Discard everything else.\")\n\nDiscard (MUST be non-empty — name the structural patterns causing the failures):\n- <pattern 1>. Evidence: <file:line>. Caused failure on principle #<N>.\n- <pattern 2>. Evidence: <file:line>. Caused failure on principle #<N>.\n\nTop 3–5 moves from the audit (verbatim):\n1. <Principle # — short name>: <specific move>. Evidence: <file:line>.\n2. <Principle # — short name>: <specific move>. Evidence: <file:line>.\n3. <Principle # — short name>: <specific move>. Evidence: <file:line>.\n\nRedesign principles in priority order:\n1. <Principle # — name> — <what success looks like>\n2. <Principle # — name> — <what success looks like>\n3. <Principle # — name> — <what success looks like>\n\nDeliverables for the plan:\n- New information architecture (not derived from old)\n- New primary flow (low-fi, labeled, compared side-by-side to current)\n- States checklist (empty, loading, error, success, focus, disabled)\n- Migration path for users currently on the old design\n- Cutover criteria (when is the old design retired)\n\nAnti-patterns to guard against (specific to REDESIGN):\n- Porting old structure under new styling\n- Keeping both designs behind a flag indefinitely\n- Redesigning to follow a trend rather than the principles above\n- Treating the Preserve list as optional — it must be filled before this handoff is valid\n````\n\n## Key Principles (for the auditor)\n\n- **Evidence over taste** — every score cites a source; \"feels wrong\" is not a finding\n- **Score what is, not what was intended** — design is what ships, not what was drawn\n- **Honesty applies to the audit too** — if total is 28/30, say REFINE even if the user wanted a redesign; if it's 12/30, say REDESIGN even if the user wanted a refine\n- **One verdict, not three** — pick NEW or REFINE or REDESIGN; do not hedge\n- **Handoff, don't implement** — `design-is` ends at the `/make-plan` prompt; `/make-plan` and `/do` take it from there\n- **Verdict commitment** — Once `02-scorecard.md` is written, the verdict follows the Phase 3 rule mechanically. Never re-score to back into a preferred verdict; if the scorecard says REDESIGN, the handoff is REDESIGN.\n\n## Failure Modes to Prevent\n\n- Scoring from screenshots alone without reading the code — redeploy with structural subagent\n- Scoring the codebase instead of the design — re-anchor on user-facing evidence\n- Awarding 3s generously to soften the verdict — recalibrate against the per-principle anchors in Phase 2\n- Producing a handoff prompt that doesn't quote the verdict and top moves — the next session is blind without them\n- Skipping Phase 0 scope lock — auditing the wrong surface wastes Phase 1\n- **Sunk-cost reasoning** — recommending REFINE because the codebase is large; sunk cost is not a design principle\n- **Hedging across verdicts** — \"could be REFINE or REDESIGN depending on...\" — pick one\n- **Score inflation to match a desired verdict** — score the evidence, then read the verdict off the rule\n- **Letting Phase 0 user preference override Phase 3 evidence** — the user can disagree with the verdict, but the audit reports what the evidence says","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/design-is","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/design-is/SKILL.md","defaultBranch":"main"},"readme":"# Design Is\n\n## Do not use for\n\n- Routine UI code reviews → use `/review`\n- Pure copy edits → use a separate copy pass\n- Pre-design ideation with no artifact yet → start with `/make-plan` directly\n\nYou are an ORCHESTRATOR. Audit a design against Dieter Rams' ten principles, score each principle with evidence, decide the outcome verdict (NEW / REFINE / REDESIGN), and hand off to `/make-plan` with a ready-to-run prompt.\n\nYou do not write implementation code. You produce: evidence-cited scores, a verdict, and a `/make-plan` handoff prompt.\n\n## The Ten Principles (Dieter Rams)\n\nAudit each principle in this exact order. Each gets a score 0–3 and ≥1 piece of evidence (`file:line`, screenshot region, copy excerpt, or measured value).\n\n1. **Good design is innovative** — Does it advance the form, or imitate? Innovation rides on technology; never an end in itself.\n2. **Good design makes a product useful** — Does it serve the primary task? Emphasizes usefulness; disregards anything that detracts.\n3. **Good design is aesthetic** — Is it beautiful? Only well-executed objects can be beautiful; aesthetic quality affects well-being.\n4. **Good design makes a product understandable** — Does the structure clarify function? Or is it self-explanatory at best?\n5. **Good design is unobtrusive** — Does it stay out of the way? Neither decorative objects nor works of art — leave room for self-expression.\n6. **Good design is honest** — Does it claim only what it is? No false promises, no manipulation, no inflated value.\n7. **Good design is long-lasting** — Will it age well? Avoids being fashionable; never appears antiquated.\n8. **Good design is thorough down to the last detail** — Are edges, empty states, errors, focus rings, motion curves all considered? Care and accuracy express respect for the user.\n9. **Good design is environmentally friendly** — Does it conserve resources? Minimizes pollution — in software: bundle weight, energy, attention, cognitive load.\n10. **Good design is as little design as possible** — Less, but better. Concentrates on essentials; back to purity, back to simplicity.\n\n> The user wrote \"Dieter Braun\" — they mean Dieter Rams. Don't correct them inline; just use the right principles.\n\n## Delegation Model\n\nUse subagents for *evidence gathering* (reading components, measuring contrast, counting elements, inspecting tokens, screenshotting via agent-browser). Keep *scoring and verdict synthesis* with the orchestrator. Reject subagent reports that score without citing evidence and redeploy.\n\n### Subagent Reporting Contract (MANDATORY)\n\nEach evidence subagent response must include:\n1. Sources consulted — exact file paths and line ranges, or screenshot regions\n2. Concrete findings — what is present, what is missing, with quotes/values\n3. Per-principle facts (not opinions) — leave scoring to the orchestrator\n4. Known gaps — what could not be inspected and why\n\n## Output Artifacts\n\nAll artifacts go in `DESIGN-IS-<YYYY-MM-DD>/` at repo root (or the project the user points at):\n\n- `00-scope.md` — what was audited (URL, component paths, screens), input materials\n- `01-evidence.md` — per-principle evidence collected by subagents\n- `02-scorecard.md` — per-principle 0–3 score with one-line justification + total\n- `03-verdict.md` — NEW / REFINE / REDESIGN with reasoning\n- `04-handoff-prompt.md` — copy-pasteable `/make-plan` prompt for the chosen outcome\n\n## Phases\n\n### Phase 0: Scope Lock (ALWAYS FIRST)\n\nAsk the user (or infer from the request) and write `00-scope.md`:\n- What is being audited? (live URL, repo path, Figma frame, component name)\n- Who is the primary user, and what is the primary task?\n- Constraints (brand, stack, deadline)\n- Reference designs or competitors, if any\n\nIf the user is asking about a design that doesn't exist yet, skip Phases 1–2 and go straight to Phase 3 with verdict = **NEW**.\n\n### Phase 1: Evidence Gathering (FAN OUT)\n\nDeploy subagents in parallel. Each must return ONLY the required fields below — no prose paragra","createdAt":"2026-09-25T10:51:51.719Z","updatedAt":"2026-09-25T10:51:51.719Z"},{"id":"cmugucise0022qu064n2kkc7a","slug":"thedotmack-claude-mem-cloud-sync","name":"cloud-sync","description":"Set up or check claude-mem cloud sync with cmem.ai Pro. Use when the user says \"set up cloud sync\", \"sync my memories\", \"cmem pro\", \"cloud backup\", \"sync status\", or wants their memory database backed up or synced to their cmem.ai account.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"cloud-sync","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Set up or check claude-mem cloud sync with cmem.ai Pro. Use when the user says \"set up cloud sync\", \"sync my memories\", \"cmem pro\", \"cloud backup\", \"sync status\", or wants their memory database backed up or synced to their cmem.ai account.","permissions":["shell"],"systemPrompt":"# Cloud Sync (cmem.ai Pro)\n\nThe installed worker syncs through SyncHub. There is one client, one durable\noperation log, and no separate sync daemon. This skill checks status or writes\nthe three connection values issued by **cmem.ai → Connect**.\n\n**Security rule:** never print the sync token, put it in argv, or log it.\nConfirm only its length. Preserve every unrelated setting and keep\n`~/.claude-mem/settings.json` mode `0600`.\n\n## 1. Check status\n\nResolve the worker port and query the always-registered status route:\n\n```bash\nPORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\ncurl -s \"http://127.0.0.1:${PORT}/api/sync/status\"\n```\n\n- `configured: true` and `hub.reachable: true` → the worker completed an\n authenticated `GET /v1/sync/status` against SyncHub. Report `deviceId`,\n pending counts, `lastFlushAt`, `lastError`, and the Hub head/checkpoint;\n stop unless the user asked to replace the connection.\n- `configured: true` and `hub.reachable: false` → report `hub.error` and say\n the SyncHub connection is not verified. A zero pending count or\n `lastError: null` is not success because an empty queue performs no push.\n- `configured: false` → continue.\n- Connection refused, 404, or 503 immediately after restart → retry every\n three seconds for about 30 seconds before diagnosing the worker.\n\n## 2. Obtain the connection\n\nAsk for all three values shown by **cmem.ai → Connect**:\n\n1. sync token;\n2. user id;\n3. SyncHub URL.\n\nThe Hub URL must be an absolute `https://` URL. Do not substitute the cmem.ai\napplication API URL; the installed client talks only to SyncHub.\n\n## 3. Write installed-client settings\n\nSubstitute the collected values inside this quoted stdin script. Do not echo\nthem before or after running it:\n\n```bash\nnode - <<'EOF'\nconst fs = require('fs'), os = require('os'), path = require('path');\nconst token = 'PASTE_TOKEN_HERE';\nconst userId = 'PASTE_USER_ID_HERE';\nconst hubUrl = 'PASTE_HUB_URL_HERE';\nif (!token || !userId || !/^https:\\/\\/[^\\s]+$/.test(hubUrl)) {\n console.error('token, user id, and an https SyncHub URL are required');\n process.exit(1);\n}\nconst dir = path.join(os.homedir(), '.claude-mem');\nconst file = path.join(dir, 'settings.json');\nfs.mkdirSync(dir, { recursive: true });\nconst settings = fs.existsSync(file) ? JSON.parse(fs.readFileSync(file, 'utf8')) : {};\nconst target = settings.env && typeof settings.env === 'object' ? settings.env : settings;\ntarget.CLAUDE_MEM_CLOUD_SYNC_TOKEN = token;\ntarget.CLAUDE_MEM_CLOUD_SYNC_USER_ID = userId;\ntarget.CLAUDE_MEM_CLOUD_SYNC_HUB_URL = hubUrl.replace(/\\/+$/, '');\nfs.writeFileSync(file, JSON.stringify(settings, null, 2) + '\\n', { mode: 0o600 });\nfs.chmodSync(file, 0o600);\nconsole.log(`saved cloud connection: token length ${token.length}, user id length ${userId.length}`);\nEOF\n```\n\nThese are the only required connection keys. The worker mints and persists a\ndevice id on first start and defaults the device name to the hostname.\n\n## 4. Restart and verify\n\n```bash\ncurl -s -X POST \"http://127.0.0.1:${PORT}/api/admin/restart\"\n```\n\nPoll the status route every five seconds for up to 30 seconds while the\nsuccessor starts. Success means `configured: true`, `hub.reachable: true`, and\n`lastError: null`. The local route always makes an authenticated, read-only\nSyncHub status probe, even when every pending count is zero; it never uses a\nlegacy cmem.ai Pro status route and never appends or advances sync state.\nPending counts describe only writes made after the SyncHub launch baseline;\nsetup does not migrate a pre-launch local corpus.\n\nIf `hub.reachable` is false, report `hub.error`. If `lastError` is non-null,\nreport it too. Ask the user to verify the three values in **cmem.ai →\nConnect**. Never include the token.\n\n## 5. Report\n\nReport device id, pending counts, last successful flush, Hub reachability and\ncheckpoint, and any Hub/flush error. End with this privacy note:\n\n> Cloud sync uploads your observation narratives and full prompt text to your\n> cmem.ai account.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/cloud-sync","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/cloud-sync/SKILL.md","defaultBranch":"main"},"readme":"# Cloud Sync (cmem.ai Pro)\n\nThe installed worker syncs through SyncHub. There is one client, one durable\noperation log, and no separate sync daemon. This skill checks status or writes\nthe three connection values issued by **cmem.ai → Connect**.\n\n**Security rule:** never print the sync token, put it in argv, or log it.\nConfirm only its length. Preserve every unrelated setting and keep\n`~/.claude-mem/settings.json` mode `0600`.\n\n## 1. Check status\n\nResolve the worker port and query the always-registered status route:\n\n```bash\nPORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\ncurl -s \"http://127.0.0.1:${PORT}/api/sync/status\"\n```\n\n- `configured: true` and `hub.reachable: true` → the worker completed an\n authenticated `GET /v1/sync/status` against SyncHub. Report `deviceId`,\n pending counts, `lastFlushAt`, `lastError`, and the Hub head/checkpoint;\n stop unless the user asked to replace the connection.\n- `configured: true` and `hub.reachable: false` → report `hub.error` and say\n the SyncHub connection is not verified. A zero pending count or\n `lastError: null` is not success because an empty queue performs no push.\n- `configured: false` → continue.\n- Connection refused, 404, or 503 immediately after restart → retry every\n three seconds for about 30 seconds before diagnosing the worker.\n\n## 2. Obtain the connection\n\nAsk for all three values shown by **cmem.ai → Connect**:\n\n1. sync token;\n2. user id;\n3. SyncHub URL.\n\nThe Hub URL must be an absolute `https://` URL. Do not substitute the cmem.ai\napplication API URL; the installed client talks only to SyncHub.\n\n## 3. Write installed-client settings\n\nSubstitute the collected values inside this quoted stdin script. Do not echo\nthem before or after running it:\n\n```bash\nnode - <<'EOF'\nconst fs = require('fs'), os = require('os'), path = require('path');\nconst token = 'PASTE_TOKEN_HERE';\nconst userId = 'PASTE_USER_ID_HERE';\nconst hubUrl = 'PASTE_HUB_URL_HERE';\nif (!token || !userId || !/^https:\\/\\/[^\\s]+$/.test(hubUrl)) {\n console.error('token, user id, and an https SyncHub URL are required');\n process.exit(1);\n}\nconst dir = path.join(os.homedir(), '.claude-mem');\nconst file = path.join(dir, 'settings.json');\nfs.mkdirSync(dir, { recursive: true });\nconst settings = fs.existsSync(file) ? JSON.parse(fs.readFileSync(file, 'utf8')) : {};\nconst target = settings.env && typeof settings.env === 'object' ? settings.env : settings;\ntarget.CLAUDE_MEM_CLOUD_SYNC_TOKEN = token;\ntarget.CLAUDE_MEM_CLOUD_SYNC_USER_ID = userId;\ntarget.CLAUDE_MEM_CLOUD_SYNC_HUB_URL = hubUrl.replace(/\\/+$/, '');\nfs.writeFileSync(file, JSON.stringify(settings, null, 2) + '\\n', { mode: 0o600 });\nfs.chmodSync(file, 0o600);\nconsole.log(`saved cloud connection: token length ${token.length}, user id length ${userId.length}`);\nEOF\n```\n\nThese are the only required connection keys. The worker mints and persists a\ndevice id on first start and defaults the device name to the hostname.\n\n## 4. Restart and verify\n\n```bash\ncurl -s -X POST \"http://127.0.0.1:${PORT}/api/admin/restart\"\n```\n\nPoll the status route every five seconds for up to 30 seconds while the\nsuccessor starts. Success means `configured: true`, `hub.reachable: true`, and\n`lastError: null`. The local route always makes an authenticated, read-only\nSyncHub status probe, even when every pending count is zero; it never uses a\nlegacy cmem.ai Pro status route and never appends or advances sync state.\nPending counts describe only writes made after the SyncHub launch baseline;\nsetup does not migrate a pre-launch local corpus.\n\nIf `hub.reachable` is false, report `hub.error`. If `lastError` is non-null,\nrep","createdAt":"2026-09-25T10:51:51.711Z","updatedAt":"2026-09-25T10:51:51.711Z"},{"id":"cmugucis3001zqu06ovfcywrb","slug":"thedotmack-claude-mem-ccs-align","name":"ccs-align","description":"Run the CCS Align seat's hourly breathing cycle — prove the local claude-mem worker is healthy, pull needle observations through search → timeline → get_observations, land them in a seat-owned middle cache via atomic grab → append → filter exclude-marks → replace, manage exclude marks, and walk house → project → seat rules to detect conflicts (SHADOW_HOUSE, DENY_ALLOW, DRIFT, CLOCK_HEADER) with an append-only rules-report.md. Use when asked to run CCS Align, breathe the alignment seat, refresh the middle cache, exclude or restore an observation, walk rules, check rules conflicts, or check the Worker Watch board.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"ccs-align","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Run the CCS Align seat's hourly breathing cycle — prove the local claude-mem worker is healthy, pull needle observations through search → timeline → get_observations, land them in a seat-owned middle cache via atomic grab → append → filter exclude-marks → replace, manage exclude marks, and walk house → project → seat rules to detect conflicts (SHADOW_HOUSE, DENY_ALLOW, DRIFT, CLOCK_HEADER) with an append-only rules-report.md. Use when asked to run CCS Align, breathe the alignment seat, refresh the middle cache, exclude or restore an observation, walk rules, check rules conflicts, or check the Worker Watch board.","permissions":[],"systemPrompt":"# CCS Align — Worker Watch seat (Phases 0–2 shipped; Phase 3 = verify / sign-off)\n\nCCS Align is a **standing seat**, not a bird's-eye planner. Its one job, once an hour: talk to the **local** claude-mem worker, pull recent needle observations through the existing three-layer disclosure ladder, and land them in a **seat-owned middle cache** using grab → append → replace.\n\nThis skill implements the Phase 0 breathing slice, Phase 1 exclude marks, and Phase 2 rules alignment from the plan of record, `plans/2026-09-09-ccs-align.md`. Phases 0–2 are **shipped and merged** ([#3934](https://github.com/thedotmack/claude-mem/pull/3934), [#3935](https://github.com/thedotmack/claude-mem/pull/3935), [#3936](https://github.com/thedotmack/claude-mem/pull/3936)); Phase 3 is **verify / sign-off** (this loop) — no new product surface. It is **not** a context compiler, **not** Focus/mouth, and **not** Grok Memory Phase 2. When you speak to the human, address them as **Alex**.\n\n## What is implemented (Phases 0–2 shipped)\n\n- **Phase 0 — Breathing slice** ([#3934](https://github.com/thedotmack/claude-mem/pull/3934)): health check → `search` → `timeline` → `get_observations` → append records to `~/.claude-mem/ccs-align/<viewerId>/middle.jsonl` (atomic, deduped).\n- **Phase 1 — Exclude marks** ([#3935](https://github.com/thedotmack/claude-mem/pull/3935)): mark observations (and linked tool-use ids) as excluded from the compiled middle cache. \"Purge\" means the compiled `middle.jsonl` no longer contains the record — the diary / SQLite stay authoritative. Unmarking + rebuild restores the observation. `DELETE /api/observation/:id` is **forbidden**.\n- **Phase 2 — Rules alignment** ([#3936](https://github.com/thedotmack/claude-mem/pull/3936)): walk house → project → seat layers, detect conflicts (`SHADOW_HOUSE`, `DENY_ALLOW`, `DRIFT`, `CLOCK_HEADER`), emit an append-only `rules-report.md`. Optionally dry-run/apply `SHADOW_HOUSE` leaf patches when `CLAUDE_MEM_CCS_ALIGN_PATCH_SHADOWS=true`. Runs every 6th hour of the hourly Worker Watch cycle (D4). This is a **checklist**, not a parser — no `.cas` compiler.\n- **Phase 3 — Verify / sign-off** (this loop): re-run the regression tests and anti-pattern greps, prove the boundary (a scripted cycle dedupes, an exclude drops from the middle cache but not the diary, the rules report is produced or a MISS is recorded), and keep the skill + plan honest about what this seat is not. Phase 3 adds **no** new runtime behavior.\n- **Does not:** delete history, write `profile.md`, write LFG/Orifice `[awareness]` logs (that seam belongs to [#3931](https://github.com/thedotmack/claude-mem/pull/3931)), add a sixth `processAgentResponse` consumer, restart the worker, run a per-turn drip update, enforce Focus/mouth/standing rules, or copy house text into seats.\n\n## What this is NOT (honest boundary)\n\nCCS Align is deliberately small. It does **not** ship, and this loop does **not** add, any of the following — these are future work or a different agent, called out so no one reads more into the seat than is there:\n\n- **No context compiler.** There is no `.cas` parser, no `compileAwareness()`, no JIT compile, no computed-styles UI. The CCS Notion page types (`Bucket`, `canRead`) are teaching copy quoted as comments — never a runtime parser.\n- **No brainbeat product.** The \"regenerate awareness once per finished unit of work\" door is not built. Align *pulls* on an hourly cadence; it is not a per-turn drip and it is not a brainbeat.\n- **No attention trough / curse-salience.** No salience decay, no trough scoring. Explicitly out of every phase.\n- **No Focus / mouth enforcement.** Standing rules (always / never / danger) are never enforced or decayed here. Align may *list* a conflict; egress filtering belongs to a different agent.\n- **No second writer on LFG/Orifice `[awareness]` logs.** [#3931](https://github.com/thedotmack/claude-mem/pull/3931) owns `agents/**/memory/log/YYYY-MM.md`. Align writes only its seat-owned middle cache.\n- **No history rewrite.** Exclude marks filter the *compiled* cache; the diary / SQLite stay authoritative and rebuildable. No `DELETE /api/observation`, no A-MEM row rewrite.\n\n### Ops MISS — worker plugin version lag\n\nAs of this sign-off, the repo (package, plugin, marketplace) is at **13.24.5** (this Phase 3 PATCH), but the **running worker plugin on the house box may still be 13.24.1**. That is an **operational MISS to record, not fix here**: this seat does not restart or upgrade the worker (a hard forbid). If the live box still shows 13.24.1, note it when rolling status up to the Prioritizer so the worker gets restarted onto the current plugin out-of-band. If the running worker already matches the package version, this MISS is closed.\n\n## Prerequisites\n\nThe claude-mem worker must be running locally. This seat talks to the **local worker** (per-UID port ~`37700`), never the cloud CMEM MCP — cloud `observation:<base64>` ids are a different API and must not be mixed in.\n\n**Resolve the worker port** once and reuse `$WORKER_PORT` in every curl below. This snippet is copied from the `timeline-report` skill and honors `CLAUDE_MEM_WORKER_PORT` → `~/.claude-mem/settings.json` → the per-UID default `37700 + (uid % 100)`:\n\n```bash\nWORKER_PORT=\"${CLAUDE_MEM_WORKER_PORT:-$(node -e \"const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}\" 2>/dev/null)}\"\n```\n\nDo **not** hardcode port `37777` — ports are per-UID.\n\n## Settings\n\nDefaults live in `SettingsDefaultsManager.ts`; override in `~/.claude-mem/settings.json`:\n\n| Key | Default | Meaning |\n|---|---|---|\n| `CLAUDE_MEM_CCS_ALIGN_ENABLED` | `true` | Master switch for the seat. |\n| `CLAUDE_MEM_CCS_ALIGN_VIEWER_IDS` | `ccs-align` | Comma-separated viewer ids the seat maintains a cache for. |\n| `CLAUDE_MEM_CCS_ALIGN_TRIGGER_TYPES` | `decision,bugfix,security_alert,sensitive` | Needle observation types to pull (copied from #3931's list, D6). |\n| `CLAUDE_MEM_CCS_ALIGN_PATCH_SHADOWS` | `false` | Phase 2 rules-shadow patch gate. When `true`, the rules walker removes `SHADOW_HOUSE` duplicate lines from leaf files (atomic temp+rename). Default **off** — report-only. |\n\nPilot viewer id is `ccs-align`. The seat **may read** LFG observations (agent id `521e962d-2ec3-4488-bfbc-54d5209ce118`) as a project filter, but **must not write** LFG/Orifice monthly logs or any `profile.md`.\n\n## Hourly cycle (Appendix A runbook)\n\nRun this every hour on a weekday house board. One purpose. No watercooler. No \"while I was here I also…\".\n\n```\nevery hour (weekday house board):\n 1. Resolve WORKER_PORT (snippet above)\n 2. GET /api/health || GET /health → abort with a one-line miss if down\n 3. search(obs_type=needles, limit=20) since cursor.lastObservationId\n 4. timeline(anchor=newest) → collect neighbor ids\n 5. get_observations(ids=…)\n 5b. (Phase 1, mark-time only) If excluding: get_tool_uses for tool ids → record on mark\n 6. grab middle.jsonl → append new → filter exclude-marks → replace atomic\n 7. if original-cache path set and not writable: append-only to middle.jsonl (already done)\n 8. update cursor.json\n 9. every 6th hour: rules walk → append rules-report.md (Phase 2 — see below)\n 10. Speak to Alex only on red (worker down, write refused, unexpected profile.md touch)\n```\n\n### Step 1 — Resolve the port\n\nUse the `$WORKER_PORT` snippet above.\n\n### Step 2 — Prove worker health (prefer `/api/health`)\n\nPrefer `GET /api/health`; also accept the viewer alias `GET /health`. The public worker docs still show `GET /health` and a `port` field — both are stale. Health does **not** return a port; use `GET /api/stats` (`worker.port`) if you need it.\n\n```bash\ncurl -sS \"http://127.0.0.1:${WORKER_PORT}/api/health\" || curl -sS \"http://127.0.0.1:${WORKER_PORT}/health\"\n# expect a JSON body with \"status\":\"ok\". If the worker is down, abort with a\n# one-line miss — do NOT start it, do NOT retry aggressively.\n```\n\nIf health cannot be proven (e.g. no live worker in a cloud VM), record a **MISS** and stop. Do not fabricate a cache cycle.\n\n### Step 3 — Pull through the three-layer ladder (in order)\n\nThe disclosure order is **`search` → `timeline` → `get_observations`**. Never jump straight to `get_observations`, and do **not** call `get_tool_uses` in Phase 0 (that is Phase 1).\n\n1. **`search`** with the needle `obs_type` list (`CLAUDE_MEM_CCS_ALIGN_TRIGGER_TYPES`), `limit` ≤ 20, optionally scoped by `project`. Use the cursor's `lastObservationId` to avoid re-pulling the whole diary.\n\n ```bash\n curl -sS \"http://127.0.0.1:${WORKER_PORT}/api/search?query=*&type=decision&limit=20&format=json\"\n ```\n\n2. **`timeline`** anchored on the newest hit. The worker's **code default depth is 10** (`SearchManager.ts`) — the MCP text that says \"3\" is stale, so omit the depths (worker applies 10) or pass `10` explicitly.\n\n ```bash\n curl -sS \"http://127.0.0.1:${WORKER_PORT}/api/timeline?anchor=<newestObservationId>\"\n ```\n\n3. **`get_observations`** for the ids you will actually cache.\n\n ```bash\n curl -sS -X POST \"http://127.0.0.1:${WORKER_PORT}/api/observations/batch\" \\\n -H 'content-type: application/json' \\\n -d '{\"ids\":[12345,12346]}'\n ```\n\nThe MCP twins are `search` → `timeline` → `get_observations`. Worker `get_observations` ids are **numbers**; do not pass cloud `observation:<base64>` ids into `/api/observations/batch`.\n\n### Step 4 — Grab → append → filter exclude-marks → replace (atomic middle cache)\n\nLand the observations with the seat helper `src/services/integrations/CcsAlignMiddleCache.ts`\n(`landObservationsInMiddleCache`). It copies the #3931 atomic primitive\n(`appendAwarenessLineAtomic` + `awarenessLineBody`) with exactly three changes:\nthe tag is `[ccs-align]`, the path root is `~/.claude-mem/ccs-align/<viewerId>/`,\nand the file is `middle.jsonl`.\n\nPhase 1 adds an exclude-marks filter inside the atomic pipeline:\n\n```\ngrab: read middle.jsonl if it exists, else empty\nfilter: load exclude-marks.json; drop any record whose id is marked\nappend: for each new observation id not already present AND not marked, append one record\nreplace: write temp + rename (copy appendAwarenessLineAtomic; never appendFileSync)\nfallback: if an OPTIONAL original-cache path is set and not writable, skip grab/replace\n on that path and append timeline items to middle.jsonl only\n```\n\nThere is **no compiled laminate file in-repo**, so the fallback resolves to\n\"append to the seat file\" — never invent a laminate.\n\nEach line of `middle.jsonl` is one record. The shape is **locked** for Phase 0 (do not add fields):\n\n```json\n{\n \"v\": 1,\n \"id\": 12345,\n \"type\": \"decision\",\n \"title\": \"…\",\n \"created_at\": \"2026-09-09T00:00:00.000Z\",\n \"project\": \"claude-mem\",\n \"agent_id\": null,\n \"source\": \"worker\",\n \"line\": \"- 2026-09-09 [ccs-align] decision — …\"\n}\n```\n\n`line` is `formatCcsAlignLine` — the #3931 `formatAwarenessLine` with the tag\nswapped and the same 500-char truncation. Dedupe is by observation `id` **and**\nby body (the line from `[ccs-align]` onward, date excluded), so the same fact on\na new day is still skipped and the file does not grow on a repeat cycle.\n\nA minimal invocation (bun/node):\n\n```ts\nimport { landObservationsInMiddleCache } from '../../src/services/integrations/CcsAlignMiddleCache.js';\n\nlandObservationsInMiddleCache({\n viewerId: 'ccs-align',\n observations: rowsFromGetObservations, // [{ id, type, title, subtitle, facts, created_at, project, agent_id }]\n});\n```\n\nIt **never throws** into the caller — a broken write path is logged and swallowed.\n\n### Step 5 — Update the cursor\n\nWrite `~/.claude-mem/ccs-align/<viewerId>/cursor.json` so the next hour does not re-pull the whole diary:\n\n```json\n{ \"lastRunAt\": \"…\", \"lastObservationId\": 12345, \"healthPath\": \"/api/health\", \"workerPort\": 37700 }\n```\n\nUse `writeCursor` from the helper (atomic temp + rename).\n\n### Step 6 — Speak only on red\n\nRoll status **up** to the Prioritizer. Only speak to Alex on red: worker down, a write was refused, or an unexpected `profile.md` touch. Otherwise stay quiet.\n\n## Phase 1 — Exclude marks\n\n\"Purge\" means the compiled `middle.jsonl` no longer contains the observation or its tool I/O for that viewer. The diary stays. This is Secure Isolated Awareness + context-stripper — **not** delete.\n\n### Exclude-marks file\n\nEach viewer has `~/.claude-mem/ccs-align/<viewerId>/exclude-marks.json`:\n\n```json\n{\n \"v\": 1,\n \"marks\": [\n {\n \"observationId\": 12345,\n \"toolUseIds\": [\"toolu_01abc\", 678],\n \"reason\": \"sibling-wall|manual|stripper|secure-isolation\",\n \"markedAt\": \"2026-09-09T00:00:00.000Z\",\n \"markedBy\": \"ccs-align\"\n }\n ]\n}\n```\n\nMarks are managed by `addExcludeMark` / `removeExcludeMark` in `CcsAlignMiddleCache.ts`, or by manual JSON edit.\n\n### How marks get created (v1)\n\n1. **Manual JSON edit** — open `exclude-marks.json` and add a mark entry.\n2. **Skill flag** — `exclude <observationId> --reason …` (manual, sibling-wall, stripper, secure-isolation).\n3. No auto-promotion from chat text (poison surface — see Memory dig findings).\n\n### Purge tools (compiled only)\n\nWhen recording tool-use ids on a mark:\n\n1. After `get_observations`, if you need tool ids, call `get_tool_uses` / `POST /api/tool-uses/batch` (layer 4).\n2. Record those ids on the mark's `toolUseIds` array.\n3. **Never persist raw `tool_input` / `tool_response` into `middle.jsonl`** — layer 4 stays out of the laminate.\n4. **Do not** call `DELETE /api/observation/:id` — that tombstones the diary and breaks rebuild-from-history.\n\n> **Warning:** `get_tool_uses` is **layer 4** of the progressive disclosure ladder. It returns raw tool I/O and should only be called at mark-time to capture tool-use ids for an exclude mark. Never call it during the normal hourly cycle. Never persist its `tool_input` / `tool_response` payloads into any cache file.\n\n### Unmark + rebuild\n\nTo restore a previously excluded observation:\n\n1. Remove the mark from `exclude-marks.json` (`removeExcludeMark` or manual edit).\n2. Re-pull the diary through the three-layer ladder (`search` → `timeline` → `get_observations`).\n3. Call `rebuildMiddleCache` to clear and re-land the compiled file from the authoritative diary.\n\nThe observation reappears in `middle.jsonl` on the next cycle because the diary was never touched.\n\n### Viewer isolation\n\nEach viewer's middle cache is independent:\n\n- `~/.claude-mem/ccs-align/viewer-a/middle.jsonl`\n- `~/.claude-mem/ccs-align/viewer-b/middle.jsonl`\n\nObservations landed for viewer A never appear in viewer B's compiled file. Exclude marks for viewer A do not affect viewer B. This implements the Secure Isolated Awareness property: inject a unique eval token into viewer A's cache → run viewer B → assert A's token never appears in B's compiled file.\n\n### Programmatic usage\n\n```ts\nimport {\n addExcludeMark,\n removeExcludeMark,\n rebuildMiddleCache,\n ccsAlignExcludeMarksPath,\n readExcludeMarks,\n} from '../../src/services/integrations/CcsAlignMiddleCache.js';\n\nconst marksPath = ccsAlignExcludeMarksPath(dataRoot, 'ccs-align');\n\n// Mark an observation as excluded (with optional tool-use ids)\naddExcludeMark(marksPath, 12345, ['toolu_01abc'], 'manual');\n\n// Unmark and rebuild\nremoveExcludeMark(marksPath, 12345);\nrebuildMiddleCache({\n viewerId: 'ccs-align',\n observations: allObservationsFromDiary,\n dataRoot,\n});\n```\n\n## Hard forbids (every phase)\n\n- ❌ `DELETE /api/observation/:id` — tombstone ≠ exclude mark; breaks rebuild-from-history.\n- ❌ Writing LFG/Orifice `[awareness]` logs, or into any `agents/**/memory/log/` path.\n- ❌ Writing `profile.md`, user-memory, or project memory.\n- ❌ A top-of-prompt clock (timestamps belong on facts, not a cache header).\n- ❌ `POST /api/context/semantic` (per-turn drip the awareness design forbids).\n- ❌ A sixth `processAgentResponse` consumer — CCS Align **pulls**; #3931 owns that seam.\n- ❌ Restarting the worker, or `POST /api/settings`.\n- ❌ Addressing the human as \"Az\". Always **Alex**.\n- ❌ Claiming a context compiler / brainbeat shipped. Those are future work.\n- ❌ \"Fixing\" deny/allow by flipping rules — report only.\n- ❌ Copying house text into seats — that is the bug this phase detects.\n- ❌ Building a `.cas` compiler so the report looks smarter.\n- ❌ Patching standing / Focus / always / never / danger files.\n- ❌ Attention trough / curse-salience experiments (Phase-N backlog only).\n\n## Phase 2 — Rules alignment (house → project → seat)\n\nEvery 6th hour of the hourly Worker Watch cycle (D4), the seat walks house → project → seat layers to detect and report rules conflicts. This is a **checklist**, not a parser. No `.cas` compiler.\n\n### Cascade rules (from Notion CCS)\n\n- Write once at HOUSE; seats inherit\n- A leaf copy **shadows** the cascade (bug, not feature)\n- Deny beats allow\n- Siblings deny heavy buckets (`obs`, `note`, `person`) by default\n- Fail closed: if no rule exists, deny\n\n### Layer walk\n\n| Layer | Where to look (house box) | Bucket |\n|---|---|---|\n| House | `user-memory/` shared profile; Notion CCS `:root` | `profile`, `standing`, `owns` |\n| Project | `.cmem-projects/<project>/`, repo `CLAUDE.md` | project overrides |\n| Seat | `agents/<uuid>/profile.md`, `agents/<uuid>/memory/` | leaf — must not duplicate house |\n\nOn a box with no agent-data tree, the report records `MISS: house-box paths` and exits cleanly.\n\n### Conflict classes (v1)\n\n| Code | Pattern | Agency |\n|---|---|---|\n| `SHADOW_HOUSE` | Leaf file contains a line that also exists at house (or starts with `House rule`) | Dry-run remove-from-leaf; apply only if `CLAUDE_MEM_CCS_ALIGN_PATCH_SHADOWS=true` |\n| `DENY_ALLOW` | Same bucket allow at one layer, deny at another | Report only |\n| `DRIFT` | House text changed; leaf still has old wording (partial prefix match) | Report only |\n| `CLOCK_HEADER` | Top-of-prompt clock / \"current time is\" in a profile | Report only (house rule: no clock in the prefix) |\n\n### Rules report\n\nOutput: `~/.claude-mem/ccs-align/<viewerId>/rules-report.md` — dated, append-only sections. Each run appends a new section with a timestamp, a table of conflicts, any MISS entries, and a patches-applied count. Status rolls **up** to Prioritizer (never peer spam).\n\n### Limited patch (D8 default off)\n\nWhen `CLAUDE_MEM_CCS_ALIGN_PATCH_SHADOWS=true`:\n\n1. Only `SHADOW_HOUSE` conflicts are patched — never `DENY_ALLOW`, `DRIFT`, or `CLOCK_HEADER`.\n2. The would-be diff is written into the report **before** any patch is applied.\n3. The leaf file is copied, duplicate lines are stripped, and the file is replaced atomically (temp + rename, same primitive as `CcsAlignMiddleCache`).\n4. **Never patches `standing` / Focus / `always.md` / `never.md` / `danger.md` / `profile.md`.**\n5. House files are never modified.\n\n### Programmatic usage\n\n```ts\nimport {\n walkRules,\n discoverLayerPaths,\n type RulesWalkerConfig,\n} from '../../src/services/integrations/CcsAlignRulesWalker.js';\n\n// Discover paths on the current box\nconst paths = discoverLayerPaths({ project: 'claude-mem' });\n\nconst config: RulesWalkerConfig = {\n dataRoot: '~/.claude-mem',\n viewerId: 'ccs-align',\n patchShadows: false, // report-only by default\n housePaths: paths.housePaths,\n projectPaths: paths.projectPaths,\n seatPaths: paths.seatPaths,\n};\n\nconst result = walkRules(config);\n// result.conflicts — array of detected conflicts\n// result.misses — paths that were not found\n// result.reportPath — path to the appended rules-report.md\n// result.patchesApplied — number of SHADOW_HOUSE lines removed (0 if patchShadows=false)\n```\n\n## Phase 3 — Verify / sign-off (plan §3)\n\nPhase 3 closes the plan loop. It proves the seat is hourly-runnable, documented, and honest about what it is not — it does **not** add runtime behavior.\n\n**Prove the boundary, not the code (§3.1):**\n\n- One scripted cycle: health → `search` → `timeline` → `get_observations` → `middle.jsonl`.\n- A second cycle produces no duplicate lines (dedupe holds).\n- Exclude one id → gone from the middle cache, still returned by the worker (`GET /api/observation/N`).\n- A rules report is produced (or an explicit `MISS` on a box with no agent-data tree).\n- User-facing strings say **Alex**, never \"Az\"; no \"context compiler shipped / brainbeat is live / we compiled awareness\" claims (only future / not-this-plan wording).\n\n**Prove nothing regressed (§3.2):** run the tests in the Verification section below, including the #3931 pusher and transcript tests. #3931 behavior must stay: LFG/Orifice still get `[awareness]` lines from the **worker pusher**, not from Align.\n\n**Anti-pattern grep (§3.3):** no `DELETE /api/observation`, no `notifyGrokBotAwareness`, no `processAgentResponse` reuse in the seat helpers (forbid/comment mentions are fine — the seat must not *use* them).\n\n**Sign-off (§3.4):** this skill can be run by a Worker Watch seat with no extra product context; the shipped defaults still match the D-rows; the Prioritizer can roll this up as \"CCS Align Phase 0 green / Phase 1 marks / Phase 2 report.\"\n\nSee `plans/2026-09-09-ccs-align.md` §3 for the full contract.\n\n## Later phases (documented, not implemented)\n\n- **Full brainbeat / context compiler / `.cas` runtime** — future work, paper scaffold, out of this plan.\n- **Attention trough / curse-salience, Focus/mouth egress enforcement** — different agents / backlog; hard forbids here.\n\nSee `plans/2026-09-09-ccs-align.md` \"Explicit non-goals\" for the full list.\n\n## Verification (Phase 0 + Phase 1 + Phase 2)\n\n```bash\nbun test tests/integrations/ccs-align-middle-cache.test.ts\n# Phase 0: format/truncate, needle match, append, dedupe, path safety, never-throw, cursor round-trip\n# Phase 1: mark drop, diary present, tool ids not in middle.jsonl, viewer isolation,\n# unmark+rebuild, exclude-marks round-trip, buildExcludeSet, secure-isolation,\n# corrupt marks fail-closed, marked ids skipped on ingest\n\nbun test tests/integrations/ccs-align-rules-walker.test.ts\n# Phase 2: SHADOW_HOUSE detection (exact dup + \"House rule\" prefix), default report-only\n# (leaf unchanged), patchShadows=true (leaf loses duplicates, house unchanged),\n# never patches standing/always/never, MISS on absent paths, CLOCK_HEADER detection,\n# DENY_ALLOW detection, DRIFT detection, append-only report, atomic patch,\n# full walkRules integration, edge cases\n\n# #3931 must not regress — LFG/Orifice still get [awareness] lines from the worker pusher, not Align\nbun test tests/integrations/grok-bot-awareness-pusher.test.ts\n```\n\nVerification greps (plan §2.3):\n\n```bash\n# Report path documented\nrg -n \"rules-report\" plugin/skills/ccs-align/SKILL.md\n# expect ≥1\n\n# Patch gated\nrg -n \"CCS_ALIGN_PATCH_SHADOWS\" plugin/skills/ccs-align/SKILL.md\n# expect ≥1\n```\n\nLive-box checks (house, not CI — a cloud VM may have no live worker; record a MISS if so):\n\n- `curl -sS \"http://127.0.0.1:$WORKER_PORT/api/health\"` returns `status: ok`\n- After one cycle, `~/.claude-mem/ccs-align/ccs-align/middle.jsonl` exists\n- A second cycle with the same observations does **not** grow the file (dedupe)\n- Mark observation N → next cycle drops N from `middle.jsonl`\n- SQLite / `GET /api/observation/N` still returns the row (diary is authoritative)\n- Linked tool-use ids on the mark never appear in `middle.jsonl`\n- Viewer B's cache does not contain viewer A's unique eval token\n- Unmark (remove from JSON) + cycle restores N on the next pull\n- `profile.md` under any `agents/` path is byte-identical to before\n- LFG/Orifice `memory/log/YYYY-MM.md` unchanged by Align","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/ccs-align","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/ccs-align/SKILL.md","defaultBranch":"main"},"readme":"# CCS Align — Worker Watch seat (Phases 0–2 shipped; Phase 3 = verify / sign-off)\n\nCCS Align is a **standing seat**, not a bird's-eye planner. Its one job, once an hour: talk to the **local** claude-mem worker, pull recent needle observations through the existing three-layer disclosure ladder, and land them in a **seat-owned middle cache** using grab → append → replace.\n\nThis skill implements the Phase 0 breathing slice, Phase 1 exclude marks, and Phase 2 rules alignment from the plan of record, `plans/2026-09-09-ccs-align.md`. Phases 0–2 are **shipped and merged** ([#3934](https://github.com/thedotmack/claude-mem/pull/3934), [#3935](https://github.com/thedotmack/claude-mem/pull/3935), [#3936](https://github.com/thedotmack/claude-mem/pull/3936)); Phase 3 is **verify / sign-off** (this loop) — no new product surface. It is **not** a context compiler, **not** Focus/mouth, and **not** Grok Memory Phase 2. When you speak to the human, address them as **Alex**.\n\n## What is implemented (Phases 0–2 shipped)\n\n- **Phase 0 — Breathing slice** ([#3934](https://github.com/thedotmack/claude-mem/pull/3934)): health check → `search` → `timeline` → `get_observations` → append records to `~/.claude-mem/ccs-align/<viewerId>/middle.jsonl` (atomic, deduped).\n- **Phase 1 — Exclude marks** ([#3935](https://github.com/thedotmack/claude-mem/pull/3935)): mark observations (and linked tool-use ids) as excluded from the compiled middle cache. \"Purge\" means the compiled `middle.jsonl` no longer contains the record — the diary / SQLite stay authoritative. Unmarking + rebuild restores the observation. `DELETE /api/observation/:id` is **forbidden**.\n- **Phase 2 — Rules alignment** ([#3936](https://github.com/thedotmack/claude-mem/pull/3936)): walk house → project → seat layers, detect conflicts (`SHADOW_HOUSE`, `DENY_ALLOW`, `DRIFT`, `CLOCK_HEADER`), emit an append-only `rules-report.md`. Optionally dry-run/apply `SHADOW_HOUSE` leaf patches when `CLAUDE_MEM_CCS_ALIGN_PATCH_SHADOWS=true`. Runs every 6th hour of the hourly Worker Watch cycle (D4). This is a **checklist**, not a parser — no `.cas` compiler.\n- **Phase 3 — Verify / sign-off** (this loop): re-run the regression tests and anti-pattern greps, prove the boundary (a scripted cycle dedupes, an exclude drops from the middle cache but not the diary, the rules report is produced or a MISS is recorded), and keep the skill + plan honest about what this seat is not. Phase 3 adds **no** new runtime behavior.\n- **Does not:** delete history, write `profile.md`, write LFG/Orifice `[awareness]` logs (that seam belongs to [#3931](https://github.com/thedotmack/claude-mem/pull/3931)), add a sixth `processAgentResponse` consumer, restart the worker, run a per-turn drip update, enforce Focus/mouth/standing rules, or copy house text into seats.\n\n## What this is NOT (honest boundary)\n\nCCS Align is deliberately small. It does **not** ship, and this loop does **not** add, any of the following — these are future work or a different agent, called out so no one reads more into the seat than is there:\n\n- **No context compiler.** There is no `.cas` parser, no `compileAwareness()`, no JIT compile, no computed-styles UI. The CCS Notion page types (`Bucket`, `canRead`) are teaching copy quoted as comments — never a runtime parser.\n- **No brainbeat product.** The \"regenerate awareness once per finished unit of work\" door is not built. Align *pulls* on an hourly cadence; it is not a per-turn drip and it is not a brainbeat.\n- **No attention trough / curse-salience.** No salience decay, no trough scoring. Explicitly out of every phase.\n- **No Focus / mouth enforcement.** Standing rules (always / never / danger) are never enforced or decayed here. Align may *list* a conflict; egress filtering belongs to a different agent.\n- **No second writer on LFG/Orifice `[awareness]` logs.** [#3931](https://github.com/thedotmack/claude-mem/pull/3931) owns `agents/**/memory/log/YYYY-MM.md`. Align writes only its seat-owned middle cache.\n- **No his","createdAt":"2026-09-25T10:51:51.699Z","updatedAt":"2026-09-25T10:51:51.699Z"},{"id":"cmugucirt001wqu063jhe6ygd","slug":"thedotmack-claude-mem-babysit","name":"babysit","description":"Watch a pull request or review cycle until it is ready to merge. Use when asked to babysit, monitor, or keep checking PR comments, reviews, and CI until all actionable issues are resolved.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"babysit","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Watch a pull request or review cycle until it is ready to merge. Use when asked to babysit, monitor, or keep checking PR comments, reviews, and CI until all actionable issues are resolved.","permissions":[],"systemPrompt":"# Babysit PR\n\nStay with the PR until it is actually clean. Do not stop after one check pass if comments or review threads are still unresolved.\n\n## Workflow\n\n1. Identify the PR number, branch, and base branch.\n2. Confirm the PR is not draft and inspect mergeability, checks, review decision, comments, and review threads.\n3. Watch pending checks until they finish. Poll at a practical interval, usually 30-60 seconds unless the user asks for a different cadence.\n4. Read new comments and unresolved review threads. Treat bot summaries as useful, but verify actionable findings against the code.\n5. Fix real issues in focused commits, run relevant tests/builds, push, and return to step 2.\n6. Resolve stale review threads only after verifying the code or generated artifact now addresses the comment.\n7. Stop only when checks are passing or intentionally skipped, review decision is acceptable, no actionable comments remain, and no unresolved review threads remain.\n\n## GitHub CLI Checks\n\nUse `gh pr view` for the coarse status:\n\n```bash\ngh pr view <number> --json \\\n number,state,isDraft,mergeable,mergeStateStatus,reviewDecision,headRefOid,statusCheckRollup,url\n```\n\nResolve the repository owner/name before using GraphQL:\n\n```bash\nrepo_json=$(gh repo view --json owner,name)\nowner=$(jq -r '.owner.login // .owner.name' <<<\"$repo_json\")\nrepo=$(jq -r '.name' <<<\"$repo_json\")\n```\n\nUse GraphQL for unresolved review threads. Include `pageInfo`; omit `cursor` on the first page, then pass the previous `endCursor` with `-f cursor=\"$cursor\"` while `hasNextPage` is `true`.\n\n```bash\ngh api graphql \\\n -f query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}' \\\n -f owner=\"$owner\" -f repo=\"$repo\" -F number=<number>\n```\n\nUse this loop when a PR may have many review threads:\n\n```bash\nthread_query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}'\ncursor_args=()\n\nwhile :; do\n page=$(gh api graphql -f query=\"$thread_query\" -f owner=\"$owner\" -f repo=\"$repo\" -F number=<number> \"${cursor_args[@]}\")\n printf '%s\\n' \"$page\" | jq -r '.data.repository.pullRequest.reviewThreads.nodes[]\n | select(.isResolved==false)\n | [.id,.path,(.line//\"\"),(.isOutdated|tostring),(.comments.nodes[-1].author.login//\"\"),(.comments.nodes[-1].body|gsub(\"\\n\";\" \")|.[0:240])]\n | @tsv'\n\n jq -e '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' >/dev/null <<<\"$page\" || break\n cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' <<<\"$page\")\n cursor_args=(-f cursor=\"$cursor\")\ndone\n```\n\nFilter unresolved threads with `jq`:\n\n```bash\njq -r '.data.repository.pullRequest.reviewThreads.nodes[]\n | select(.isResolved==false)\n | [.id,.path,(.line//\"\"),(.isOutdated|tostring),(.comments.nodes[-1].author.login//\"\"),(.comments.nodes[-1].body|gsub(\"\\n\";\" \")|.[0:240])]\n | @tsv'\n```\n\nResolve a stale thread only when the fix is verified:\n\n```bash\ngh api graphql \\\n -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{id,isResolved}}}' \\\n -f threadId=<thread-id>\n```\n\n## Operating Rules\n\n- Keep the watcher running while long checks are pending.\n- If a generated file is part of the distribution, verify the source and generated artifact agree before resolving comments.\n- If a bot reports an issue against stale code, confirm whether the thread is outdated or addressed in the latest head.\n- Before final reporting, do one fresh sweep of PR status, unresolved threads, recent comments, and local `git status`.\n- Report concrete evidence: latest commit SHA, check names and results, unresolved thread count, tests run, and any dirty local files left untouched.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/plugin/skills/babysit","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"plugin/skills/babysit/SKILL.md","defaultBranch":"main"},"readme":"# Babysit PR\n\nStay with the PR until it is actually clean. Do not stop after one check pass if comments or review threads are still unresolved.\n\n## Workflow\n\n1. Identify the PR number, branch, and base branch.\n2. Confirm the PR is not draft and inspect mergeability, checks, review decision, comments, and review threads.\n3. Watch pending checks until they finish. Poll at a practical interval, usually 30-60 seconds unless the user asks for a different cadence.\n4. Read new comments and unresolved review threads. Treat bot summaries as useful, but verify actionable findings against the code.\n5. Fix real issues in focused commits, run relevant tests/builds, push, and return to step 2.\n6. Resolve stale review threads only after verifying the code or generated artifact now addresses the comment.\n7. Stop only when checks are passing or intentionally skipped, review decision is acceptable, no actionable comments remain, and no unresolved review threads remain.\n\n## GitHub CLI Checks\n\nUse `gh pr view` for the coarse status:\n\n```bash\ngh pr view <number> --json \\\n number,state,isDraft,mergeable,mergeStateStatus,reviewDecision,headRefOid,statusCheckRollup,url\n```\n\nResolve the repository owner/name before using GraphQL:\n\n```bash\nrepo_json=$(gh repo view --json owner,name)\nowner=$(jq -r '.owner.login // .owner.name' <<<\"$repo_json\")\nrepo=$(jq -r '.name' <<<\"$repo_json\")\n```\n\nUse GraphQL for unresolved review threads. Include `pageInfo`; omit `cursor` on the first page, then pass the previous `endCursor` with `-f cursor=\"$cursor\"` while `hasNextPage` is `true`.\n\n```bash\ngh api graphql \\\n -f query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}' \\\n -f owner=\"$owner\" -f repo=\"$repo\" -F number=<number>\n```\n\nUse this loop when a PR may have many review threads:\n\n```bash\nthread_query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}'\ncursor_args=()\n\nwhile :; do\n page=$(gh api graphql -f query=\"$thread_query\" -f owner=\"$owner\" -f repo=\"$repo\" -F number=<number> \"${cursor_args[@]}\")\n printf '%s\\n' \"$page\" | jq -r '.data.repository.pullRequest.reviewThreads.nodes[]\n | select(.isResolved==false)\n | [.id,.path,(.line//\"\"),(.isOutdated|tostring),(.comments.nodes[-1].author.login//\"\"),(.comments.nodes[-1].body|gsub(\"\\n\";\" \")|.[0:240])]\n | @tsv'\n\n jq -e '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' >/dev/null <<<\"$page\" || break\n cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' <<<\"$page\")\n cursor_args=(-f cursor=\"$cursor\")\ndone\n```\n\nFilter unresolved threads with `jq`:\n\n```bash\njq -r '.data.repository.pullRequest.reviewThreads.nodes[]\n | select(.isResolved==false)\n | [.id,.path,(.line//\"\"),(.isOutdated|tostring),(.comments.nodes[-1].author.login//\"\"),(.comments.nodes[-1].body|gsub(\"\\n\";\" \")|.[0:240])]\n | @tsv'\n```\n\nResolve a stale thread only when the fix is verified:\n\n```bash\ngh api graphql \\\n -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{id,isResolved}}}' \\\n -f threadId=<thread-id>\n```\n\n## Operating Rules\n\n- Keep the watcher running while long checks are pending.\n- If a generated file is part of the distribution, verify the source and generated artifact agree before resolving comments.\n- If a bot reports an issue against stale code, confirm whether the thread is outdated or addressed in the latest head.\n- Before final reporting, do one fresh sweep of PR status, unresolved threads, recent comments, and local `git status`.\n- Report concrete evi","createdAt":"2026-09-25T10:51:51.689Z","updatedAt":"2026-09-25T10:51:51.689Z"},{"id":"cmugucirm001tqu06vuvqm7g9","slug":"thedotmack-claude-mem-make-plan","name":"make-plan","description":"../../../plugin/skills/make-plan/SKILL.md","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"make-plan","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"../../../plugin/skills/make-plan/SKILL.md","permissions":[],"systemPrompt":"../../../plugin/skills/make-plan/SKILL.md","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/openclaw/skills/make-plan","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"openclaw/skills/make-plan/SKILL.md","defaultBranch":"main"},"readme":"../../../plugin/skills/make-plan/SKILL.md","createdAt":"2026-09-25T10:51:51.682Z","updatedAt":"2026-09-25T10:51:51.682Z"},{"id":"cmugucirf001qqu06y6m5zfvo","slug":"thedotmack-claude-mem-do","name":"do","description":"../../../plugin/skills/do/SKILL.md","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"do","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"../../../plugin/skills/do/SKILL.md","permissions":[],"systemPrompt":"../../../plugin/skills/do/SKILL.md","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/openclaw/skills/do","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"openclaw/skills/do/SKILL.md","defaultBranch":"main"},"readme":"../../../plugin/skills/do/SKILL.md","createdAt":"2026-09-25T10:51:51.675Z","updatedAt":"2026-09-25T10:51:51.675Z"},{"id":"cmugucir6001nqu0644ckdppw","slug":"thedotmack-claude-mem-mem-setup","name":"mem-setup","description":"This skill should be used when the user asks to \"set up claude-mem\", \"pair claude-mem\", \"connect cmem\", \"add my cmem key\", \"set up cloud sync in Cowork\", or provides cmem.ai Connect values (sync token, user id, SyncHub URL) for this plugin. Configures the claude-mem-cowork plugin credentials.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"mem-setup","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"This skill should be used when the user asks to \"set up claude-mem\", \"pair claude-mem\", \"connect cmem\", \"add my cmem key\", \"set up cloud sync in Cowork\", or provides cmem.ai Connect values (sync token, user id, SyncHub URL) for this plugin. Configures the claude-mem-cowork plugin credentials.","permissions":[],"systemPrompt":"# Claude-Mem Setup (Cowork pairing)\n\nConfigure this plugin with the user's own cmem.ai credentials so hooks can\ncapture and inject memory. Anyone can pair — credentials are per-user\nconfiguration, never hardcoded in plugin logic.\n\n## What to collect\n\nFrom **cmem.ai → Connect**, the user has three values:\n\n1. **sync token** (starts with `cm_`) — used as the bearer API key\n2. **user id** (UUID)\n3. **SyncHub URL** (a workers.dev or cmem.ai URL)\n\nIf the user pastes the whole Connect blurb, extract the three values from it.\nIf any are missing, ask for the sync token at minimum — the other two are\noptional.\n\n## Secret handling — non-negotiable\n\n- Never echo the token back in conversation, put it in a shell argv, or log it.\n- Move it only via file writes (Write/Edit tool) and file reads.\n\n## Steps\n\n1. Locate the installed plugin root (this skill's own plugin). Update its\n `config.json`: set `apiKey` to the sync token, `userId`, and `syncHubUrl`.\n Leave other settings unless the user asks (`inject` toggles). Project naming\n is automatic (`cmem_work_*`) and is not configurable.\n2. Cowork containers are ephemeral: edits to the installed copy last only for\n this session. To make pairing permanent, repackage — zip the plugin\n directory as `<plugin-name>.plugin` and send it to the user to re-install\n (the cowork-plugin skill's packaging flow). Tell the user this is why.\n3. If this machine also has a local claude-mem install (a `~/.claude-mem/`\n directory exists), optionally write the same values to\n `~/.claude-mem/settings.json` with mode 0600 (`CLAUDE_MEM_CLOUD_SYNC_TOKEN`,\n `CLAUDE_MEM_CLOUD_SYNC_USER_ID`, `CLAUDE_MEM_CLOUD_SYNC_HUB_URL` keys — the\n same keys the local claude-mem cloud-sync pairing writes) — the hook script\n and the local worker both read it.\n4. Verify without exposing the secret:\n\n ```bash\n node \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" status\n ```\n\n Report the masked output. A `MISSING` key means the write didn't land;\n a 404 on `/api/hooks/context` is expected until the Pro endpoints deploy\n (search/injection still work via `/api/mcp`).\n\n## Alternate source\n\nEnv vars override everything and need no file edits: `CMEM_API_KEY`,\n`CMEM_USER_ID`, `CMEM_SYNC_HUB_URL`, `CMEM_API_BASE`.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/cowork/skills/mem-setup","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"cowork/skills/mem-setup/SKILL.md","defaultBranch":"main"},"readme":"# Claude-Mem Setup (Cowork pairing)\n\nConfigure this plugin with the user's own cmem.ai credentials so hooks can\ncapture and inject memory. Anyone can pair — credentials are per-user\nconfiguration, never hardcoded in plugin logic.\n\n## What to collect\n\nFrom **cmem.ai → Connect**, the user has three values:\n\n1. **sync token** (starts with `cm_`) — used as the bearer API key\n2. **user id** (UUID)\n3. **SyncHub URL** (a workers.dev or cmem.ai URL)\n\nIf the user pastes the whole Connect blurb, extract the three values from it.\nIf any are missing, ask for the sync token at minimum — the other two are\noptional.\n\n## Secret handling — non-negotiable\n\n- Never echo the token back in conversation, put it in a shell argv, or log it.\n- Move it only via file writes (Write/Edit tool) and file reads.\n\n## Steps\n\n1. Locate the installed plugin root (this skill's own plugin). Update its\n `config.json`: set `apiKey` to the sync token, `userId`, and `syncHubUrl`.\n Leave other settings unless the user asks (`inject` toggles). Project naming\n is automatic (`cmem_work_*`) and is not configurable.\n2. Cowork containers are ephemeral: edits to the installed copy last only for\n this session. To make pairing permanent, repackage — zip the plugin\n directory as `<plugin-name>.plugin` and send it to the user to re-install\n (the cowork-plugin skill's packaging flow). Tell the user this is why.\n3. If this machine also has a local claude-mem install (a `~/.claude-mem/`\n directory exists), optionally write the same values to\n `~/.claude-mem/settings.json` with mode 0600 (`CLAUDE_MEM_CLOUD_SYNC_TOKEN`,\n `CLAUDE_MEM_CLOUD_SYNC_USER_ID`, `CLAUDE_MEM_CLOUD_SYNC_HUB_URL` keys — the\n same keys the local claude-mem cloud-sync pairing writes) — the hook script\n and the local worker both read it.\n4. Verify without exposing the secret:\n\n ```bash\n node \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" status\n ```\n\n Report the masked output. A `MISSING` key means the write didn't land;\n a 404 on `/api/hooks/context` is expected until the Pro endpoints deploy\n (search/injection still work via `/api/mcp`).\n\n## Alternate source\n\nEnv vars override everything and need no file edits: `CMEM_API_KEY`,\n`CMEM_USER_ID`, `CMEM_SYNC_HUB_URL`, `CMEM_API_BASE`.","createdAt":"2026-09-25T10:51:51.667Z","updatedAt":"2026-09-25T10:51:51.667Z"},{"id":"cmuguciqy001kqu06vtvfm5ch","slug":"thedotmack-claude-mem-mem-search-3","name":"mem-search","description":"This skill should be used when the user asks to \"search memory\", \"what do you remember about X\", \"check claude-mem\", \"mem search\", \"find past observations\", \"what did we do last session\", or wants prior-session context about a project, decision, file, or task. Searches the user's Claude-Mem (cmem.ai) memory.","authorId":"gh:thedotmack","authorName":"thedotmack","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":94658,"pricePerCall":0,"manifest":{"name":"mem-search","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"This skill should be used when the user asks to \"search memory\", \"what do you remember about X\", \"check claude-mem\", \"mem search\", \"find past observations\", \"what did we do last session\", or wants prior-session context about a project, decision, file, or task. Searches the user's Claude-Mem (cmem.ai) memory.","permissions":[],"systemPrompt":"# Claude-Mem Search (Cowork)\n\nSearch the user's persistent Claude-Mem memory on cmem.ai. Memory contains\ntimestamped observations synthesized from past sessions across all their\nagents (Claude Code, Cowork, Codex, and others).\n\n## How to search\n\nRun the bundled CLI (no dependencies, uses the plugin's configured API key):\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" search \"your query\" --limit 20\n```\n\n## Progressive search method\n\nFollow claude-mem's Index → Timeline → Transcript discipline — cheap passes\nfirst, expensive detail only for confirmed hits:\n\n1. **Index pass** — run 1–3 broad keyword searches (project names, file names,\n error strings, feature names). Skim titles/summaries only.\n2. **Narrow pass** — re-search with the most specific terms found in step 1\n (IDs, exact phrases) and a smaller `--limit`.\n3. **Answer** — synthesize from the observations returned. Quote timestamps\n when the user asks \"when\".\n\nDo not dump raw search output at the user; extract the relevant observations\nand answer in plain language.\n\n## Diagnostics\n\nIf searches return nothing or error:\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" status\n```\n\nReport the status output plainly: a MISSING api key means the plugin needs the\nuser's cmem.ai key added to its configuration; a 404 on `/api/hooks/context`\njust means the newer Pro endpoint isn't deployed — search still works via\n`/api/mcp`.\n\n## Notes\n\n- Some filters (date ranges, type) may be silently ignored by the cloud API\n until MCP parity ships — prefer keyword narrowing over filter flags.\n- Never write secrets into search queries; queries are sent to cmem.ai.","schemaVersion":1},"repoUrl":"https://github.com/thedotmack/claude-mem/tree/main/cowork/skills/mem-search","tags":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"claude-mem","audit":{"files":["openclaw/package.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-04","message":"No npm lock file: installs resolve whatever the ranges allow today.","surface":"package.json","evidence":"@better-auth/api-key@^1.6.16, better-auth@^1.6.16","severity":"medium"}],"packages":2,"auditedAt":"2026-09-25T10:51:51.575Z","lockfiles":[]},"forks":8366,"owner":"thedotmack","stars":94658,"topics":["ai","ai-agents","ai-memory","anthropic","artificial-intelligence","chromadb","claude","claude-agent-sdk","claude-agents","claude-code","claude-code-plugin","claude-skills","embeddings","long-term-memory","mem0","memory-engine","openmemory","rag","sqlite","supermemory"],"license":"Apache-2.0","fullName":"thedotmack/claude-mem","homepage":"https://claude-mem.ai","language":"TypeScript","pushedAt":"2026-09-25T01:11:49Z","avatarUrl":"https://avatars.githubusercontent.com/u/683968?v=4","crawledAt":"2026-09-25T10:51:42.785Z","openIssues":296,"manifestFile":"SKILL.md","manifestPath":"cowork/skills/mem-search/SKILL.md","defaultBranch":"main"},"readme":"# Claude-Mem Search (Cowork)\n\nSearch the user's persistent Claude-Mem memory on cmem.ai. Memory contains\ntimestamped observations synthesized from past sessions across all their\nagents (Claude Code, Cowork, Codex, and others).\n\n## How to search\n\nRun the bundled CLI (no dependencies, uses the plugin's configured API key):\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" search \"your query\" --limit 20\n```\n\n## Progressive search method\n\nFollow claude-mem's Index → Timeline → Transcript discipline — cheap passes\nfirst, expensive detail only for confirmed hits:\n\n1. **Index pass** — run 1–3 broad keyword searches (project names, file names,\n error strings, feature names). Skim titles/summaries only.\n2. **Narrow pass** — re-search with the most specific terms found in step 1\n (IDs, exact phrases) and a smaller `--limit`.\n3. **Answer** — synthesize from the observations returned. Quote timestamps\n when the user asks \"when\".\n\nDo not dump raw search output at the user; extract the relevant observations\nand answer in plain language.\n\n## Diagnostics\n\nIf searches return nothing or error:\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}/scripts/cmem-hook.mjs\" status\n```\n\nReport the status output plainly: a MISSING api key means the plugin needs the\nuser's cmem.ai key added to its configuration; a 404 on `/api/hooks/context`\njust means the newer Pro endpoint isn't deployed — search still works via\n`/api/mcp`.\n\n## Notes\n\n- Some filters (date ranges, type) may be silently ignored by the cloud API\n until MCP parity ships — prefer keyword narrowing over filter flags.\n- Never write secrets into search queries; queries are sent to cmem.ai.","createdAt":"2026-09-25T10:51:51.658Z","updatedAt":"2026-09-25T10:51:51.658Z"}],"total":1060,"limit":24,"offset":0}