novahiz 0.1.0

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

@@ -0,0 +1,320 @@
+---
+name: wiki-dedup
+description: >
+  Scan the Obsidian wiki for page-level identity collisions — different pages covering the same
+  concept under different names (e.g. "RSC" vs "React Server Components") — and merge them.
+  Use this skill when the user says "dedup my wiki", "find duplicate pages", "merge duplicates",
+  "identity resolution", "consolidate my wiki", "I have duplicate pages", or "my wiki has two pages
+  for the same thing". Distinct from wiki-lint (which checks structure) and cross-linker (which adds
+  links) — this skill makes destructive page-level merges and requires careful confirmation.
+---
+
+# Wiki Dedup — Identity Resolution and Page-Level Deduplication
+
+You are finding and merging wiki pages that cover the same concept under different names. This is a write-heavy, potentially destructive skill — page merges cannot be automatically undone. Work carefully and confirm before acting in merge mode.
+
+**Follow the Retrieval Primitives table in `llm-wiki/SKILL.md`.** The candidate-detection pass uses only frontmatter and titles (cheap). Only open full page bodies for confirmed candidate pairs.
+
+## 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` and `OBSIDIAN_LINK_FORMAT`.
+2. Read `index.md` to get the full page inventory with one-line descriptions and tags.
+3. Read `log.md` briefly — if a dedup run just happened, note what was already merged.
+
+## Modes
+
+| Mode | Flag | Behavior |
+|---|---|---|
+| **Audit** | *(default)* | Report candidates only — no writes |
+| **Merge** | `--merge` | Show each confirmed pair, ask for confirmation before merging |
+| **Auto-merge** | `--auto` | Merge all high-confidence pairs (`score ≥ 0.90`) non-interactively |
+
+If the user doesn't specify, run in **Audit** mode and present findings before asking whether to proceed.
+
+## Step 1: Build the Page Registry
+
+Glob all `.md` files in the vault (excluding `_archives/`, `_raw/`, `.obsidian/`, `index.md`, `log.md`, `hot.md`, `_insights.md`, and any file that contains `redirects_to:` in its frontmatter — those are already merged redirect stubs).
+
+For each remaining page, extract from frontmatter:
+- `node_id` — relative path from vault root, without `.md`
+- `title` — frontmatter `title` field
+- `aliases` — frontmatter `aliases` list (may be absent)
+- `tags` — frontmatter `tags` list
+- `category` — directory prefix
+
+Build a lookup table: `node_id → {title, aliases, tags, category, summary}`.
+
+## Step 2: Detect Candidate Pairs
+
+For every pair of pages in the registry, compute a **similarity score** using these signals:
+
+### 2a. Title similarity signals
+
+| Signal | How to assess | Max contribution |
+|---|---|---|
+| **Token overlap** | Jaccard similarity of lowercased title word-tokens (split on spaces, hyphens, underscores, punctuation) | 0.65 |
+| **Edit distance** | Normalized edit distance on lowercased titles: `1 - (edits / max(len_a, len_b))` | 0.40 |
+| **Substring containment** | One title is a substring of the other (e.g. "RSC" ⊂ "React Server Components") | 0.50 |
+| **Alias cross-match** | Page A's title appears in page B's `aliases`, or vice versa | 0.65 |
+
+Composite title score = `min(max(token_overlap, edit_distance, substring), 0.65) + alias_cross_bonus`.
+
+You don't need exact arithmetic — make a confident judgement about degree of similarity.
+
+**Title extraction note:** Some pages use YAML block scalars (`title: >-` or `title: |`). When the `title:` value is `>-`, `>`, `|`, or `|-`, the actual title is on the next indented line — read it from there. Never compare the literal string `>-` as a title.
+
+### 2b. Semantic signals (cheap pass)
+
+| Signal | Points |
+|---|---|
+| Same `category` directory | +0.10 |
+| Tag overlap ≥ 3 shared tags | +0.15 |
+| Tag overlap ≥ 2 shared tags | +0.05 |
+| Same first tag (dominant tag) | +0.05 |
+
+### 2c. Threshold
+
+Flag pairs with composite score ≥ **0.75** as **candidates**. Pairs scoring 0.90+ are **high-confidence**.
+
+Score ranges → confidence labels:
+
+| Score | Label |
+|---|---|
+| ≥ 0.90 | HIGH — almost certainly the same concept |
+| 0.75–0.89 | MEDIUM — likely the same, verify |
+| 0.60–0.74 | LOW — possible abbreviation or specialisation; skip unless user asks |
+
+Only carry HIGH and MEDIUM candidates into Step 3.
+
+### 2d. Quick exit rule
+
+If the vault has fewer than 10 pages, skip the pair loop and report "vault too small to have meaningful duplicates". If the vault has more than 500 pages, process candidates in batches of 50 pairs — pause and report progress between batches.
+
+## Step 3: Semantic Verdict
+
+For each candidate pair (sorted by score descending):
+
+1. Read both pages in full (full page read — justified because candidate pool is small).
+2. Ask: are these pages covering the **same concept**, or are they distinct?
+
+Assign one of three verdicts:
+
+| Verdict | Meaning |
+|---|---|
+| `merge` | Same concept — different name, abbreviation, alias, or accidental duplicate. Safe to merge. |
+| `keep-separate` | Related but distinct — e.g. "Server Actions" vs "Server Components" are related React features, not duplicates. |
+| `needs-review` | Ambiguous — substantial overlap but also meaningful differences. Flag for the user to decide. |
+
+Attach a short reason to each verdict (one sentence). This appears in the report and the log.
+
+## Step 4: Audit Report
+
+Always produce this report, even in merge/auto-merge mode (so the user sees what will happen):
+
+```markdown
+## Wiki Dedup Report
+
+### High-Confidence Candidates (score ≥ 0.90): N pairs
+
+| Score | Page A | Page B | Verdict | Reason |
+|---|---|---|---|---|
+| 0.95 | `concepts/rsc.md` | `concepts/react-server-components.md` | merge | "RSC" is the abbreviation; both pages cover identical material |
+| 0.91 | `entities/vaswani-2017.md` | `references/attention-is-all-you-need.md` | keep-separate | One is a person stub, one is a paper reference |
+
+### Medium-Confidence Candidates (score 0.75–0.89): N pairs
+
+| Score | Page A | Page B | Verdict | Reason |
+|---|---|---|---|---|
+| 0.82 | `concepts/fine-tuning.md` | `concepts/finetuning.md` | merge | Same concept, hyphenation variant |
+
+### Needs Human Review: N pairs
+
+| Score | Page A | Page B | Reason |
+|---|---|---|---|
+| 0.78 | `concepts/agents.md` | `concepts/autonomous-agents.md` | Substantial overlap but "agents" may intentionally be broader |
+
+### Summary
+- Pages scanned: N
+- Candidate pairs found: M
+- Recommended merges: X
+- Keep separate: Y
+- Needs review: Z
+```
+
+In **Audit mode**, stop here and ask: "Run `--merge` to interactively merge the recommended pairs, or `--auto` to merge all high-confidence ones automatically?"
+
+## Step 5: Merge
+
+**Pre-write snapshot** — before the first file write, check whether the vault itself is the root of a Git repository. Merely being a subdirectory of a larger repository does not qualify: running `git add -A` there could capture unrelated files. If the vault is not a standalone Git repository, skip this step silently — no nagging, no suggesting `git init`.
+
+```bash
+VAULT_REAL_PATH=$(cd "$OBSIDIAN_VAULT_PATH" && pwd -P)
+VAULT_GIT_ROOT=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse --show-toplevel 2>/dev/null || true)
+SNAPSHOT_SHA=""
+
+if [ -n "$VAULT_GIT_ROOT" ] && [ "$VAULT_GIT_ROOT" = "$VAULT_REAL_PATH" ]; then
+  if git -C "$OBSIDIAN_VAULT_PATH" diff --quiet \
+    && git -C "$OBSIDIAN_VAULT_PATH" diff --cached --quiet \
+    && [ -z "$(git -C "$OBSIDIAN_VAULT_PATH" ls-files --others --exclude-standard)" ]; then
+    SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD)
+  else
+    if ! git -C "$OBSIDIAN_VAULT_PATH" add -A; then
+      echo "Pre-write snapshot failed; abort the skill without writing any vault files." >&2
+      exit 1
+    fi
+    if ! git -C "$OBSIDIAN_VAULT_PATH" commit -m "pre-wiki-dedup snapshot" --quiet; then
+      echo "Pre-write snapshot failed; abort the skill without writing any vault files." >&2
+      exit 1
+    fi
+    SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD)
+  fi
+fi
+```
+
+The clean-repository branch deliberately avoids calling `git commit`, so "nothing to commit" is not treated as an error. If `git add` or `git commit` fails, stop before editing the vault; never continue without the promised snapshot.
+
+If `SNAPSHOT_SHA` is non-empty and the skill writes files, include the SHA in the final report. To discard the entire run, after confirming there are no later changes worth keeping, the user can run:
+
+```bash
+git -C "$OBSIDIAN_VAULT_PATH" reset --hard "$SNAPSHOT_SHA"
+git -C "$OBSIDIAN_VAULT_PATH" clean -fd
+```
+
+For each `merge` verdict pair (in merge or auto-merge mode):
+
+In **merge mode**: show the pair and verdict, then ask: "Merge `[Page A]` into `[Page B]`? (yes/skip/review)". Skip on anything other than yes.
+
+In **auto-merge mode**: only process HIGH-confidence (`score ≥ 0.90`) merges without prompting.
+
+### 5a: Pick the canonical page
+
+Apply these tiebreakers in order until one wins:
+
+1. **More incoming wikilinks** — grep the vault for `[[node_id]]` references; higher count wins
+2. **Richer content** — longer page body (more lines) wins
+3. **More sources** — larger `sources:` list wins
+4. **Title length** — longer, more descriptive title wins (e.g. "React Server Components" beats "RSC")
+5. **Alphabetical** — earlier title wins
+
+The canonical page is the **survivor**. The other page becomes the **secondary** (to be merged in, then replaced with a redirect stub).
+
+### 5b: Merge content into the canonical page
+
+Read both pages. Update the canonical page:
+
+- **`aliases:`** — add secondary page's title and all its aliases (no duplicates)
+- **`tags:`** — merge both tag lists (deduplicate, cap at 5 domain tags + system tags)
+- **`sources:`** — merge both source lists (deduplicate)
+- **`relationships:`** — merge both relationship lists (deduplicate by target, prefer typed entries over untyped)
+- **`base_confidence`** — recompute using the union of sources and the formula from `llm-wiki/SKILL.md`
+- **`updated`** — set to now
+- **`summary:`** — rewrite to cover the merged scope if the secondary page added new ground
+- **Body content** — merge unique sections and bullets from the secondary page. Do not blindly append — integrate the content. Avoid duplicating claims already present in the canonical page. Use `^[inferred]` markers where synthesis is needed.
+- **`provenance:`** — recompute after merging
+
+### 5c: Write a redirect stub at the secondary page path
+
+```markdown
+---
+title: <secondary page title>
+redirects_to: "[[<canonical node_id>]]"
+aliases: [<secondary aliases>]
+category: <secondary category>
+tags: []
+created: <secondary original created>
+updated: <ISO timestamp now>
+---
+
+This page has been merged into [[<canonical page title>]].
+```
+
+The `redirects_to:` field tells any skill reading this page to follow the redirect rather than treat it as content.
+
+### 5d: Rewrite wikilinks vault-wide
+
+Grep the entire vault for any link pointing at the secondary slug:
+
+- `[[secondary-slug]]` → `[[canonical-slug]]`
+- `[[secondary-slug|display text]]` → `[[canonical-slug|display text]]`
+- If `OBSIDIAN_LINK_FORMAT=markdown`: `[text](../path/to/secondary.md)` → `[text](../path/to/canonical.md)`
+
+**Safety rules:**
+- Never rewrite inside code blocks (``` fences or `inline code`)
+- Never rewrite inside the redirect stub itself (that's the one place the old slug should remain legible)
+- Never use `rm` or destructive shell ops — only Edit/Write tools
+- Rewrite one file at a time, verifying each before moving on
+- If a file has zero occurrences, skip it
+
+### 5e: Update tracking files
+
+**`index.md`** — Remove the secondary page's entry. Update the canonical page's entry with the merged summary.
+
+**`.manifest.json`** — For the secondary page's source entries: add `"merged_into": "<canonical node_id>"` to each. For the canonical page: merge in the secondary's `pages_created` and `pages_updated` lists.
+
+**`hot.md`** — Update Recent Activity: "Merged N duplicate pairs; canonical pages updated."
+
+### 5f: Final check
+
+After all merges, grep the vault for any remaining `[[secondary-slug]]` references (in non-stub files). If any survive, report them — the rewrite step may have missed a non-standard link format.
+
+## Step 6: Log
+
+Append to `log.md`:
+```
+- [TIMESTAMP] DEDUP mode=audit|merge|auto-merge pages_scanned=N pairs_found=M merged=X kept_separate=Y needs_review=Z wikilinks_rewritten=W
+```
+
+## Redirect Stub Handling
+
+Other skills should handle redirect stubs as follows:
+
+- **`wiki-export`** — skip pages with `redirects_to:` in frontmatter; they are not content nodes
+- **`wiki-query`** — if a search hits a redirect stub, follow `redirects_to:` and read the canonical page instead
+- **`wiki-lint`** — validate that every `redirects_to:` wikilink resolves to an existing, non-stub page (a redirect chain — stub pointing to stub — is an error)
+- **`cross-linker`** — treat redirect stubs as non-targets; never add a new `[[wikilink]]` pointing at a stub page
+
+## Tips
+
+- **Audit first, always.** Even in auto-merge mode, the audit report is shown. Read it before trusting the results.
+- **Check `needs-review` last.** These are the hard cases — don't batch them with obvious merges.
+- **Abbreviations are the most common case.** "GPT" / "GPT-4" / "GPT4", "RSC" / "React Server Components", "LLM" / "Large Language Models" — these score high on substring containment and are almost always safe to merge.
+- **Different versions are not duplicates.** "GPT-3" and "GPT-4" are related but distinct. "fine-tuning" and "fine-tuning-llms" may be distinct (technique vs. specific application).
+- **Run `cross-linker` after dedup.** The redirect stubs leave the graph in a slightly inconsistent state. Cross-linker will tighten it up.
+
+## 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>`

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

@@ -0,0 +1,243 @@
+---
+name: wiki-digest
+description: >
+  Generate a periodic knowledge digest — a human-readable newsletter-style summary of what was
+  learned, updated, and connected in your wiki over a specified period (day/week/month). Use when
+  the user says "what did I learn this week", "give me a digest", "weekly summary", "knowledge
+  report", "what's new in my wiki", "/wiki-digest [period]", "summarize my recent learning", or
+  wants a readable overview of recent wiki activity. Distinct from wiki-status (which reports
+  ingestion delta of sources) — wiki-digest summarizes *knowledge*, not sources.
+---
+
+# Wiki Digest — Knowledge Newsletter Generator
+
+You are generating a human-readable digest of recent wiki activity: what was learned, what was updated, what themes are emerging, and what's worth reviewing. This skill summarizes *knowledge*, not sources — think of it as a weekly review session, not an ingestion status report.
+
+## 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` and `OBSIDIAN_LINK_FORMAT`.
+2. **Parse the period** from the user's request:
+   - "daily" / "today" / "yesterday" → last 24 hours
+   - "weekly" / "this week" / no argument (default) → last 7 days
+   - "monthly" / "this month" → last 30 days
+   - ISO date like "since 2026-05-01" → pages updated since that date
+   - Explicit number like "last 14 days" → that many days
+3. Read `$OBSIDIAN_VAULT_PATH/log.md` — last 200 lines — for entries within the period (timestamps are ISO-8601 prefixed lines).
+4. Read `$OBSIDIAN_VAULT_PATH/hot.md` for current session context.
+5. If `$OBSIDIAN_VAULT_PATH/_insights.md` exists, read its **Anchor Pages** table — you'll use it later to identify which new pages became hubs.
+
+## Step 1: Collect Pages Active in the Period
+
+Glob all `.md` files under `$OBSIDIAN_VAULT_PATH`. Skip special/system files:
+- `index.md`, `log.md`, `hot.md`, `AGENTS.md`, `_insights.md`
+- Anything under `_meta/`, `_archives/`, `_raw/`
+- Journal digest pages themselves (`journal/digest-*.md`)
+
+For each remaining page, read its frontmatter:
+- `created` — when the page was first written
+- `updated` — when it was last modified
+
+Classify:
+- **New pages**: `created` is within the period
+- **Updated pages**: `updated` is within the period but `created` is before it
+- **Unchanged**: neither date falls in the period → skip
+
+If fewer than 5 pages were active, note it and offer to widen: *"Only 3 pages were active in the last 7 days — want a monthly digest instead?"* Stop here unless the user says to continue.
+
+For each active page, collect: `title`, `category`, `tags`, `summary` (frontmatter field), `lifecycle`, any `^[ambiguous]` or `^[inferred]` markers in the body.
+
+## Step 2: Identify Themes
+
+From all active pages' tags, tally theme frequency:
+
+```
+For each tag across new + updated pages:
+  count how many active pages carry it
+Sort descending, take top 5
+```
+
+Also read `$OBSIDIAN_VAULT_PATH/_meta/taxonomy.md` (if it exists). Flag any tag from step 1 that **does not appear** in the taxonomy — these are new vocabulary words that emerged this period.
+
+Note which categories grew most (concepts/, entities/, skills/, synthesis/, references/, etc.).
+
+## Step 3: Find Notable New Connections
+
+Scan new and updated pages for cross-category wikilinks — links that bridge different knowledge layers. These are the most intellectually interesting outputs of the period.
+
+For each active page, extract all `[[wikilink]]` targets. Classify each link by the target's category prefix. Flag links that cross categories (e.g., a `concepts/` page linking to an `entities/` page, or a `synthesis/` page bridging two topics).
+
+Rank candidates by interestingness:
+- **+3** if the link is across two categories that rarely connect (use `_insights.md` bridge data if available)
+- **+2** if the target page is a top-10 hub (per `_insights.md` anchors)
+- **+2** if the link appears in a `synthesis/` page (deliberate cross-cutting)
+- **+1** if the source page is marked `^[inferred]` (synthesized connection, not directly stated)
+
+Take the top 3–5 connections. Write each as a plain-English sentence: not just "A → B" but *why* the connection is interesting.
+
+## Step 4: Surface Open Threads
+
+Scan active pages and `_raw/` for unresolved work:
+
+- **Drafts**: pages with `lifecycle: draft` or `lifecycle: stub`
+- **Ambiguous claims**: count `^[ambiguous]` markers across all active pages (don't list every one — just the count and which pages have the most)
+- **Unstaged notes**: count files in `$OBSIDIAN_VAULT_PATH/_raw/` (anything here hasn't been promoted)
+- **Taxonomy gaps**: tags from Step 2 that aren't in `_meta/taxonomy.md`
+
+## Step 5: Choose Recommended Re-reads
+
+From the *existing* (pre-period) pages, identify 2–3 worth revisiting given this week's new context.
+
+Heuristic: find pre-period pages that share the most tags with the active pages from Step 1. These are foundational pages whose topic was extended this period — the new pages build on them but the user may not have revisited the foundation.
+
+Also include any pre-period page that now has 2+ new incoming links from active pages (it just became more connected — a sign it's load-bearing).
+
+Write each recommendation with a concrete reason: *"[[concepts/attention-mechanism]] — your foundational page; three new papers ingested this week all extend it"*, not just the page title.
+
+## Step 6: Generate the Digest
+
+Produce a structured, scannable markdown report. The Headlines section is the most important — it should feel like the opening of a good newsletter, synthesizing actual insight rather than listing page names.
+
+Apply the link format from `llm-wiki/SKILL.md` (Link Format section) using `OBSIDIAN_LINK_FORMAT`. Default is `[[wikilink]]`.
+
+```markdown
+# Wiki Digest — [Period Label]
+> [N new pages · M updated pages · period: YYYY-MM-DD to YYYY-MM-DD]
+
+## Headlines
+
+- [Concrete insight #1 — synthesize the actual knowledge, not just "learned about X"]
+- [Concrete insight #2]
+- [Concrete insight #3]
+
+## New Knowledge
+
+### New pages ([count])
+| Page | Category | Summary |
+|---|---|---|
+| [[concepts/foo]] | concept | One-sentence summary from frontmatter |
+| [[entities/bar]] | entity | One-sentence summary |
+
+### Notable updates ([count])
+| Page | What changed |
+|---|---|
+| [[skills/react-hooks]] | Added patterns for useCallback with async effects |
+
+*(If no updates, omit this subsection.)*
+
+## Emerging Themes
+
+- **#[tag]** ([N pages]) — [One sentence on why this topic was active]
+- **#[tag]** ([N pages]) — [...]
+- **#[NEW TAG]** ([N pages]) ⭐ *New vocabulary — not yet in taxonomy*
+
+Most active category: **[category/]** ([N pages added or updated])
+
+## Key Connections Made
+
+- [[concepts/A]] → [[entities/B]] — [Plain-English reason this connection is interesting]
+- [[synthesis/X]] created — bridges [[concepts/Y]] and [[concepts/Z]] for the first time
+- *(up to 5 connections)*
+
+## Open Threads
+
+- **Drafts to compile** ([count]): [[concepts/foo]], [[concepts/bar]] — still in draft lifecycle
+- **Ambiguous claims**: [N] `^[ambiguous]` markers across [M] pages — run `/wiki-synthesize` to resolve
+- **Unstaged notes**: [N] files in `_raw/` — run `/wiki-ingest _raw/` to promote them
+- **Taxonomy gaps**: Tags `#newtag1`, `#newtag2` used but not in taxonomy — run `/tag-taxonomy`
+
+*(Omit any subsection where count is 0.)*
+
+## Recommended Re-reads
+
+- [[concepts/X]] — [Specific reason: "3 new papers this week all extend this concept"]
+- [[synthesis/Y]] — [Specific reason: "2 new pages created this week reference it"]
+- [[skills/Z]] — [Specific reason: "now has 4 new incoming links — it's become a hub"]
+
+---
+*Generated by wiki-digest · [TIMESTAMP] · [N pages scanned in [VAULT_PATH]]*
+```
+
+**Visibility**: If a page is tagged `visibility/pii`, exclude it from all tables and connection lists (but count it in the totals, noted as "+ N private"). If the user explicitly says "include private pages" or "full digest", include them normally.
+
+## Step 7: Output & Optionally Save
+
+**Default (chat output):** Print the digest directly. At the end, ask:
+*"Want me to save this as `journal/digest-YYYY-MM-DD.md`?"*
+
+**If user prefixed with "save" or "write"** (e.g., `/wiki-digest save` or "generate and save my weekly digest"):
+- Write to `$OBSIDIAN_VAULT_PATH/journal/digest-YYYY-MM-DD.md` (weekly/monthly) or `journal/digest-YYYY-MM-DD-daily.md` (daily)
+- Add frontmatter:
+  ```yaml
+  ---
+  title: "Wiki Digest — [Period Label]"
+  category: journal
+  tags: [digest, meta/review]
+  sources: []
+  created: TIMESTAMP
+  updated: TIMESTAMP
+  summary: "Weekly knowledge digest: [N new, M updated pages]. Top themes: [tag1], [tag2]."
+  ---
+  ```
+- Update `index.md` with the new entry under Journal
+- Do **not** add to `.manifest.json` (digests aren't source ingestions)
+
+Either way, append to `log.md`:
+```
+- [TIMESTAMP] DIGEST period="7d" new_pages=N updated_pages=M themes=T connections=C saved=false
+```
+
+## Edge Cases
+
+| Situation | Handling |
+|---|---|
+| Fewer than 5 active pages | Offer to widen the period; proceed only if user confirms |
+| Empty vault (no pages at all) | Tell the user to run an ingest first; stop |
+| No `_meta/taxonomy.md` | Skip taxonomy gap check; omit that line from Open Threads |
+| No `_insights.md` | Skip hub-based scoring in Step 3; still produce connections section |
+| All pages are `visibility/pii` | Report "N private pages active this period" with no details; offer full mode |
+| Period spans a wiki rebuild | Note it in the digest: "Wiki was rebuilt during this period — page dates reflect post-rebuild state" |
+
+## Notes
+
+- **Headlines are the payoff.** Don't list page titles — synthesize the actual learning. If someone learned about attention mechanisms this week, the headline should capture the insight, not just say "added 3 transformer pages".
+- **Be concrete about re-reads.** "This page is relevant" is useless. "3 of this week's papers all cite the same claim in this page" is actionable.
+- **This skill only reads.** The only writes are the optional journal page, and the `log.md` append. It does not modify existing wiki pages.
+- **Don't duplicate wiki-status.** If the user asks "what needs ingesting" or "what's the delta", route to `wiki-status`. This skill answers "what did I learn", not "what's pending".
+
+## 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>`