Best for
- Use this skill when the user asks "what's the status", "how much is ingested", "what's left to process", "show me the delta", "what changed since last ingest", "wiki dashboard", or wants an overview of their knowledge b…
Ar9av/obsidian-wiki/.skills/wiki-status/SKILL.md
Show the current state of the wiki — what's been ingested, what's pending, and the delta between sources and wiki content. Use this skill when the user asks "what's the status", "how much is ingested", "what's left to process", "show me the delta", "what changed since last ingest", "wiki dashboard", or wants an overview of their knowledge base health and completeness. Also use before deciding whether to append or rebuild. Includes an insights mode triggered by "wiki insights", "what's central",
Decision brief
You are computing the current state of the wiki: what's been ingested, what's new since last ingest, and what the delta looks like. This helps the user decide whether to append (ingest the delta) or rebuild (archive and reprocess everything).
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Declared | Source record | Install path and trigger |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/Ar9av/obsidian-wiki --skill ".skills/wiki-status"Inspect the Agent Skill "wiki-status" from https://github.com/Ar9av/obsidian-wiki/blob/3d39cb491a28cd11c96e13d31349a4a9367b865e/.skills/wiki-status/SKILL.md at commit 3d39cb491a28cd11c96e13d31349a4a9367b865e. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Build an inventory of everything available to ingest right now:
Compare current sources against the manifest. Classify each source file:
Visibility tally (before rendering the report): Grep frontmatter across all vault .md pages for visibility/internal and visibility/pii tag values. Count: - public = pages with visibility/public tag or no visibility/ tag at all - internal = pages with visibility/internal tag - pi…
After building the status summary, compute the token footprint estimate:
Replace the old single-line Recommendation with a ranked What to Do Next section. Gather these signals before rendering:
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 86/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 3,117 | Source | Repository attention, not individual Skill quality |
| Compatibility | 1 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
You are computing the current state of the wiki: what's been ingested, what's new since last ingest, and what the delta looks like. This helps the user decide whether to append (ingest the delta) or rebuild (archive and reprocess everything).
llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → ~/.obsidian-wiki/config → prompt setup). This gives OBSIDIAN_VAULT_PATH, OBSIDIAN_SOURCES_DIR, CLAUDE_HISTORY_PATH, and CODEX_HISTORY_PATH..manifest.json at the vault root — this is the ingest tracking ledgerThe manifest lives at $OBSIDIAN_VAULT_PATH/.manifest.json. It tracks every source file that has been ingested. If it doesn't exist, this is a fresh vault with nothing ingested.
Source keys are canonical absolute paths (
~and env vars expanded). Never mix~-relative and absolute keys — the same file would be tracked twice and re-ingested. Seellm-wiki/SKILL.md→.manifest.json. Repair a mixed manifest withscripts/manifest.py normalize <vault>.
{
"version": 1,
"last_updated": "2026-04-06T10:30:00Z",
"sources": {
"/absolute/path/to/file.md": {
"ingested_at": "2026-04-06T10:30:00Z",
"size_bytes": 4523,
"modified_at": "2026-04-05T08:00:00Z",
"source_type": "document",
"project": null,
"pages_created": ["concepts/transformers.md"],
"pages_updated": ["entities/vaswani.md"]
},
"/Users/name/.claude/projects/-Users-name-my-app/abc123.jsonl": {
"ingested_at": "2026-04-06T11:00:00Z",
"size_bytes": 128000,
"modified_at": "2026-04-06T09:00:00Z",
"source_type": "claude_conversation",
"project": "my-app",
"pages_created": ["entities/my-app.md"],
"pages_updated": ["skills/react-debugging.md"]
}
},
"projects": {
"my-app": {
"source_path": "/Users/name/.claude/projects/-Users-name-my-app",
"vault_path": "projects/my-app",
"last_ingested": "2026-04-06T11:00:00Z",
"conversations_ingested": 5,
"conversations_total": 8,
"memory_files_ingested": 3
}
},
"stats": {
"total_sources_ingested": 42,
"total_pages": 87,
"total_projects": 6,
"last_full_rebuild": null
}
}
Build an inventory of everything available to ingest right now:
OBSIDIAN_SOURCES_DIR)Glob each directory in OBSIDIAN_SOURCES_DIR for all text files
Record: path, size, modification time
CLAUDE_HISTORY_PATH)Glob: ~/.claude/projects/*/ → project directories
Glob: ~/.claude/projects/*/*.jsonl → conversation files
Glob: ~/.claude/projects/*/memory/*.md → memory files
Record: path, size, modification time, parent project
CODEX_HISTORY_PATH)Glob: ~/.codex/session_index.jsonl → session inventory index
Glob: ~/.codex/sessions/**/rollout-*.jsonl → session rollout transcripts
Glob: ~/.codex/history.jsonl → optional local history log
Glob: ~/.codex/archived_sessions/**/rollout-*.jsonl → archived rollouts (if user wants archive coverage)
Record: path, size, modification time, inferred project from cwd when available
Check the manifest for source paths outside the standard directories.
Compare current sources against the manifest. Classify each source file:
| Status | Meaning | Action needed |
|---|---|---|
| New | File exists on disk, not in manifest | Needs ingesting |
| Modified | File in manifest, hash differs from content_hash | Needs re-ingesting |
| Touched | File in manifest, mtime newer but hash unchanged | Skip — content identical, no re-ingest needed |
| Unchanged | File in manifest, mtime and hash both match | Nothing to do |
| Deleted | In manifest, but file no longer exists on disk | Note it — wiki pages may be stale |
When a manifest entry has no content_hash (older entry), fall back to mtime comparison only.
For Claude history specifically, also compute:
~/.claude/projects/ not in manifest)For Codex history specifically, also compute:
sessions/**session_index.jsonl entries (session title/freshness changes)Visibility tally (before rendering the report): Grep frontmatter across all vault .md pages for visibility/internal and visibility/pii tag values. Count:
public = pages with visibility/public tag or no visibility/ tag at allinternal = pages with visibility/internal tagpii = pages with visibility/pii tagInclude this in the Overview section as Page visibility: N public · M internal · K pii. Skip the line if all pages are untagged (fully public vault).
Present a clear summary:
# Wiki Status
## Overview
- **Total wiki pages:** 87 across 6 categories
- **Page visibility:** 72 public · 11 internal · 4 pii
- **Total sources ingested:** 42
- **Projects tracked:** 6
- **Last ingest:** 2026-04-06T11:00:00Z
- **Staged writes pending:** 4 pages · 2 patches (oldest: 3 days ago) ← only when WIKI_STAGED_WRITES=true
## Delta (what's changed since last ingest)
### New sources (never ingested): 12
| Source | Type | Size |
|---|---|---|
| ~/Documents/research/new-paper.pdf | document | 2.1 MB |
| ~/.claude/projects/-Users-.../session-xyz.jsonl | claude_conversation | 340 KB |
| ~/.codex/sessions/2026/04/12/rollout-...jsonl | codex_rollout | 220 KB |
| ... | | |
### Modified sources (need re-ingesting): 3
| Source | Last ingested | Last modified | Delta |
|---|---|---|---|
| ~/notes/architecture.md | 2026-04-01 | 2026-04-05 | 4 days newer |
| ... | | | |
### New projects (not yet in wiki): 2
- **tractorex** (3 conversations, 2 memory files)
- **papertech** (1 conversation, 0 memory files)
### Deleted sources (ingested but gone): 0
## Summary
- **Ready to ingest:** 12 new + 3 modified = 15 sources
- **Up to date:** 27 sources unchanged
- **Recommendation:** Append (delta is small relative to total)
## Token Footprint (estimated)
| Scope | Pages | ~Tokens |
|---|---|---|
| core tier | 12 | 18,400 |
| supporting tier | 87 | 94,200 |
| peripheral tier | 43 | 31,600 |
| **Full wiki (all)** | **142** | **144,200** |
Index-only pass (frontmatter + summaries): ~8,900 tokens
Typical query (index + 5 full pages): ~14,200 tokens
⚠️ Full wiki exceeds 100K tokens. Consider:
- Demoting peripheral pages (promote tier suggestions from wiki-status insights mode)
- Running /wiki-lint --consolidate to merge near-duplicates
- Using wiki-query fast mode for most queries
After building the status summary, compute the token footprint estimate:
Per-tier page sizes — Glob all .md pages. Read the tier: frontmatter field of each (cheap grep). Group pages by tier value (core, supporting, peripheral; unset → supporting).
Estimate tokens — For each page, estimate token count as file_size_bytes / 4 (4 chars/token heuristic — no actual tokenizer needed). Sum per tier and total.
Index-only estimate — Estimate the cost of an index-only pass: sum len(title) + len(summary) + len(tags) for each page frontmatter (~100 chars each on average), divided by 4.
Typical query estimate — Index-only estimate + average full-read cost of 5 pages (total_chars / total_pages * 5 / 4).
Threshold check — Read WIKI_TOKEN_WARN_THRESHOLD from config (default: 100000). If 0, skip the warning. If full-wiki token estimate exceeds the threshold, emit a ⚠️ warning with the three remediation suggestions shown in the template above.
Include in every standard status run — both normal and insights mode. The methodology note (4 chars/token heuristic) appears as a footnote below the table.
Replace the old single-line Recommendation with a ranked What to Do Next section. Gather these signals before rendering:
Staged writes pending (only when WIKI_STAGED_WRITES=true) — Glob $OBSIDIAN_VAULT_PATH/_staging/**/*.md and **/*.patch.md. Count new pages and patches separately. Report the oldest file's age (mtime). This is always listed first if any staged files exist — it has the highest intent signal (the LLM already did the work; the human just needs to review).
_raw/ files — list every file at the top level of $OBSIDIAN_VAULT_PATH/_raw/ that isn't a .gitkeep, excluding the _archived/ subdirectory (already-promoted drafts kept for provenance, not pending work). Count and name them.
Stale core pages — scan all vault .md files. A page is "stale" when its updated frontmatter field is ≥90 days before today's date AND it has ≥5 incoming wikilinks (i.e., it's "core" — other pages depend on it). List them by name + last-updated date.
Orphan pages — pages with zero incoming wikilinks. To compute: glob all .md pages, extract every [[wikilink]], count references to each page, collect pages with incoming == 0. Show up to 5 names; report total count.
Synthesis opportunities — check hot.md for any recent /wiki-synthesize run summary. If the last synthesis run reported N opportunities, surface that count. If no synthesis has been run recently (not in hot.md or log.md within last 14 days), flag it as "synthesis scan overdue".
Source delta — from Step 2: count of new + modified sources ready to ingest.
Lint issues — check log.md for a recent /wiki-lint run (within last 30 days). If a recent run recorded broken links or missing frontmatter, surface the count. If no lint run appears in the log, flag "lint not run recently".
Score each category and emit a ranked list, capped at 6 items. Always rank in this priority order (skip a category if its count is 0 or it has nothing to report):
| Priority | Category | Trigger |
|---|---|---|
| 0 | Staged writes pending | Any .md/.patch.md in _staging/ (only when WIKI_STAGED_WRITES=true) |
| 1 | _raw/ files waiting | Any files present in _raw/ |
| 2 | Stale core pages | Any page: updated ≥90 days ago AND ≥5 incoming links |
| 3 | Orphan pages | Any pages with zero incoming wikilinks |
| 4 | Synthesis opportunities | N opportunities from last synthesize run, OR scan overdue |
| 5 | New/modified sources | Count from delta in Step 2 |
| 6 | Lint issues | Known issues from last lint run, OR lint overdue |
Render as:
## What to Do Next
0. 📋 6 staged pages waiting for review (oldest: 3 days ago)
→ 4 new pages + 2 patches in _staging/
run: /wiki-stage-commit
1. 📥 Ingest 3 files waiting in _raw/
→ architecture-notes.md, meeting-2026-05-10.md, paper-draft.pdf
run: /wiki-ingest
2. 🔄 Refresh 2 stale core pages (not updated in 90+ days)
→ [[System Architecture]] (last updated 2026-02-10), [[API Design]] (2026-01-15)
run: open these pages and re-run /wiki-update
3. 🔗 Link 7 orphan pages → run: /cross-linker
Disconnected: [[Redis Caching]], [[JWT Tokens]], +5 more
4. 🧩 2 synthesis opportunities identified → run: /wiki-synthesize
[[Redis Caching]] × [[Session Management]] (co-occur in 8 pages)
5. ✅ 4 sources modified since last ingest → run: /wiki-ingest (append mode)
6. 🩺 Lint not run in 30+ days — run: /wiki-lint
Empty state: If all categories have nothing to report (no staged files, no _raw/ files, no orphans, no stale pages, no synthesis opportunities, no new sources, no lint issues), output instead:
## What to Do Next
✅ Wiki is healthy — nothing urgent.
All sources up to date · no orphans · no stale core pages · no _raw/ files pending · no staged writes
Overflow: If more than 6 items would be shown, add a footer line: _(N more items available — run /wiki-status --full to see all)_. The --full flag is not yet implemented; this is forward-looking copy that sets expectations.
Triggered when the user asks something like "wiki insights", "what's central in my wiki", "show me the hubs", "cross-domain bridges", "what pages are most important", or "wiki structure". This mode is additive — it doesn't replace the delta report, it analyzes the shape of the wiki itself.
Where the delta report tells the user what's pending, insights mode tells them what they've already built and where the interesting structure lives. Complements wiki-lint (which finds problems) by surfacing interesting structure.
First, run the graph analyser. This replaces manual wikilink parsing — one command produces all the raw data you need:
obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --pretty
Output fields used below:
god_nodes — pages ranked by total degree (in + out). Use for anchor pages and hub classification.communities — page clusters by link density (label propagation / Leiden). Use for bridge detection and cluster labelling.surprising_connections — cross-community edges ranked by unexpectedness. Use directly in the Surprising Connections section.dead_ends — pages with zero outgoing links. Use for orphan-adjacent and cross-linker suggestions.isolated — pages with zero links in either direction. Use for stubs/orphan reporting.stats — total pages, edges, communities.Fallback (if obsidian-wiki is not installed): glob all .md pages, extract every [[wikilink]], and build incoming, outgoing, and tags maps manually.
You'll reuse this data across all sections below.
Anchor pages (top hubs). Pages with the most incoming links — the load-bearing concepts.
incoming count, take top 10Bridge pages. Pages that connect otherwise-disconnected tag clusters — removing them would partition the graph. These are often more structurally important than raw hub count suggests.
P bridges [tag-cluster-A] ↔ [tag-cluster-B]"Tag cluster cohesion. For each tag with ≥ 5 pages, score how tightly the pages within it are interconnected:
n = number of pages sharing this tagactual_links = number of wikilinks between any two pages in this tag groupcohesion = actual_links / (n × (n−1) / 2) — ratio of actual links to maximum possibleSurprising connections. Cross-category wikilinks that are non-obvious — scored by how unexpected they are:
concepts/ → entities/, skills/ → synthesis/):
^[ambiguous] (uncertain connection, worth reviewing)^[inferred] (synthesized, not directly stated)concepts ↔ entities more surprising than concepts ↔ concepts)Orphan-adjacent suggestions. Pages linked from a top-10 hub but with zero outgoing links of their own. Dead-ends in high-traffic areas — prime cross-linker candidates.
Rough clusters. Group anchor pages by dominant tag. (Simple tag intersection — just for orientation.)
Graph delta since last run. Compare the current link graph to the snapshot stored in the previous _insights.md:
<!-- GRAPH_SNAPSHOT: ... --> line at the bottom of the previous _insights.md (if it exists) — it contains a compact JSON edge listTier assignment suggestions. After computing hubs and bridges, recommend tier: changes. Never write tier: to pages — only surface suggestions so the human can decide.
core: pages with ≥5 incoming links OR top-5 bridge position that currently have tier: supporting or no tier: fieldperipheral: pages with ≤1 incoming link AND not updated in 90+ days that currently have tier: supporting or tier: coreTier Suggestions:
↑ core [[concepts/attention-mechanism]] — 14 incoming links, currently tier=supporting
↑ core [[entities/andrej-karpathy]] — bridge (3 cluster pairs), currently unset
↓ peripheral [[concepts/old-concept]] — 0 incoming, 120 days stale
tier: core and all low-link pages have tier: peripheral, emit: "Tier assignments look healthy — no changes suggested."Suggested questions. Questions this wiki structure is uniquely positioned to answer — or that reveal gaps:
^[ambiguous] claims: "Resolve: What is the exact relationship between X and Y?"P connect [cluster-A] to [cluster-B]?"X has no incoming links — what should reference it?"[T] be split into more focused sub-tags?"Write the result to _insights.md at the vault root. Overwrite freely — it's regenerable. At the very end, embed a compact graph snapshot as an HTML comment so the next run can diff against it.
# Wiki Insights — <TIMESTAMP>
## Anchor Pages (top 10 hubs)
| Page | Incoming | Outgoing | Note |
|---|---|---|---|
| [[concepts/transformer-architecture]] | 23 | 8 | connector hub |
| [[entities/andrej-karpathy]] | 17 | 0 | sink hub — cross-linker candidate |
## Bridge Pages (top 5)
| Page | Bridges | Cross-cluster pairs |
|---|---|---|
| [[concepts/exponential-growth]] | #ml ↔ #economics | 4 pairs |
## Tag Cluster Cohesion
### Most cohesive (well-linked)
- **#ml** — 12 pages, cohesion 0.41
### Most fragmented (cross-linker targets)
- **#systems** — 7 pages, cohesion 0.06 ⚠️ run cross-linker on this tag
## Surprising Connections (top 5)
- [[concepts/scaling-laws]] → [[entities/gordon-moore]] — score 5
- Reason: cross-layer (concepts ↔ entities), marked ^[inferred]
- ...
## Orphan-Adjacent (dead-ends near hubs)
- [[concepts/foo]] — linked from 3 hubs, 0 outbound links
## Rough Clusters
- **#ml** — transformer-architecture, attention-mechanism, scaling-laws
- **#systems** — distributed-consensus, raft, paxos
## Graph Delta Since Last Run
- +3 new pages, +11 new wikilinks
- Newly connected: [[concepts/bar]], [[entities/baz]]
- Lost incoming links: [[references/old-paper]] (target may have been renamed)
## Tier Suggestions
↑ core [[concepts/attention-mechanism]] — 14 incoming links, currently tier=supporting
↑ core [[entities/andrej-karpathy]] — top bridge (4 cluster pairs), currently unset
↓ peripheral [[concepts/old-concept]] — 0 incoming, 132 days stale
## Questions Worth Asking
1. Resolve: What is the exact relationship between `scaling-laws` and `moore's-law`? (^[ambiguous] claim)
2. Explore: Why does `exponential-growth` bridge #ml and #economics?
3. Link: `references/foo.md` has no incoming links — what should reference it?
4. Audit: Should tag `#systems` be split? (cohesion 0.06, 7 pages)
<!-- GRAPH_SNAPSHOT: {"nodes":["concepts/foo","entities/bar"],"edges":[["concepts/foo","entities/bar"]]} -->
After writing the file, append to log.md:
- [TIMESTAMP] STATUS_INSIGHTS anchors=10 bridges=N cohesion_checked=T surprising=5 questions=7 delta="+N pages +M links" tier_suggestions=N
wiki-rebuild — wait until at least one ingest has happened._insights.md in insights mode, which is regenerable)wiki-ingest, claude-history-ingest, codex-history-ingest)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.
${QMD_CLI:-qmd} update
If the output says vectors are needed or embeddings may be stale, run:
${QMD_CLI:-qmd} embed
Verify the collection with either:
${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"
or, when a specific page path is known:
${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5
Record one of:
QMD refreshed: update + embed + verifiedQMD refreshed: update only + verifiedQMD skipped: QMD_WIKI_COLLECTION unsetQMD skipped: qmd CLI unavailableQMD failed: <short error summary>Alternatives
wanshuiyin/Auto-claude-code-research-in-sleep
Two-thread adversarial review: a fresh reviewer constructs the strongest 200-word rejection memo, then a second fresh reviewer defends the paper point-by-point and surfaces still-unresolved critical issues. Use when user says "kill argument", "adversarial review", "hostile review", "rebuttal preparation", "reviewer-2 simulation", or before submitting a theory paper that has already passed standard review rounds.
wanshuiyin/Auto-claude-code-research-in-sleep
Two-thread adversarial review: a fresh reviewer constructs the strongest 200-word rejection memo, then a second fresh reviewer defends the paper point-by-point and surfaces still-unresolved critical issues. Use when user says "kill argument", "adversarial review", "hostile review", "rebuttal preparation", "reviewer-2 simulation", or before submitting a theory paper that has already passed standard review rounds.
PramodDutta/qaskills
Generate optimized test combinations using pairwise (all-pairs) testing algorithms to achieve maximum coverage with minimum test cases across multiple input parameters
PramodDutta/qaskills
Gate RAG pipelines in CI with versioned golden eval sets, per-metric thresholds, baseline drift detection, and a build that fails when retrieval or answer quality regresses.