novahiz 0.1.0

package/bundled-skills/video/references/ai-video-prompting.md

@@ -0,0 +1,175 @@
+# AI Video Prompting Guide
+
+How to write effective prompts for AI video generation models (Veo, Runway, Kling, Pika).
+
+---
+
+## Prompt Structure
+
+A strong video prompt follows this formula:
+
+```
+[Subject] + [Action] + [Camera movement] + [Visual style] + [Lighting/mood] + [Technical specs]
+```
+
+### Example Prompts by Use Case
+
+**Product hero shot:**
+```
+A sleek laptop on a minimal white desk, screen glowing with a dashboard UI,
+camera slowly orbits 180 degrees around the desk,
+soft volumetric lighting from the left, shallow depth of field,
+cinematic commercial aesthetic, 4K
+```
+
+**Lifestyle B-roll:**
+```
+A woman in a modern co-working space smiling while looking at her phone,
+natural window light, candid documentary feel,
+camera handheld with subtle movement, warm color grading
+```
+
+**Abstract/brand:**
+```
+Flowing liquid gold particles forming the shape of a network graph,
+dark background, particles catch light as they move,
+slow-motion macro photography style, dramatic rim lighting
+```
+
+**SaaS explainer scene:**
+```
+An overhead shot of a team around a conference table pointing at charts,
+camera slowly pushes in, bright modern office,
+clean corporate style, even lighting, 1080p
+```
+
+---
+
+## Camera Movement Vocabulary
+
+Use these terms — video models understand them:
+
+| Term | Effect |
+|------|--------|
+| **Static** | Locked camera, no movement |
+| **Pan left/right** | Camera rotates horizontally |
+| **Tilt up/down** | Camera rotates vertically |
+| **Dolly in/out** | Camera moves toward/away from subject |
+| **Orbit** | Camera circles around subject |
+| **Tracking shot** | Camera follows moving subject |
+| **Crane/aerial** | Camera rises or descends |
+| **Handheld** | Subtle shake, documentary feel |
+| **Zoom** | Lens zoom (different from dolly) |
+| **Slow push** | Gradual dolly in — builds tension/focus |
+
+---
+
+## Style Keywords
+
+### Cinematic
+- "cinematic color grading"
+- "anamorphic lens flare"
+- "shallow depth of field"
+- "film grain"
+- "35mm film"
+
+### Commercial/Corporate
+- "clean commercial lighting"
+- "bright and airy"
+- "professional corporate aesthetic"
+- "even, diffused lighting"
+
+### Documentary
+- "handheld documentary style"
+- "natural lighting"
+- "candid, unposed"
+- "observational camera"
+
+### Social/Trendy
+- "vertical 9:16"
+- "fast-paced cuts"
+- "bold text overlays"
+- "high contrast, saturated colors"
+
+---
+
+## Model-Specific Tips
+
+### Veo (Google)
+
+- Excels at photorealism and complex scenes
+- Supports audio generation synced to video
+- Best with detailed, descriptive prompts
+- Specify "high resolution" or "1080p" for best quality
+- Can handle multiple subjects and scene transitions
+
+### Runway Gen-4
+
+- Strong motion control — specify camera movements precisely
+- Best temporal consistency (subjects stay consistent across frames)
+- Use motion brush for specific area animation
+- Image-to-video works well — provide a reference frame
+- Keep prompts under 100 words for best results
+
+### Kling
+
+- Can generate up to 2 minutes (much longer than others)
+- Good for longer narrative sequences
+- More affordable for bulk generation
+- Quality drops slightly at longer durations
+- Best with simpler scenes and fewer subjects
+
+### Pika
+
+- Fastest generation time (under 2 minutes)
+- Good for quick iterations and experimentation
+- Effects mode adds motion to still images
+- Best for short clips (5-15 seconds)
+- Less control over camera movement
+
+---
+
+## Common Prompt Mistakes
+
+| Mistake | Why It Fails | Fix |
+|---------|-------------|-----|
+| "A person using our app" | Too vague, no visual detail | Describe the person, setting, lighting, camera |
+| Including text/logos | AI can't render readable text | Add text in post via Hyperframes/CapCut |
+| "Make it viral" | Not a visual instruction | Describe the visual style you want |
+| Extremely long prompts (200+ words) | Models lose focus | Keep to 50-100 words, be specific |
+| No camera direction | Random/static camera | Always specify movement or "static" |
+| "Realistic" alone | Not specific enough | "Photorealistic, natural lighting, shot on RED camera" |
+
+---
+
+## Prompting Workflow
+
+1. **Reference first** — find a real video that looks like what you want
+2. **Describe it** — break down: subject, action, camera, style, mood
+3. **Generate 3-4 variations** — same concept, different angles or styles
+4. **Iterate on the best** — refine the prompt based on results
+5. **Composite** — combine AI footage with programmatic text/overlays
+
+---
+
+## Aspect Ratios
+
+Always specify in your prompt or generation settings:
+
+| Platform | Ratio | Resolution |
+|----------|-------|-----------|
+| YouTube | 16:9 | 1920x1080 or 3840x2160 |
+| TikTok/Reels/Shorts | 9:16 | 1080x1920 |
+| Instagram Feed | 1:1 or 4:5 | 1080x1080 or 1080x1350 |
+| Website hero | 16:9 | 1920x1080 |
+| LinkedIn | 16:9 or 1:1 | 1920x1080 |
+
+---
+
+## Cost Optimization
+
+- **Iterate at low resolution** — upscale only the final version
+- **Use Kling for drafts** — cheapest per second, switch to Veo/Runway for finals
+- **Image-to-video** — providing a reference frame saves generation credits and gives better results
+- **Batch similar prompts** — models often offer volume discounts
+- **Cache and reuse** — B-roll clips can be reused across multiple videos

package/bundled-skills/video/references/edit-anatomy.md

@@ -0,0 +1,84 @@
+# Reverse-Engineering an Edit (The Beat Sheet)
+
+A viral short-form video usually isn't winning on the footage — it's winning on the *edit*: the cut rhythm, the caption style, the punch-ins, the on-screen text landing on the exact word, the b-roll cutaways, the sound design. This reference turns a reference edit you admire into a **reusable edit spec** — a beat sheet you (or an editing tool) can execute against your own footage — without copying a single frame of theirs.
+
+This is the tool-agnostic half of "copy any viral edit": the *decomposition*. The generation is whatever you edit with afterward — CapCut, Premiere, Remotion/Hyperframes, or an AI restyle tool. The spec is the deliverable.
+
+## When to use it
+
+- A competitor's or creator's edit keeps stopping your scroll and you want to understand *why* and replicate the technique
+- You have raw footage (a talking-head clip, a demo) and a reference edit whose style you want to match
+- You're briefing an editor or a template and need the edit decisions written down, not vibes
+
+Don't use it to copy someone's actual creative — this extracts the *editing grammar* (structure, rhythm, caption treatment), not the script, footage, or brand. Same rule as mining organic content for vocabulary in the hook system: take the technique, never the creative.
+
+## Step 1 — Pull the reference so you can actually read the edit
+
+You cannot decompose an edit from a description of it. Get the frames and the timing:
+
+- **watch-video** (visual or multimodal mode) — extracts the transcript *and* samples frames at the cut points, so you can read on-screen text, caption style, and shot changes. This is the primary tool.
+- **social-fetch** — pull the post for the caption, engagement, and the media URL when the reference is a specific tweet/Reel/TikTok.
+- Screenshots of key frames also work if the user supplies them — you need the visual, not just the words.
+
+Note the total duration and roughly how many cuts there are before you start — cuts-per-second is the single most telling number about an edit's energy.
+
+## Step 2 — Extract the anatomy, beat by beat
+
+Walk the reference from 0:00 and log every editing decision. The dimensions that define a short-form edit:
+
+| Dimension | What to read off the reference |
+|---|---|
+| **Shot & framing** | Talking head / screen recording / b-roll / text card; close-up vs. wide; headroom, rule-of-thirds, or dead-center |
+| **Cut rhythm** | Where each cut lands and how fast (cuts-per-second); is it on the beat, on the word, or on the breath? |
+| **On-screen text** | The words, when each appears/disappears, and *where* on the frame (top-third caption vs. big centered statement) |
+| **Caption style** | Font, weight, color, outline/box, and animation (word-by-word pop, karaoke highlight, whole-line) |
+| **Motion** | Punch-ins / zoom pushes, shakes, whip-transitions, speed ramps — where and how aggressive |
+| **B-roll & overlays** | Cutaways, stickers, arrows, emoji, screenshots, meme inserts — what's laid over the base footage and when |
+| **Sound design** | Music choice and where it hits, SFX (whooshes, dings, risers), and deliberate silence before a beat |
+| **Hook (first 2s)** | The single most-copied element — what's on screen and said in the opening two seconds, before anyone's committed |
+| **Pacing curve** | Does it stay frantic, or fast-hook → slower-body → fast-CTA? Map the energy over the runtime |
+
+Read the *pattern*, not just the instances: "a hard cut + punch-in on every new sentence," "caption is one word at a time, yellow, karaoke-highlighted, bottom third," "a whoosh SFX on every scene change." Patterns are what make an edit replicable; a list of 40 individual cuts is not.
+
+## Step 3 — Write the beat sheet
+
+Two artifacts: a per-beat table and a short style summary.
+
+**The beat sheet** — one row per beat (a beat = a cut or a distinct edit event):
+
+```
+| Beat | Time      | Shot            | On-screen text        | Caption style        | Transition / motion   | Audio            |
+|------|-----------|-----------------|-----------------------|----------------------|-----------------------|------------------|
+| 1    | 0:00–0:02 | CU talking head | "STOP doing this"     | word-pop, yellow, ctr| hard in, slow push    | music in + riser |
+| 2    | 0:02–0:04 | screen record   | (caption only)        | karaoke, white, btm  | hard cut + whoosh     | click SFX        |
+| …    |           |                 |                       |                      |                       |                  |
+```
+
+**The style summary** — the 3–5 *signature moves* that make this edit recognizable, stated so they're reusable:
+- e.g. "Every sentence gets a hard cut + a 5% punch-in." / "Captions are one word at a time, bottom-third, karaoke-highlighted." / "A whoosh SFX on every cut; music drops out for 0.5s before the CTA." / "The hook is a bold centered statement on frame 1, no logo."
+
+The signature moves are the real deliverable — someone can apply those five rules to any footage and get the style. The table is the detailed backup.
+
+## Step 4 — Review once, then execute
+
+Show the beat sheet before anyone edits anything — the same review-once gate as the ad-creative creative review page. The reviewer checks two things:
+
+- **The on-screen text says what you want** (mapped to your message, not the reference's)
+- **The scene changes land where you want them** (your footage's beats, not a blind copy of the reference's timing)
+
+Approve, then execute the spec with your footage:
+- **Remotion / Hyperframes** — when you want the edit templated and data-driven (see the programmatic-video section in SKILL.md); the beat sheet *is* the composition spec.
+- **CapCut / Premiere / an editor** — hand off the beat sheet + style summary as the brief.
+- **An AI restyle tool** — feed the style summary as the target style.
+
+## Originality guardrail
+
+You are copying the *edit*, not the content. The beat sheet describes technique (cut rhythm, caption treatment, motion, sound design) applied to **your** footage and **your** message. General editing techniques and style cues are usually reusable — U.S. copyright protects expression, not procedures or methods (17 U.S.C. §102(b)) — but the reference's specific creative expression is not, and closely reproducing a finished video's exact selection and arrangement of choices can still create risk. So copy the grammar, not the finished work: use your own footage, message, script, voiceover, licensed music/SFX/samples, and brand elements. If the reference's "style" is really a specific bit or sketch, that's their creative — draw inspiration, don't reproduce it.
+
+## Common mistakes
+
+- **Describing instead of reading** — you can't extract caption style or cut timing from the transcript alone; pull the frames (watch-video).
+- **Logging instances, not patterns** — 40 cut timestamps isn't a spec; "hard cut + punch-in per sentence" is.
+- **Copying the reference's timing onto different footage** — beats land on *your* words and *your* cuts; the reference gives you the grammar, not the calendar.
+- **Skipping the hook** — the first 2 seconds carry most of the retention; decode them in the most detail.
+- **Reproducing the creative** — matching the edit is fine; re-shooting their exact bit, script, or using their footage/music/SFX is not.

package/bundled-skills/wiki-agent/SKILL.md

@@ -0,0 +1,322 @@
+---
+name: wiki-agent
+description: >
+  Query-driven targeted ingest from a specific AI agent's raw history. Use this skill when the user
+  invokes /wiki-claude, /wiki-codex, /wiki-hermes, /wiki-openclaw, /wiki-copilot, /wiki-pi — with or without a
+  search topic. Different from wiki-history-ingest (which bulk-ingests everything new): this skill finds
+  sessions about a SPECIFIC TOPIC in a specific agent's history and ingests just those, then returns a
+  synthesized answer immediately usable in the current session. Primary use case: you're working in
+  agent A and want to pull in how you solved X in agent B's history. Cross-referencing, not archiving.
+  Also trigger on: "what did I work on in codex about X", "search my claude sessions for Y",
+  "pull in hermes knowledge about Z", "find that conversation where I did X in codex".
+---
+
+# Wiki Agent — Targeted Cross-Agent History Search + Ingest
+
+You are doing a **query-driven targeted ingest** from one specific AI agent's raw conversation history. The user is typically working in a *different* agent right now and wants to pull in context from another agent's past sessions.
+
+This is not bulk ingest. You find sessions about a specific topic, extract the relevant blobs, distill them into the wiki, and return a synthesized answer the user can act on immediately.
+
+## Command Routing
+
+Parse the invocation to determine the target agent and optional query:
+
+| Command | Target | Example |
+|---|---|---|
+| `/wiki-claude [query]` | Claude Code history | `/wiki-claude "how did I set up auth middleware"` |
+| `/wiki-codex [query]` | Codex CLI history | `/wiki-codex "rust ownership patterns"` |
+| `/wiki-hermes [query]` | Hermes agent history | `/wiki-hermes "memory architecture"` |
+| `/wiki-openclaw [query]` | OpenClaw history | `/wiki-openclaw "project planning approach"` |
+| `/wiki-copilot [query]` | Copilot chat history | `/wiki-copilot "test strategy for API routes"` |
+| `/wiki-pi [query]` | Pi agent history | `/wiki-pi "how did I refactor the auth module"` |
+
+If no query is given, default to **recent sessions mode**: ingest the last 5 unprocessed sessions from that agent and return a summary of what was found. This is equivalent to a focused `wiki-history-ingest` for that agent only.
+
+## Before You Start
+
+**Writing profile:** Before drafting or rewriting natural-language Markdown, read and apply the `Writing Profile Resolution` section in `llm-wiki/SKILL.md`. Framework schema, provenance, safety, and operation-specific requirements take precedence.
+`WRITING.md` preferences apply only to newly drafted or rewritten natural-language Markdown; preserve source content and structured records.
+
+1. **Resolve config** — follow the Config Resolution Protocol in `llm-wiki/SKILL.md` (inline `@name` override → walk up CWD for `.env` → global config → prompt setup). This gives `OBSIDIAN_VAULT_PATH`.
+2. Read `$OBSIDIAN_VAULT_PATH/.manifest.json` → know what's already ingested.
+3. Read `$OBSIDIAN_VAULT_PATH/hot.md` if it exists → warm context on recent wiki activity.
+
+---
+
+## Step 1: Locate the Agent's History Root
+
+| Agent | Default path | Config override |
+|---|---|---|
+| `claude` | `~/.claude` + `~/Library/Application Support/Claude/local-agent-mode-sessions/` | `CLAUDE_HISTORY_PATH` in `.env` |
+| `codex` | `~/.codex` | `CODEX_HISTORY_PATH` in `.env` |
+| `hermes` | `~/.hermes` | `HERMES_HOME` in env or `.env` |
+| `openclaw` | `~/.openclaw` | `OPENCLAW_HOME` in `.env` |
+| `copilot` | `~/.copilot` | `COPILOT_HISTORY_PATH` in `.env` |
+| `pi` | `~/.pi/agent/sessions` | `PI_HISTORY_PATH` in `.env` |
+
+If the history root doesn't exist, stop and tell the user: "No `<agent>` history found at `<path>`. Have you run `<agent>` on this machine? You can set a custom path with `<CONFIG_VAR>` in `.env`."
+
+---
+
+## Step 2: Build Session Inventory
+
+Use the **cheapest index source** for each agent — don't open session files until you know which ones are relevant.
+
+### Claude
+```
+Primary index:   ~/.claude/projects/  (directories = projects, files = sessions)
+Session files:   ~/.claude/projects/*/*.jsonl
+Desktop index:   find ~/Library/Application Support/Claude/local-agent-mode-sessions -name "local_*.json"
+Signal fields:   sessionId, cwd, startedAt, title (in local_*.json)
+```
+Build a list of sessions: `{path, project_dir, modified_at, already_ingested}`.
+
+### Codex
+```
+Primary index:   ~/.codex/session_index.jsonl
+Session files:   ~/.codex/sessions/**/rollout-*.jsonl
+Signal fields:   thread_id, name/title, updated_at (in session_index.jsonl)
+```
+Read `session_index.jsonl` as the inventory. Each line: `{thread_id, name, updated_at}`. Map thread IDs to rollout files by matching directory names.
+
+### Hermes
+```
+Primary index:   ~/.hermes/memories/*.md  (fast to scan)
+Session files:   ~/.hermes/sessions/**/*.jsonl
+Signal fields:   file names, memory titles, first 3 lines of each memory
+```
+Scan memory filenames first (they're often titled by topic). Fall back to session listing.
+
+### OpenClaw
+```
+Primary index:   ~/.openclaw/workspace/memory/MEMORY.md  (structured long-term memory)
+Daily notes:     ~/.openclaw/workspace/memory/YYYY-MM-DD.md
+Session index:   ~/.openclaw/agents/*/sessions/sessions.json
+Session files:   ~/.openclaw/agents/*/sessions/*.jsonl
+```
+Read `MEMORY.md` sections first — it's the pre-compiled summary of everything. Daily notes give recency signal.
+
+### Copilot
+```
+Primary index:   session filenames / directory listing
+Session files:   varies by client (VS Code: ~/.copilot/sessions/*.jsonl or similar)
+Signal fields:   session timestamps, file names
+```
+
+### Pi
+```
+Primary index:   ~/.pi/agent/sessions/--<cwd>--/ directories
+Session files:   ~/.pi/agent/sessions/--<cwd>--/<timestamp>_<uuid>.jsonl
+Signal fields:   cwd (decoded from dir name), session_info.name, timestamp in filename
+```
+Scan session directories first. Decode `--<cwd>--` to get the working directory. Read the first line (session header) and any `session_info` entries for the session name. No separate index file — the filesystem is the index.
+
+---
+
+## Step 3: Score Sessions Against the Query
+
+If a query was given, score each session in the inventory without opening full session files:
+
+1. **Name/title match** — does the session name or thread title contain the query terms? Score: +3
+2. **CWD/project match** — does the working directory suggest the right project? Score: +2
+3. **Recency** — apply exponential time decay with a 90-day half-life, as a multiplier on the match score rather than a bonus added to it:
+
+   ```
+   base  = name_match(3) + cwd_match(2)
+   score = base * (0.35 + 0.65 * 0.5 ** (age_days / 90))
+   ```
+
+   The 0.35 floor is deliberate: an old session that matches the query exactly must still outrank a recent one that barely matches, or the skill can never answer "how did I first solve this?". This is the same decay `session-brain` uses, so the two skills rank consistently.
+4. **Already ingested** — if this session was previously ingested and the wiki page already covers the query (check `hot.md` + `index.md`), flag as "covered" but still show in results
+
+Select the **top 3–5 sessions** by score. If no query was given, select the 5 most recent unprocessed sessions.
+
+---
+
+## Step 4: Extract the Relevant Blob
+
+Open each selected session file and extract only the content relevant to the query. **Do not read the full session if it's large — use targeted extraction.**
+
+### Per-Agent Extraction Strategy
+
+**Claude** (JSONL conversation):
+- Each line: `{role, content, timestamp, ...}`
+- Search with: `rg -i "<query terms>" <session.jsonl>` to find the relevant lines
+- Extract: the surrounding conversation window (10 lines before + 20 lines after each hit)
+- Special signal: tool calls (Read/Write/Bash/Edit) reveal what was actually done — extract these even without keyword matches if they're in the relevant window
+
+**Codex** (rollout JSONL):
+- Each line: `{type: "session_meta|turn_context|event_msg|response_item", ...}`
+- Filter to `type: "event_msg"` (user turns) and `type: "response_item"` (model output)
+- Search with: `rg -i "<query terms>" <rollout.jsonl>`
+- Extract: matching turns + their parent context (the `turn_context` preceding the match)
+- Skip: `session_meta` events (operational metadata, not knowledge)
+
+**Hermes** (memory files + session JSONL):
+- For memory files: read the full file (they're short — typically <500 words each)
+- For session JSONL: `rg -i "<query terms>"` + surrounding window
+- Memory files with title matches → read fully; others → grep only
+
+**OpenClaw** (MEMORY.md + daily notes + session JSONL):
+- `MEMORY.md`: grep for section headers containing query terms → extract that section
+- Daily notes: grep most recent 30 days for query terms → extract matching paragraphs
+- Session JSONL: same grep-window approach as Claude
+- Prefer MEMORY.md/daily notes over session JSONL (they're pre-synthesized)
+
+**Copilot** (session JSONL):
+- Same grep-window approach as Claude
+- Look for checkpoint files if available (pre-summarized)
+
+**Pi** (structured JSONL with tree layout):
+- Each line is a tree entry: `{type, id, parentId, timestamp, message?, ...}`
+- Build the active branch: map entries by `id`, find leaf (last entry with no children), walk `parentId` to root
+- Search with: `rg -i "<query terms>" <session.jsonl>` to find matching entries
+- Extract: the matching entries + their ancestors on the active branch (follow parent chain)
+- Special signal: `toolCall` blocks inside assistant messages reveal what was actually done — extract these even without keyword matches if they're in the relevant window
+- Prefer `compaction` and `branch_summary` entries when available — they're pre-synthesized summaries
+- Skip `thinking` content blocks (noise) and `model_change` / `thinking_level_change` entries
+
+---
+
+## Step 5: Distill Blobs into Wiki Pages
+
+For each extracted blob, determine where it belongs in the wiki:
+
+1. **Check if a wiki page already covers this** — grep `index.md` and page frontmatter for the topic. If yes, update the existing page rather than creating a new one.
+2. **Determine category** using standard rules (from `llm-wiki/SKILL.md`):
+   - Technique / how-to → `skills/`
+   - Abstract concept / pattern → `concepts/`
+   - Tool / library / person → `entities/`
+   - Cross-cutting insight → `synthesis/`
+3. **Write or update the page** with required frontmatter:
+   ```yaml
+   ---
+   title: <topic>
+   category: skill|concept|entity|synthesis
+   tags: [tag1, tag2]
+   sources: [<agent>://<path/to/session>]
+   created: <date>
+   updated: <date>
+   confidence: high|medium|low
+   lifecycle: stable|draft
+   ---
+   ```
+   Set `sources` with the agent prefix so `memory-bridge` can find it later.
+4. **Add cross-links** to related wiki pages found in `index.md`.
+
+Distillation rules (same as all ingest skills):
+- Extract durable knowledge, not operational telemetry
+- One wiki page per concept, not one per session
+- Merge into existing pages rather than duplicating
+- Keep the signal: decisions made, patterns discovered, techniques that worked, bugs explained
+
+---
+
+## Step 6: Return Synthesized Answer
+
+After ingesting, immediately synthesize and return an answer from the newly ingested + existing wiki content:
+
+```
+## From <agent> history: "<query>"
+
+**Found in:** <N> sessions (<session names/titles>)
+
+**Key insights:**
+<Synthesized answer — 3–5 bullet points of the most useful knowledge>
+
+**Wiki pages updated/created:**
+- [[page-name]] — <what was added>
+- [[page-name]] — <what was added>
+
+**Sessions ingested:**
+| Session | Date | Relevance |
+|---------|------|-----------|
+| <name>  | <date> | <one-line why it was selected> |
+
+**Gaps:** <What the sessions didn't cover that might be relevant>
+```
+
+If a query was given but no relevant sessions were found, say so explicitly: "No sessions about '<query>' found in `<agent>` history. The most recent sessions covered: <list topics from last 3 sessions>."
+
+---
+
+## Step 7: Update Tracking Files
+
+Update `.manifest.json` for each session file processed:
+```json
+{
+  "<path>": {
+    "ingested_at": "<now>",
+    "source_type": "<agent>_conversation",
+    "modified_at": "<file mtime>",
+    "pages_created": [...],
+    "pages_updated": [...]
+  }
+}
+```
+
+Append to `log.md`:
+```
+- [TIMESTAMP] WIKI-AGENT agent=<agent> query="<query>" sessions_searched=N sessions_ingested=M pages_created=X pages_updated=Y
+```
+
+Update `hot.md` with a one-line summary of what was ingested.
+
+---
+
+## Cross-Agent Use Patterns
+
+These are the primary use cases this skill is designed for:
+
+**"I'm on Codex. What did I figure out about X in Claude?"**
+→ `/wiki-claude "X"` — finds Claude sessions about X, ingests them, returns the answer
+
+**"I solved a bug in Hermes last week. I need that context now in Claude Code."**
+→ `/wiki-hermes "bug description"` — surfaces and ingests the Hermes session
+
+**"What are all the approaches I've tried for X across all my tools?"**
+→ Run `/wiki-claude "X"`, `/wiki-codex "X"`, `/wiki-hermes "X"` in sequence — each ingests its slice, the wiki accumulates the cross-agent picture, then `/memory-bridge diff` shows what each tool uniquely contributed
+
+**No query — just "catch me up on recent Codex work"**
+→ `/wiki-codex` — ingests last 5 Codex sessions and returns a summary
+
+**"I'm on Claude Code. What did I figure out about X in Pi?"**
+→ `/wiki-pi "X"` — finds Pi sessions about X, ingests them, returns the answer
+
+**No query — just "catch me up on recent Pi work"**
+→ `/wiki-pi` — ingests last 5 Pi sessions and returns a summary
+
+## QMD Refresh After Vault Writes
+
+QMD is a search index, not the source of truth. If `$QMD_WIKI_COLLECTION` is empty or unset, skip this step. Run it only after this skill has written or rewritten vault markdown. If QMD refresh fails, do not roll back the vault changes; report the QMD status separately.
+
+Use `$QMD_CLI` if set; otherwise use `qmd`.
+
+```bash
+${QMD_CLI:-qmd} update
+```
+
+If the output says vectors are needed or embeddings may be stale, run:
+
+```bash
+${QMD_CLI:-qmd} embed
+```
+
+Verify the collection with either:
+
+```bash
+${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"
+```
+
+or, when a specific page path is known:
+
+```bash
+${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5
+```
+
+Record one of:
+- `QMD refreshed: update + embed + verified`
+- `QMD refreshed: update only + verified`
+- `QMD skipped: QMD_WIKI_COLLECTION unset`
+- `QMD skipped: qmd CLI unavailable`
+- `QMD failed: <short error summary>`