/refresh

description: "Check if active wiki articles are still current. Re-fetches sources, detects changes, and offers to update stale articles."
argument-hint: "[<article-path>|--due] [--wiki <name|all>] [--local] [--include-archived]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(wc:*), Bash(date:*), WebFetch, WebSearch, Agent

Your task

**Resolve the wiki.** Do NOT search the filesystem or read reference files — follow these steps: 1. Read `$HOME/.config/llm-wiki/config.json`. If it has `hub_path`, expand leading `~` only (not tildes in `com~apple~CloudDocs`) and prefer that path; use `resolved_path` only as a fallback cache when the expanded `hub_path` is unavailable and `resolved_path` is initialized. If config has only `resolved_path`, use it. If the configured path can be statted but reading `wikis.json` or listing `topics/` fails with `Operation not permitted`, stop and ask the user to grant Full Disk Access/iCloud Drive access to the launcher; do not fall back to `~/wiki` or `resolved_path`. Do not write machine-specific `resolved_path` into shared configs. 2. If no config → read `$HOME/wiki/_index.md`. If it exists → HUB = `$HOME/wiki`. If nothing found, ask the user where to create the wiki. 3. **Wiki location** (first match): `--local` → `.wiki/` in CWD; `--wiki all` → HUB with an `ALL_TOPICS` flag for step 5; `--wiki <name>` → `HUB/wikis.json` lookup with portable path resolution (`<HUB>`, `~`, absolute, or HUB-relative); if the registry path is stale, fall back to `HUB/topics/<name>`; CWD has `.wiki/` → use it; else → HUB. 4. Read `<wiki>/_index.md` to verify. If missing → stop with "No wiki found. Run `/wiki init` first." 5. **Hub-level detection**: Refresh operates on articles inside a single topic wiki. The HUB has no `wiki/` subdirectory. If `ALL_TOPICS` is set from `--wiki all`, read registered topic wikis from `HUB/wikis.json` (excluding the synthetic `hub` entry) and iterate refresh against each topic wiki sequentially. If the resolved wiki is the HUB (detected by the presence of `wikis.json` and the absence of a `wiki/` subdir) AND the user did not pass `--wiki <name>`, do NOT iterate against an empty topic surface. Instead, present a numbered list of registered topic wikis from `HUB/wikis.json` and ask the user to pick one. Re-resolve the wiki path with the selected name (`HUB/topics/<name>/`) and continue.

Check whether wiki articles are still current by re-examining their sources. This is NOT automatic recompilation — it's a human-gated assessment of what may have changed.

Inventory awareness: if refresh finds a source that needs later follow-up, monitoring, replacement, or access repair, offer an inventory record or update an existing one. Do not create records for every minor stale article; reserve inventory for durable watch items and blocked actions.

Parse $ARGUMENTS

• **article-path**: Path to a specific wiki article to refresh (e.g., `wiki/concepts/nvidia-spark.md`)
• **--due**: Check ALL articles past their volatility tier's staleness threshold. Present a numbered list for the user to select which ones to refresh.
• **--include-archived**: Explicitly include archived topic wikis. Archived

topics are skipped by default so old interests do not create freshness chores.

• If neither is provided, show articles sorted by staleness (most overdue first) and ask which to check.

When `--wiki all` is used, iterate active registered topic wikis only unless `--include-archived` is present. If a single `--wiki <name>` target is archived, ask for `--include-archived` or restoration before refreshing.

Refresh Protocol

For each article being refreshed:

Tier 1: Source Check

1. Read the article's `sources:` frontmatter to get the list of raw source files. Resolve each entry with the Source Reference Resolution protocol in `references/wiki-structure.md`; preserve paths with whitespace and never split entries on whitespace. 2. For each raw source, read its `source:` URL from frontmatter 3. Use WebFetch to re-fetch the URL content 4. Compare the fetched content against the stored raw source using key-fact extraction:

• Extract 5-10 key claims/facts/numbers from the stored raw source
• Check whether those same facts appear unchanged in the current version
• Note any new sections, updated statistics, or changed conclusions

5. Classify each source as: **unchanged**, **updated** (new info available), **contradicted** (facts changed), or **unreachable** (URL 404/timeout)

Tier 2: Change Assessment

For sources classified as **updated** or **contradicted**:

1. Summarize what changed: new information added, statistics updated, conclusions revised, sections removed 2. Classify the change impact on the wiki article:

• **Cosmetic**: formatting, typos, no factual change — no action needed
• **Additive**: new information that could supplement the article — optional update
• **Contradictory**: information that conflicts with the article's claims — update recommended

Tier 3: Action Decision

Present the assessment to the user with options per source:

## Refresh Report — <article title>

### Sources checked: N

1. **[Source Title]** — unchanged (last fetched: YYYY-MM-DD)
2. **[Source Title]** — updated (additive)
   What changed: New benchmarks published for 2026 Q2, 15% performance improvement reported
   → skip | update | flag
3. **[Source Title]** — unreachable (HTTP 404)
   → skip | retract

### Article freshness
Current: volatility hot, verified 45 days ago
Recommendation: update sources 2, retract source 3

On user selection:

• **skip**: No changes. Update `verified` date to today (human confirmed it's still accurate).
• **update**: Re-ingest the changed source (overwrite the raw file with new content, preserve frontmatter), then recompile the article following the standard compilation protocol.
• **flag**: Degrade the article's `confidence` by one level (high→medium, medium→low). Add a note to the artic