wiki-ingest
Skill189 starsChanged 4 months agoMITView on GitHub
Use when adding a new source to a wiki — a paper, article, URL, file, transcript, or any document. One ingest may touch 10-15 wiki pages.
45 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- methylo/claude-skill-booktheir own version, first seen Nov 8, 2026
- Ar9av/obsidian-wikitheir own version, first seen Nov 8, 2026
- barakgut/llm-wikitheir own version, first seen Nov 1, 2026
- chobizzy/llm-wikitheir own version, first seen Nov 1, 2026
- wareagledusty/wiki-federation-starter-kittheir own version, first seen Nov 1, 2026
- jervislab/skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use wiki-status, wiki-capture and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
nexuschainsSkillwiki-status
Reports the current state of the wiki vault — page counts, category breakdown, hub pages, orphans, stale entries, and a delta showing what has changed since the last ingest. Use this skill when the operator asks "what's the status", "wiki dashboard", "how many pages", "what's stale", "what's been ingested", "show me the delta", or "wiki health overview". Also surfaces structural insights (top hubs, fragmented clusters, bridge pages) when the operator asks "wiki insights", "what's central", or "show me the hubs". Read-only: this skill reports and recommends; it does not modify any files.
Also in 5 projects that use this
jehrhardtSkillwiki-capture
Quickly capture raw thoughts, links, images, or notes to today's Obsidian daily note from anywhere in Pi. Use when the user wants to jot something down for later wiki processing.
Also in 6 projects that use this
Ivy-Chen1999Skillwiki-research
Autonomously research a topic via multi-round web search, synthesize findings, and file structured results into the Obsidian wiki. Use this skill when the user says "/wiki-research [topic]", "research X", "find everything about Y", "do a deep dive on Z", "autonomous research on X", or wants comprehensive, web-sourced knowledge on a topic filed directly into their wiki.
Also in 5 projects that use this
nexuschainsSkillcross-linker
Scans the wiki vault and adds missing [[wikilinks]] between pages that are related but not yet connected. Use this skill when the operator says "link my pages", "find missing links", "cross-reference the wiki", "connect my wiki", "add wikilinks", or after any large ingest to weave new pages into the existing knowledge graph. Also trigger when orphaned pages need connecting or when wiki-lint reports fragmented tag clusters. This is a write-heavy skill — it modifies page files to insert links, unlike wiki-lint which only reports.
Also in 4 projects that use this
Ivy-Chen1999Skillwiki-setup
Initialize a new Obsidian wiki vault with the correct structure, special files, and configuration. Use this skill when the user wants to set up a new wiki from scratch, initialize the vault structure, create the .env file, or says things like "set up my wiki", "initialize obsidian", "create a new vault", "get started with the wiki". Also use when the user needs to reconfigure their existing vault or fix a broken setup.
Also in 5 projects that use this
justvinhhereSkillwiki-review
Use when the user runs /review, says "show pending changes", "what's uncommitted", or wants an audit of uncommitted wiki edits before they land in history. Narrates uncommitted changes, flags structural issues scoped to those changes, and commits them with a conventional subject. Fully automatic.
Also in 8 projects that use this
- +1 more from nexuschains
- +3 more from Ivy-Chen1999
Other versions45 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- bozhouDev/bozhou-skills★ 7884% same
- crabin/llm-wiki★ 848% same
Wrote their own version · 43
- AgriciDaniel/claude-obsidian★ 16ksame name
- sanyuan0704/code-review-expert★ 3.9ksame name
- sanyuan0704/sanyuan-skills★ 3.9ksame name
- Ar9av/obsidian-wiki★ 3.7ksame name
- IssacW228/student-llm-wiki★ 173same name
- vanillaflava/llm-wiki-skills★ 65same name
- cookyman74/llmwiki-harness★ 34same name
- Ivy-Chen1999/llm-wiki-kit★ 21same name
- CarbeneAI/Forge★ 9same name
- CodePhobiia/claude-roblox-game-studio★ 9same name
33 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- wiki-auditSkill
- wiki-initSkill
- wiki-lintSkill
- wiki-mergeSkill
- wiki-querySkill
- wiki-updateSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. 0 are common, 8 are distinctive, and 10 are very specific to this project.
0
Common
Most of the 36 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Add a source to the wiki. Read it, discuss with the user, write a summary page, update entity/concept pages, and maintain the index, …
- Very specific: line 12
Search for SCHEMA.md starting from the current directory and upward, or in common wiki locations (~/wikis/).
- Very specific: line 14
Read SCHEMA.md to learn: wiki root path, page frontmatter format, cross-reference convention, log entry format, index category taxonomy.
- Distinctive: line 29
Read all content. For long sources, read in sections.
- Distinctive: line 38
Ask: "Anything specific you want me to emphasize or de-emphasize?"
- Distinctive: line 40
Wait for the user's response before proceeding.
- Distinctive: line 122
If you cannot produce either citation kind for a claim, you do not have a citation.
- Distinctive: line 146
Only when all three passes are clean do you move on to entity pages.
- Very specific: line 152
Page exists: Read it, add to or update the relevant section, add this source to frontmatter sources list, update updated date
- Distinctive: line 153
Page doesn't exist: Create it:
- Very specific: line 222
Use internal in place of the [[slug]] for a within-page conflict.
- Very specific: line 230
When a conflict is resolved, remove the contradiction-check line from the page.
- Very specific: line 231
Only once no contradiction-check: failed line remains on any touched page do you continue.
- Very specific: line 236
not: write anything to any page and do not block.
- Very specific: line 241
Do not hand-edit the index.
- Very specific: line 260
Update the frontmatter updated date.
- Very specific: line 264
Gate first: do not suggest a commit while any page touched this ingest still carries a contradiction-check: failed line (step 7b).
- Distinctive: line 271
Commit on the user's confirmation.
“Common” is measured: kept by at least 6 in 10 of the 36 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Wiki Ingest
Add a source to the wiki. Read it, discuss with the user, write a summary page, update entity/concept pages, and maintain the index, overview, and log.
Pre-condition
Search for SCHEMA.md starting from the current directory and upward, or in common wiki locations (~/wikis/). If not found, tell the user to run wiki-init first.
Read SCHEMA.md to learn: wiki root path, page frontmatter format, cross-reference convention, log entry format, index category taxonomy.
Link style. Read link_style: from SCHEMA.md. If the field is missing or <wiki-root>/config/link-style.md does not exist, default to obsidian and use [[slug]] as the cross-reference form. Otherwise, read <wiki-root>/config/link-style.md for the exact emit and parse rules. Every cross-reference and citation slug-target you write below must follow that file's ## Emit rule. Every scan of existing pages (the backlink audit in step 7) must follow its ## Parse rule.
Process
1. Accept the source
The source can be:
- File path — read it directly; copy to
raw/<filename>if not already there - URL — use the
browseskill to fetch it; save toraw/<slug>.<ext> - Pasted text — use what was provided
2. Read the source in full
Read all content. For long sources, read in sections. Do not skip.
3. Surface takeaways — BEFORE writing anything
Tell the user:
- 3-5 bullet points of key takeaways
- What entities/concepts this introduces or updates
- Whether it contradicts anything already in the wiki (regenerate the index first —
python bin/generate-index.py— then readwiki/index.mdand relevant pages to check)
Ask: "Anything specific you want me to emphasize or de-emphasize?"
Wait for the user's response before proceeding.
4. Generate the slug
Lowercase, hyphens, no special characters.
Example: "Attention Is All You Need" → attention-is-all-you-need
5. Write the source summary page
Write wiki/pages/<slug>.md:
---
title: <source title>
category: <one of the wiki's Index Categories — e.g. Sources>
summary: <one-line description for the index>
tags: [<relevant tags>]
sources: [<slug>]
created: <today>
updated: <today>
---
# <Source Title>
**Source:** <original URL or file path>
**Date ingested:** <today>
**Type:** <paper | article | transcript | code | other>
## Summary
<2-3 paragraph synthesis — your own words, not abstract copy-paste>
## Key Takeaways
- <bullet>
## Entities & Concepts
<list of entities/concepts as cross-reference links — emit each in the wiki's link_style; see config/link-style.md>
## Relation to Other Wiki Pages
<how this connects to or updates existing knowledge>5b. Cite as you write — do not skip
While drafting the Summary, Key Takeaways, and any other prose section, every
non-common-knowledge factual claim must carry a footnote. Read the Citations
section in SCHEMA.md for the full convention.
Two citation kinds, three valid targets:
Quote: [^N]: <target> <locator> — "<verbatim quote>"
Synthesis: [^N]: <target> <locator> [synthesis] — <what supports the claim>
<target> is one of:
<slug-reference> — a source wiki page, written in the wiki's link_style
(preferred for the source you're ingesting)
raw/<file> — a path, for drive-by citations to other local files
<URL> — a live URL or postFor the source being ingested, the slug-reference target is <this-source-slug> written in the form prescribed by config/link-style.md. wiki-ingest is creating that page now, so the target exists by the time the page is read.
Line-range provenance — required for text-addressable sources. If the raw file
you are citing is markdown, plaintext, code, or cached HTML, every footnote to it must
carry a line-range token after the semantic locator: L<start>-<end> (or L<n> for a
single line). As you read the raw file, note the line numbers of the passage you are
citing — for a quote, the lines the quote is taken from; for a [synthesis] claim, the
block of lines being summarized. Example:
[^1]: [[<this-source-slug>]] §3.2 L142-143 — "We employ h = 8 parallel attention layers"
[^2]: [[<this-source-slug>]] §3.2-5.3 [synthesis] L138-202 — encoder/decoder + attention describe the architectureSources WITHOUT stable line numbers — PDFs, transcripts, and live URLs with no local
cached copy — are exempt: keep the semantic locator (p.N, [HH:MM:SS], URL anchor)
and omit L….
If you cannot produce either citation kind for a claim, you do not have a citation. Find one, weaken the claim ("the paper suggests..."), or drop it.
Footnotes go at the bottom of the page, below all sections. Number them sequentially in order of first reference.
5c. Self-check before continuing
Re-read the draft once. Three passes:
- Unfootnoted claims — scan for factual claims with no footnote (the most common failure mode in long ingest sessions). For each, add a footnote or revise the wording.
- Missing line-ranges — for every footnote whose target is a text-addressable raw
file (markdown / plaintext / code / cached HTML), confirm an
L…token is present. A text-source footnote with no line-range is incomplete: go back to the raw file, find the lines, and add the token. Exempt sources (PDF / transcript / live URL) are fine without one. - Link resolution — collect every
[[slug]]you wrote in this page and confirm each resolves to an existingwiki/pages/<slug>.mdor to a page you are creating in this same ingest. See the Concept Identity rule inSCHEMA.md. Any[[slug]]that resolves to neither is a hallucinated link: remove it, or create the page it points to. This is the inline version of the broken-link checkwiki-lintruns wiki-wide — catching it now keeps the link graph trustworthy by construction.
Only when all three passes are clean do you move on to entity pages.
6. Update entity and concept pages
For each entity/concept touched by this source:
- Page exists: Read it, add to or update the relevant section, add this source to frontmatter
sourceslist, updateupdateddate - Page doesn't exist: Create it:
---
title: <Entity or Concept Name>
category: <one of the wiki's Index Categories — e.g. Entities or Concepts>
summary: <one-line description for the index>
tags: [entity | concept]
sources: [<this-source-slug>]
created: <today>
updated: <today>
---
# <Name>
## Description
<synthesis across all sources that discuss this>
## Appearances in Sources
- <slug-reference to source-slug, in the wiki's link_style> — <one-line note>
## Related Concepts
- <slug-reference to related-slug, in the wiki's link_style> — <relationship>7. Backlink audit — do not skip
Scan ALL existing pages in wiki/pages/ for any that mention this source's entities/concepts but don't yet link to the new page. Use the ## Parse regex from config/link-style.md to detect existing references. Add new cross-references to the new page using the ## Emit form from the same file.
This is the step most commonly skipped. A compounding wiki's value comes from bidirectional links.
Before adding each [[slug]], apply the Concept Identity rule: the target must
resolve to a real page. When you mention an entity that should have a page but doesn't,
create the page (step 6) rather than linking to a slug that resolves to nothing.
Final link-resolution sweep. Once every page this ingest touched is written
(summary, entity/concept pages, backlinks), collect all [[slug]] references across
those pages and confirm each resolves to an existing wiki/pages/<slug>.md. This
extends the step 5c check to the links written after it. Fix any unresolved link before
moving on — remove it or create its page.
7b. Contradiction check — do not skip
Now that every page this ingest touched is written and you have its neighbors in context,
check for contradictions before committing. Read the Contradiction Check section in
SCHEMA.md for the full convention. This is a gate, not an annotation: a clean ingest
leaves no contradiction metadata on any page.
Scope — what to compare (do NOT re-read the whole wiki):
- each page you wrote/edited against itself (internal contradictions), and
- each page you wrote/edited against the pages you already read this ingest — the entity/concept pages from step 6 and the neighbor pages from the step 7 backlink audit.
A conflict with some distant page you never opened is out of scope here — the periodic
wiki-lint sweep is the backstop for that.
Classify each contradiction you find:
Blocking — a real factual conflict on the same entity under the same scope: incompatible dates, counts, names, or mutually-exclusive claims (e.g. the new source page says a model launched in 2024 but
[[that-model]]already says 2023). For each blocking contradiction, write a single line into the affected page's frontmatter — the page you touched that carries the newer claim:contradiction-check: failed — launch year conflicts with [[that-model]] (2024 vs 2023)Use
internalin place of the[[slug]]for a within-page conflict. Then stop — do not proceed to the commit step (step 10). Surface the conflict (both claims, both locations) and offer the user these resolutions:- correct the newly-written page,
- correct the counterpart page,
- reconcile both with a scope qualifier,
- or confirm it is not actually a conflict (it was a soft tension — see below).
When a conflict is resolved, remove the
contradiction-checkline from the page. Only once nocontradiction-check: failedline remains on any touched page do you continue.- Soft — a tension that is not a true conflict: differing emphasis, values within
plausible version/measurement variance, or claims that hold under different scope. Do
not write anything to any page and do not block. Note it for the step 11 summary
so the user can act if they wish; the periodic
wiki-lintsweep is the backstop.
8. Regenerate wiki/index.md
Do not hand-edit the index. Every page you wrote this ingest already carries
category, summary, and created in its frontmatter — that is the index's source of
truth. Regenerate it:
python bin/generate-index.pyThe new source, entity, and concept pages now appear under their categories
automatically. If the generator warns about a page with no frontmatter or a page lands in
Uncategorized, fix that page's frontmatter and rerun.
9. Update wiki/overview.md
Re-read the current overview. If this source:
- Introduces a significant concept: add it to "Key Entities / Concepts"
- Shifts the overall understanding: update "Current Understanding"
- Raises a new question: add it to "Open Questions"
Update the frontmatter updated date.
10. Record the operation
Gate first: do not suggest a commit while any page touched this ingest still carries a
contradiction-check: failed line (step 7b). Resolve the blocking contradiction and remove
the line first — committed pages are always clean.
Per SCHEMA's Operation Log & Commit Convention:
- Git wiki: stage the wiki changes and suggest a commit (subject follows the repo's
convention — default Conventional Commits
docs:for an ingest — plus the trailer). Commit on the user's confirmation; never auto-commit.docs: summarize <source title> Wiki-Op: ingest - Non-git wiki: append to
wiki/log.md:## [<today>] ingest | <source title> Pages written: <slug> Pages updated: <comma-separated list>
Common Mistakes
- Appending chronological updates instead of editing in-place — Wiki pages are living documents, not journals. Do not add sections like
## April 27 update:or**Update:**followed by new content. Update the relevant section in-place, bump theupdatedfrontmatter date, and record what changed in the operation log (a commit on a git wiki, orlog.mdotherwise). The log is the historical record; pages are the current truth. - Skipping the backlink audit (step 7) — A wiki's value compounds through bidirectional links. Always scan existing pages for entities this source introduces.
- Inventing
[[slug]]links — Never write a cross-reference to a slug you have not confirmed exists or are creating now. A link that resolves to nothing is a hallucinated link. Verify against the existing page set (ls wiki/pages/); see the Concept Identity rule inSCHEMA.md. - Summarizing the abstract instead of synthesizing — The Summary section should reflect your own synthesis, not a rephrased abstract.
11. Report to user
- Summary page:
wiki/pages/<slug>.md - Entity/concept pages created or updated:
<list> - Pages that received backlinks:
<list> - Index and overview updated
- Soft tensions noted (step 7b): <list any non-blocking tensions, or "none"> — not recorded on any page; act on them if you want
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

