ingest
Skill14 starsChanged 5 months agoMITView on GitHub
Use when the user wants to compile a set of pulled sources into a structured, cross-linked wiki. Natural triggers: "/ingest", "compile these papers into a wiki", "synthesize my sources", "ingest the X papers focusing on Y", "build me a wiki page per method from these papers". Distinct from /pull (fetches sources) and /sota (produces a state-of-the-art review). Input: a folder of Markdown sources (typically `./sources/`). Output: cross-linked pages in `./wiki/` with per-source summaries and synthesis pages.
88 other projects use a version of this.
Adopted by
Most recently taken up by
- zaynram/scholartheir own version, first seen Nov 8, 2026
- silouone/skillstheir own version, first seen Nov 8, 2026
- hydra-db/hydradb-claude-codetheir own version, first seen Nov 8, 2026
- fjwood69/moritheir own version, first seen Nov 8, 2026
- zedarvates/frugal-skillstheir own version, first seen Nov 8, 2026
- Mharbulous/probanda-devtheir own version, first seen Nov 8, 2026
Used with
Projects with it also use daily-arxiv, exp-eval and 10 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.
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
phanghonghaoSkillposter
HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.
Also in 5 projects that use this
skyllwtSkillexp-pilot-eval
Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.
Also in 4 projects that use this
skyllwtSkillexp-pilot-run
Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.
Also in 4 projects that use this
- +6 more from Lambenthan
- +1 more from skyllwt
Other versions88 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 88
- garrytan/gbrain★ 32ksame name
- skyllwt/OmegaWiki★ 1.7ksame name
- DAIR-AutoResearch/AutoSci★ 1.7ksame name
- PKU-DAIR/AutoSci★ 1.7ksame name
- skyllwt/AutoSci★ 1.7ksame name
- suboss87/FDEOps★ 940same name
- coreyhaines31/makerskills★ 893same name
- jason-effi-lab/karpathy-llm-wiki-vault★ 718same name
- ZimoLiao/scholaraio★ 585same name
- egregore-labs/egregore★ 293same name
78 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.
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 10 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 72 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Read one or more files from ./sources/ and compile them into structured, cross-linked pages in ./wiki/, following natural-language guidance …
- Distinctive: line 68
If any of the three is ambiguous beyond reasonable inference, STOP and ask one clarifying question before proceeding.
- Distinctive: line 69
STOP and ask one clarifying question before proceeding.
- Very specific: line 74
Write only inside
./wiki/: Read anywhere. Never modify sources — they are authoritative raw material. - Very specific: line 85
If the file already exists, UPDATE it (do not duplicate).
- Distinctive: line 90
When focus is narrowed (e.g., "focusing on training tricks"), the summary floor is waived — no source-summaries unless they are part of the …
- Distinctive: line 136
Existing pages may be freely re-written: When new sources introduce new claims about an existing concept page, merge those claims in.
- Distinctive: line 165
If guidance is empty or unintelligible → ask for guidance, do nothing.
- Distinctive: line 167
If scope resolves to zero sources → report empty result, do nothing.
- Distinctive: line 169
If scope resolves to more than 10 sources → list candidates, ask to trim.
- Distinctive: line 171
If a source file cannot be read → report the failure, ingest the rest.
- Very specific: line 173
If about to write a file whose path is NOT under ./wiki/ → STOP.
- Distinctive: line 174
STOP. That is an error.
- Very specific: line 175
If the user asks to modify sources or write outside ./wiki/ → refuse and explain the read-only contract on sources.
- Distinctive: line 187
No focus narrowing. Ontology: agent-chosen from content."
“Common” is measured: kept by at least 6 in 10 of the 72 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
ingest
Read one or more files from ./sources/ and compile them into
structured, cross-linked pages in ./wiki/, following natural-language
guidance from the user.
When to use
- The user has accumulated several pulled sources and wants them digested into a navigable wiki.
- A research / writing task needs the corpus organized by concept / method / debate / entity rather than by raw source.
- The user names a focus or ontology for the synthesis ("one page per evaluation benchmark", "focusing on training tricks").
When NOT to use
- The user wants atomic claims as Zettelkasten notes → that's
/distill. - The user wants a state-of-the-art chapter draft → that's
/sota. - The user wants to audit a written document → that's
/review. - The corpus has fewer than 3 sources — ingest is overkill; suggest reading the sources directly.
Input format
The user passes natural-language guidance. Examples:
- "the paper at
sources/2026-04-20-foo.md" - "everything I pulled since 2026-04-15 about transformers"
- "the three mixture-of-experts papers, focusing on training tricks"
- "
sources/papers/foo.mdandsources/papers/bar.md, one page per evaluation benchmark"
Parse the guidance to determine three things:
- Scope — which source files to read. Resolve explicit paths
directly. For topic references ("about X"), grep within
./sources/(body text + frontmattertags:,title:,topic:fields). For time windows ("since YYYY-MM-DD" or "yesterday"), filter by frontmatterdate:or filename date prefix. If the resolved set has more than 10 files, STOP, list candidates, and ask the user to trim before proceeding. - Focus — the angle to extract. If the guidance includes phrases like "focusing on", "just the X", "extract the Y", narrow the synthesis to that angle. Absence of narrowing means extract broadly.
- Ontology — the shape of output pages. If the guidance includes phrases like "one page per X", "by X", "grouped by X", constrain output shape. Absence means choose ontology from content.
If any of the three is ambiguous beyond reasonable inference, STOP and ask one clarifying question before proceeding. Do not invent scope.
Contract
Write only inside ./wiki/. Read anywhere. Never modify
sources — they are authoritative raw material.
Two kinds of output pages:
Per-source summaries — produced only when the source has artifact identity (a paper, book, talk, canonical article — signals: arxiv ID / DOI / ISBN / author list in frontmatter, or the source is clearly a bounded artifact). One file per such source at
./wiki/sources/<source-slug>.md, where<source-slug>matches the source filename without extension. If the file already exists, UPDATE it (do not duplicate); append today's timestamp toingestion_runs:and refresh the body as needed. Skip the summary entirely if the source is a random webpage, pasted markdown, or otherwise non-artifact.When focus is narrowed (e.g., "focusing on training tricks"), the summary floor is waived — no source-summaries unless they are part of the focus.
- Synthesis pages — free-shape, produced as the content
warrants. Flat in
./wiki/(no subfolders). Filenames are slugs from page titles (lowercase, hyphen-separated). Thekind:frontmatter field distinguishes page types (entity,concept,method,debate,timeline, or any other value the material calls for).
Every page carries this frontmatter, always:
---
kind: <entity|concept|method|debate|timeline|source-summary|...>
sources: ["[[source-slug-1]]", "[[source-slug-2]]"]
created: YYYY-MM-DD
updated: YYYY-MM-DD
ingestion_runs: ["YYYY-MM-DDTHH:MM", ...]
---kind— mandatory. For source-summaries, usesource-summary. For synthesis pages, pick from the canonical set or invent as needed.sources— list of wikilinks to the source files this page draws from. For source-summaries, a single source. For synthesis pages, every source that contributed.created— today's date if new; preserve existing value if updating.updated— today's date, always.ingestion_runs— append today's ISO timestamp (YYYY-MM-DDTHH:MM) to the existing list; if new page, start fresh.
Additional frontmatter fields (aliases, tags, etc.) are
permitted when useful.
Cross-link freely. Wiki pages link to other Wiki pages via
[[other-page]]. Source citations live in the sources:
frontmatter, NOT in body wikilinks (sources are metadata, not
graph edges). Source-summary pages live at
./wiki/sources/<slug>.md; to reference one in prose, use
[[sources/<slug>]].
Existing pages may be freely re-written. When new sources introduce new claims about an existing concept page, merge those claims in; split pages that have grown too large; merge overlapping pages. The whole wiki is regenerable. Do not be conservative about touching existing pages — the compounding value of the wiki depends on re-synthesis.
Process
- Parse the guidance — determine scope, focus, ontology. If scope resolves to more than 10 files, list candidates and stop.
- Read the sources — full body + frontmatter. Note
source_type,title,date, any arxiv / DOI identifiers. - Read the existing wiki — at minimum
ls ./wiki/to know what exists. Read any page about to be touched or cross-referenced. - Plan the page deltas — decide: which source-summaries to write (respecting the artifact + focus rules), which synthesis pages to create, which existing pages to update. Briefly narrate the plan in your response so the user can interrupt if the ontology is wrong.
- Write the pages — produce frontmatter + body for each. Be
concrete and cite sources — every factual claim should trace
to a source in the
sources:list. - Report — tell the user what was parsed (scope / focus / ontology) and what was written (page deltas with paths).
Refusals and stops
- If guidance is empty or unintelligible → ask for guidance, do nothing.
- If scope resolves to zero sources → report empty result, do nothing.
- If scope resolves to more than 10 sources → list candidates, ask to trim.
- If a source file cannot be read → report the failure, ingest the rest.
- If about to write a file whose path is NOT under
./wiki/→ STOP. That is an error. - If the user asks to modify sources or write outside
./wiki/→ refuse and explain the read-only contract on sources.
Example invocation
/ingest the paper at sources/2026-04-20-new-llm-paper.mdResponse shape:
- "Parsed scope: single file
sources/2026-04-20-new-llm-paper.md. No focus narrowing. Ontology: agent-chosen from content." - "Reading the source … identified 4 concepts: mixture-of-depths, dynamic routing, conditional compute, expert-choice."
- "Existing wiki pages:
[[mixture-of-experts]]is relevant and will be updated." - "Plan: 1 source-summary, 3 new synthesis pages, 1 updated synthesis page."
- Write files.
- "Done. New:
[[mixture-of-depths]],[[dynamic-routing]],[[conditional-compute]]. Updated:[[mixture-of-experts]]. Summary:[[sources/2026-04-20-new-llm-paper]]."
Anti-patterns
- ❌ Hand-writing prose in a source-summary that contradicts the source. Summaries are extracts, not editorials.
- ❌ Inventing wikilinks to non-existent pages. Either create the target page in the same run, or use plain text.
- ❌ Promoting a wiki synthesis page to canonical / evergreen status. Synthesis pages are regenerable; canonical knowledge lives elsewhere by user convention.
- ❌ Writing the same content to multiple pages. Each claim has one canonical home, with cross-links from elsewhere.
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.

