keepmind 1.0.0

package/plugin/skills/timeline-report/SKILL.md

@@ -0,0 +1,211 @@
+---
+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.
+---
+
+# Timeline Report
+
+Generate a comprehensive narrative analysis of a project's entire development history using claude-mem's persistent memory timeline.
+
+## When to Use
+
+Use when users ask for:
+
+- "Write a timeline report"
+- "Journey into [project]"
+- "Analyze my project history"
+- "Full project report"
+- "Summarize the entire development history"
+- "What's the story of this project?"
+
+## Prerequisites
+
+The claude-mem worker must be running. The project must have claude-mem observations recorded.
+
+**Resolve the worker port** (do this once at the start and reuse `$WORKER_PORT` in every curl call below):
+
+```bash
+WORKER_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)}"
+```
+
+This 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).
+
+## Workflow
+
+### Step 1: Determine the Project Name
+
+Ask 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.
+
+**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:
+
+```bash
+git_dir=$(git rev-parse --git-dir 2>/dev/null)
+git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
+if [ "$git_dir" != "$git_common_dir" ]; then
+  # We're in a worktree — resolve the parent project name
+  parent_project=$(basename "$(dirname "$git_common_dir")")
+  echo "Worktree detected. Parent project: $parent_project"
+else
+  parent_project=$(basename "$PWD")
+fi
+echo "$parent_project"
+```
+
+If 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."
+
+### Step 2: Fetch the Full Timeline
+
+Use Bash to fetch the complete timeline from the claude-mem worker API:
+
+```bash
+curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true"
+```
+
+This 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.
+
+**Token estimates:** The full timeline size depends on the project's history:
+- Small project (< 1,000 observations): ~20-50K tokens
+- Medium project (1,000-10,000 observations): ~50-300K tokens
+- Large project (10,000-35,000 observations): ~300-750K tokens
+
+If 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.
+
+### Step 3: Estimate Token Count
+
+Before proceeding, estimate the token count of the fetched timeline (roughly 1 token per 4 characters). Report this to the user:
+
+```
+Timeline fetched: ~X observations, estimated ~Yk tokens.
+This analysis will consume approximately Yk input tokens + ~5-10k output tokens.
+Proceed? (y/n)
+```
+
+Wait for user confirmation before continuing if the timeline exceeds 100K tokens.
+
+### Step 4: Analyze with a Subagent
+
+Deploy 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.
+
+**Agent prompt:**
+
+```
+You 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.
+
+You 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, source_tool, source_input_summary.
+
+Write a comprehensive narrative report titled "Journey Into [PROJECT_NAME]" that covers:
+
+## Required Sections
+
+1. **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?
+
+2. **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.
+
+3. **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.
+
+4. **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).
+
+5. **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).
+
+6. **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.
+
+7. **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?
+
+8. **Token Economics & Memory ROI** -- Quantitative analysis of how memory recall saved work:
+   - Query the database directly for these metrics using `sqlite3 ~/.claude-mem/claude-mem.db`
+   - Count total discovery_tokens across all observations (the original cost of all work)
+   - Count sessions that had context injection available (sessions after the first)
+   - Calculate the compression ratio: average discovery_tokens vs average read_tokens per observation
+   - Identify the highest-value observations (highest discovery_tokens -- these are the most expensive decisions, bugs, and discoveries that memory prevents re-doing)
+   - Identify explicit recall events (observations where source_tool contains "search", "smart_search", "get_observations", "timeline", or where narrative mentions "recalled", "from memory", "previous session")
+   - 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
+   - Estimate explicit recall savings: ~10K tokens per explicit recall query
+   - Calculate net ROI: total_savings / total_read_tokens_invested
+   - Present as a table with monthly breakdown
+   - 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)
+
+   Use these SQL queries as a starting point:
+   ```sql
+   -- Total discovery tokens
+   SELECT SUM(discovery_tokens) FROM observations WHERE project = 'PROJECT_NAME';
+
+   -- Sessions with context available (not the first session)
+   SELECT COUNT(DISTINCT memory_session_id) FROM observations WHERE project = 'PROJECT_NAME';
+
+   -- Average tokens per observation
+   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;
+
+   -- Top 5 most expensive observations (highest-value memories)
+   SELECT id, title, discovery_tokens FROM observations WHERE project = 'PROJECT_NAME' ORDER BY discovery_tokens DESC LIMIT 5;
+
+   -- Monthly breakdown
+   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;
+
+   -- Explicit recall events
+   SELECT COUNT(*) FROM observations WHERE project = 'PROJECT_NAME' AND (source_tool LIKE '%search%' OR source_tool LIKE '%timeline%' OR source_tool LIKE '%get_observations%' OR narrative LIKE '%recalled%' OR narrative LIKE '%from memory%' OR narrative LIKE '%previous session%');
+   ```
+
+9. **Timeline Statistics** -- Quantitative summary:
+   - Date range (first observation to last)
+   - Total observations and sessions
+   - Breakdown by observation type (features, bug fixes, discoveries, decisions, changes)
+   - Most active days/weeks
+   - Longest debugging sessions
+
+10. **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?
+
+## Writing Style
+
+- Write as a technical narrative, not a list of bullet points
+- Use specific observation IDs and timestamps when referencing events (e.g., "On Dec 14 (#26766), the root cause was finally identified...")
+- Connect events across time -- show how early decisions created later consequences
+- Be honest about struggles and dead ends, not just successes
+- Target 3,000-6,000 words depending on project size
+- Use markdown formatting with headers, emphasis, and code references where appropriate
+
+## Important
+
+- Analyze the ENTIRE timeline chronologically -- do not skip early history
+- Look for narrative arcs: problem -> investigation -> solution
+- Identify turning points where the project's direction fundamentally changed
+- Note any observations about the development process itself (tooling, workflow, collaboration patterns)
+
+Here is the complete project timeline:
+
+[TIMELINE CONTENT GOES HERE]
+```
+
+### Step 5: Save the Report
+
+Save the agent's output as a markdown file. Default location:
+
+```
+./journey-into-PROJECT_NAME.md
+```
+
+Or if the user specified a different output path, use that instead.
+
+### Step 6: Report Completion
+
+Tell the user:
+- Where the report was saved
+- The approximate token cost (input timeline + output report)
+- The date range covered
+- Number of observations analyzed
+
+## Error Handling
+
+- **Empty timeline:** "No observations found for project 'X'. Check the project name with: `curl -s \"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\"`"
+- **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`."
+- **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.
+
+## Example
+
+User: "Write a journey report for the tokyo project"
+
+1. Fetch: `curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=tokyo&full=true"`
+2. Estimate: "Timeline fetched: ~34,722 observations, estimated ~718K tokens. Proceed?"
+3. User confirms
+4. Deploy analysis agent with full timeline
+5. Save to `./journey-into-tokyo.md`
+6. Report: "Report saved. Analyzed 34,722 observations spanning Oct 2025 - Mar 2026 (~718K input tokens, ~8K output tokens)."

package/plugin/skills/version-bump/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: claude-code-plugin-release
+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 (so `npx claude-mem@X.Y.Z` resolves) is handed off to the human maintainer, who raised npm security.
+---
+
+# Version Bump & Release Workflow
+
+**IMPORTANT:** Plan and write detailed release notes before starting.
+
+**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.
+
+## Preparation
+
+1.  **Analyze**: Determine if the change is **PATCH** (bug fixes), **MINOR** (features), or **MAJOR** (breaking).
+2.  **Environment**: Identify repository owner/name from `git remote -v`.
+3.  **Paths — every file that carries the version string**:
+    - `package.json` — **the npm/npx-published version** (`npx claude-mem@X.Y.Z` resolves from this)
+    - `plugin/package.json` — bundled plugin runtime deps
+    - `.claude-plugin/marketplace.json` — version inside `plugins[0].version`
+    - `.claude-plugin/plugin.json` — top-level Claude-plugin manifest
+    - `plugin/.claude-plugin/plugin.json` — bundled Claude-plugin manifest
+    - `.codex-plugin/plugin.json` — Codex-plugin manifest
+    - `plugin/.codex-plugin/plugin.json` — bundled Codex-plugin manifest
+    - `openclaw/openclaw.plugin.json` — OpenClaw plugin manifest
+
+    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.
+
+## Workflow
+
+1.  **Update**: Increment the version string in every path above. Do NOT touch `CHANGELOG.md` — it's regenerated.
+2.  **Verify**: `git grep -n "\"version\": \"<NEW>\""` — confirm all eight files match. `git grep -n "\"version\": \"<OLD>\""` — should return zero hits.
+3.  **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.
+4.  **Commit**: `git add -A && git commit -m "chore: bump version to X.Y.Z"`.
+5.  **Tag**: `git tag -a vX.Y.Z -m "Version X.Y.Z"`.
+6.  **Push**: `git push origin main && git push origin vX.Y.Z`.
+7.  **Publish to npm — HAND OFF TO HUMAN.** The human maintainer raised npm
+    security, so publishing now requires credentials/2FA only they can provide.
+    The agent MUST NOT run `npm publish` (or `np` / `npm run release:*`, which
+    also publish) itself. **Hand off NPM publishing to the human now:** stop and
+    tell them the version is committed, tagged, and pushed, and that they must
+    publish to npm to make `npx claude-mem@X.Y.Z` resolve. Give them the command:
+    ```bash
+    npm publish   # run by the HUMAN — the prepublishOnly script rebuilds the package
+    ```
+    Wait for the human to confirm they published, then verify it landed:
+    ```bash
+    npm view claude-mem@X.Y.Z version   # should print X.Y.Z
+    ```
+    If the publish build touched local artifacts, run `npm run build-and-sync` again afterward.
+8.  **GitHub release**: `gh release create vX.Y.Z --title "vX.Y.Z" --notes "RELEASE_NOTES"`.
+9.  **Changelog**: Regenerate via the project's changelog script:
+    ```bash
+    npm run changelog:generate
+    ```
+    (Runs `node scripts/generate-changelog.js`, which pulls releases from the GitHub API and rewrites `CHANGELOG.md`.)
+10. **Sync changelog**: Commit and push the updated `CHANGELOG.md`.
+11. **Notify**: Run the Discord notification from `~/Scripts/claude-mem/`, where the `.env` with Discord webhook details lives:
+    ```bash
+    cd ~/Scripts/claude-mem/ && npm run discord:notify vX.Y.Z
+    ```
+    Do this even when the release worktree does not have a local `.env`.
+12. **Finalize**: `git status` — working tree must be clean.
+
+## Checklist
+
+- [ ] All eight config files have matching versions
+- [ ] `git grep` for old version returns zero hits
+- [ ] `npm run build-and-sync` succeeded
+- [ ] Git tag created and pushed
+- [ ] **NPM publishing handed off to the human** (agent does NOT run `npm publish` — human raised security); once they publish, `npm view claude-mem@X.Y.Z version` confirms it (so `npx claude-mem@X.Y.Z` resolves)
+- [ ] GitHub release created with notes
+- [ ] `CHANGELOG.md` updated and pushed
+- [ ] Discord notification run from `~/Scripts/claude-mem/`
+- [ ] `git status` shows clean tree

package/plugin/skills/version-bump/scripts/generate_changelog.js

@@ -0,0 +1,34 @@
+#!/usr/bin/env node
+const fs = require('fs');
+
+function generate() {
+  try {
+    const input = fs.readFileSync(0, 'utf8');
+    if (!input || input.trim() === '') {
+      process.stderr.write('No input received on stdin
+');
+      process.exit(1);
+    }
+
+    const releases = JSON.parse(input);
+    const lines = ['# Changelog', '', 'All notable changes to this project.', ''];
+    
+    releases.slice(0, 50).forEach(r => {
+      const date = r.published_at.split('T')[0];
+      lines.push(`## [${r.tag_name}] - ${date}`);
+      lines.push('');
+      if (r.body) lines.push(r.body.trim());
+      lines.push('');
+    });
+    
+    process.stdout.write(lines.join('
+') + '
+');
+  } catch (err) {
+    process.stderr.write(`Error generating changelog: ${err.message}
+`);
+    process.exit(1);
+  }
+}
+
+generate();

package/plugin/skills/weekly-digests/SKILL.md

@@ -0,0 +1,262 @@
+---
+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.
+---
+
+# Weekly Digests
+
+Produce 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.
+
+**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.
+
+## When to Use
+
+Trigger when the user asks for:
+
+- "Weekly digests"
+- "Week-by-week story"
+- "Serial timeline"
+- "Story chapters of [project]"
+- "Run a digest for each week"
+- "Continue the story week by week"
+
+If the user wants a single sweeping report, use `timeline-report` instead. This skill is for serial chapter format.
+
+## Prerequisites
+
+- claude-mem worker running
+- Project has at least one ISO week of observations (the pipeline degenerates gracefully — even N=1 works)
+- A clean output directory the user is comfortable writing into
+
+**Resolve the worker port** (do this once, reuse `$WORKER_PORT`):
+
+```bash
+WORKER_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)}"
+```
+
+## Workflow
+
+### Step 1: Determine the Project Name
+
+Same worktree-detection pattern as `timeline-report`. In a worktree, the data source is the **parent project**:
+
+```bash
+git_dir=$(git rev-parse --git-dir 2>/dev/null)
+git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
+if [ "$git_dir" != "$git_common_dir" ]; then
+  parent_project=$(basename "$(dirname "$git_common_dir")")
+else
+  parent_project=$(basename "$PWD")
+fi
+echo "$parent_project"
+```
+
+### Step 2: Fetch the Full Timeline and Save It
+
+```bash
+mkdir -p .scratch
+curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true" \
+  > .scratch/cm-timeline.md
+wc -l .scratch/cm-timeline.md
+```
+
+Sanity-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)`).
+
+### Step 3: Split the Timeline Into Per-ISO-Week Files
+
+Write a Python script to `.scratch/split-timeline.py` that:
+
+1. Parses date headers (`### Mon DD, YYYY`).
+2. Groups days into ISO weeks via `date.isocalendar()` (Monday-start).
+3. Emits one file per week to `docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md`, preserving each day's section verbatim.
+4. Runs a dual-pass sanity check: total observations distributed must equal the count in the source file.
+
+Output structure (filenames illustrative):
+
+```
+docs/timeline-weeks/
+  README.md                       # weekly index table
+  YYYY-W<NN>-MonDD-to-MonDD.md    # one per ISO week the timeline covers
+  ...
+```
+
+Each weekly file should preserve the original daily sections verbatim. Do not paraphrase at this stage — the digest agents need raw fidelity.
+
+**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.
+
+### Step 4: Build the Weekly Index README
+
+Write `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).
+
+### Step 5: Run the Consecutive Subagent Pipeline
+
+**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.
+
+Create the output directory:
+
+```bash
+mkdir -p docs/timeline-weeks/digests
+```
+
+For 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.
+
+#### Subagent Prompt Template
+
+```
+You 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"}.
+
+**Source file (read in full):**
+{ABSOLUTE_PATH_TO_WEEK_FILE}
+
+**Output digest file (write):**
+{ABSOLUTE_PATH_TO_DIGEST_FILE}
+
+**Format key for the source file:**
+- Numeric lines like `1 7:59p 🔵 Save hook file is empty` are observations (ID, time, type-emoji, title)
+- `S##` lines are session boundaries (the user prompt that started the session)
+- Emoji legend: 🎯session 🔴bugfix 🟣feature 🔄refactor ✅change 🔵discovery ⚖️decision 🚨security_alert 🔐security_note
+
+**Story so far (carry-forward from Week {N-1}):**
+
+{STORY_SO_FAR_BLOCK_OR_EMPTY_FOR_WEEK_1}
+
+**Your digest must include:**
+1. **Title line** — `# Week {N} ({WEEK_LABEL}): {DATE_RANGE} — [your chosen subtitle]`
+2. **One-line tagline** — what this week is about, in plain English
+3. **Narrative section** ({BUDGET}) — tell the story. Resolve threads from prior weeks where the data shows resolution. Introduce new arcs. Use specific observation details.
+4. **Threads continued / opened / resolved** sections
+5. **Cliffhanger / What's next**
+6. **Carry-forward block** at the very bottom, fenced as ```carry-forward ... ``` — structured handoff for the next week's agent.
+
+**CARRY-FORWARD DISCIPLINE:**
+- Cap at ~350 words.
+- AGGRESSIVELY PRUNE: drop arcs that didn't surface this week unless they're actively unresolved cliffhangers.
+- Drop cast members absent 2+ weeks unless load-bearing for the long arc.
+- Quality over completeness. The next agent inherits what you mention; mention judiciously.
+
+Required carry-forward sub-sections:
+- **Active arcs** — ongoing themes/projects the next agent should watch for
+- **Cast** — notable named systems/people/tools (continuing + new)
+- **Unresolved** — open questions or unfinished work
+- **Tone notes** — how the story is being told (voice, perspective, register evolution)
+
+**Tone rules:**
+- Third-person narrator, sharp, observational. Not twee.
+- AI is "Claude"; human is "{USER_FIRST_NAME}".
+- 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.
+- Don't manufacture drama. Name what's there.
+- Track the user's prompt-register evolution week by week (frustration markers, escalation language, shifts in tone).
+- 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).
+- Watch for new villains or co-stars and name them.
+- For trough/silent weeks: silence IS the story. Don't pad. Name what didn't happen.
+- For surge weeks (>2,000 obs): pick 4-7 spine arcs and tell them well. Don't catalog.
+
+**Important:** Do NOT speculate beyond what's in the source file.
+
+After writing the file, return:
+1. Path of the file you wrote
+2. The carry-forward block verbatim
+3. One-sentence summary of the week
+```
+
+#### Narrative Budget by Observation Count
+
+Scale narrative length proportionally to the week's volume:
+
+| Obs count | Narrative section budget |
+| --- | --- |
+| < 100 | 200–400 words |
+| 100–500 | 300–600 words |
+| 500–1,500 | 500–900 words |
+| 1,500–3,000 | 700–1,100 words |
+| 3,000+ | 800–1,300 words |
+
+Pad these into the `{BUDGET}` slot of the prompt for each week.
+
+#### The First Week
+
+For 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.
+
+#### The Final Week
+
+The 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.
+
+#### When N = 1 (single-week project)
+
+Apply 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.
+
+### Step 6: Rename Files for Sortable Order
+
+The 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:
+
+```bash
+cd docs/timeline-weeks/digests
+total=$(ls *.md | wc -l | tr -d ' ')
+width=${#total}                  # 1 for N<10, 2 for N<100, 3 for N<1000
+[ "$width" -lt 2 ] && width=2    # always pad to at least 2 for readability
+i=0
+for f in *.md; do
+  printf -v prefix "%0${width}d" $i
+  mv "$f" "${prefix}-$f"
+  i=$((i+1))
+done
+```
+
+Result 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.
+
+Do 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`.
+
+### Step 7: Report Completion
+
+Tell the user:
+- Total weeks digested (N)
+- Output directory path
+- Date range covered
+- Any silent/trough weeks worth flagging
+- 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.
+
+## Pipeline Discipline
+
+These rules emerged from running the pipeline end-to-end. Encode them every time:
+
+1. **Sequential, not parallel.** The whole point is the carry-forward chain. Parallelism breaks it.
+2. **Carry-forward is bounded.** It will bloat without active pruning. Tell every agent: cap ~350 words, drop dormant arcs, drop absent cast.
+3. **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.
+4. **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.
+5. **Honor silence.** Trough weeks (10–100 obs) are real chapters. Name what didn't happen. Don't pad.
+6. **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.
+7. **Final week: no false ending.** The digest stops; the project doesn't. Write `## Where We Are`, not "the end."
+
+## Error Handling
+
+- **Empty timeline**: project name wrong, or worker not running. `curl -s "http://localhost:${WORKER_PORT}/api/search?query=*&limit=1"` to verify.
+- **Worker not running**: start it via your usual method or check `ps aux | grep worker-service`.
+- **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."
+- **One agent fails mid-pipeline**: retry that week with the same carry-forward. Don't skip — the chain breaks.
+- **Carry-forward growing past ~500 words**: tighten the discipline instruction in subsequent prompts. Force pruning explicitly.
+
+## Examples
+
+### Long-running project (~30 weeks)
+
+User: "Make weekly digests for [project] from beginning to end"
+
+1. Resolve worker port, detect project name.
+2. Fetch full timeline → `.scratch/cm-timeline.md`.
+3. Run `.scratch/split-timeline.py` → N weekly files in `docs/timeline-weeks/` (e.g. 30).
+4. Generate `docs/timeline-weeks/README.md` index.
+5. 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.
+6. Rename digests with zero-padded order prefix (`00-...md` through `29-...md`).
+7. Report total chapters, date range, any troughs/peaks, and the one-line capstone the final agent produced.
+
+### Short-lived project (~3 weeks)
+
+Same flow, just smaller. N=3, so:
+- Chapter 1: empty carry-forward, establish cast/tone/arcs.
+- Chapter 2: receives chapter 1's carry-forward, builds on it.
+- Chapter 3: receives chapter 2's carry-forward, BUT gets the final-chapter treatment (`## Where We Are` instead of carry-forward block).
+- Filenames: `00-...md`, `01-...md`, `02-...md`.
+
+### Single-week project (N=1)
+
+Apply both first-and-final-chapter treatment to the only chapter: empty carry-forward, `## Where We Are` close, no inter-chapter references. Filename: `00-...md`.

package/plugin/skills/what-the/SKILL.md

@@ -0,0 +1,6 @@
+---
+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."
+---
+
+that sounds mad technical. explain to me the who, what, where, why, and when of this