agentleFS
matcommatcom/ai-skills/skills/ingest/SKILL.md

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

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.
  • LambenthanSkill

    daily-arxiv

    每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新

    Also in 5 projects that use this

  • LambenthanSkill

    exp-eval

    实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

    Also in 5 projects that use this

  • phanghonghaoSkill

    poster

    HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.

    Also in 5 projects that use this

  • skyllwtSkill

    exp-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

  • skyllwtSkill

    exp-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

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
  1. Very specific:

    Read one or more files from ./sources/ and compile them into structured, cross-linked pages in ./wiki/, following natural-language guidance …

    line 16
  2. Distinctive:

    If any of the three is ambiguous beyond reasonable inference, STOP and ask one clarifying question before proceeding.

    line 68
  3. Distinctive:

    STOP and ask one clarifying question before proceeding.

    line 69
  4. Very specific:

    Write only inside ./wiki/: Read anywhere. Never modify sources — they are authoritative raw material.

    line 74
  5. Very specific:

    If the file already exists, UPDATE it (do not duplicate).

    line 85
  6. Distinctive:

    When focus is narrowed (e.g., "focusing on training tricks"), the summary floor is waived — no source-summaries unless they are part of the …

    line 90
  7. Distinctive:

    Existing pages may be freely re-written: When new sources introduce new claims about an existing concept page, merge those claims in.

    line 136
  8. Distinctive:

    If guidance is empty or unintelligible → ask for guidance, do nothing.

    line 165
  9. Distinctive:

    If scope resolves to zero sources → report empty result, do nothing.

    line 167
  10. Distinctive:

    If scope resolves to more than 10 sources → list candidates, ask to trim.

    line 169
  11. Distinctive:

    If a source file cannot be read → report the failure, ingest the rest.

    line 171
  12. Very specific:

    If about to write a file whose path is NOT under ./wiki/ → STOP.

    line 173
  13. Distinctive:

    STOP. That is an error.

    line 174
  14. Very specific:

    If the user asks to modify sources or write outside ./wiki/ → refuse and explain the read-only contract on sources.

    line 175
  15. Distinctive:

    No focus narrowing. Ontology: agent-chosen from content."

    line 187

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md and sources/papers/bar.md, one page per evaluation benchmark"

Parse the guidance to determine three things:

  1. Scope — which source files to read. Resolve explicit paths directly. For topic references ("about X"), grep within ./sources/ (body text + frontmatter tags:, title:, topic: fields). For time windows ("since YYYY-MM-DD" or "yesterday"), filter by frontmatter date: or filename date prefix. If the resolved set has more than 10 files, STOP, list candidates, and ask the user to trim before proceeding.
  2. 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.
  3. 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:

  1. 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 to ingestion_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.

  2. Synthesis pages — free-shape, produced as the content warrants. Flat in ./wiki/ (no subfolders). Filenames are slugs from page titles (lowercase, hyphen-separated). The kind: 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, use source-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

  1. Parse the guidance — determine scope, focus, ontology. If scope resolves to more than 10 files, list candidates and stop.
  2. Read the sources — full body + frontmatter. Note source_type, title, date, any arxiv / DOI identifiers.
  3. Read the existing wiki — at minimum ls ./wiki/ to know what exists. Read any page about to be touched or cross-referenced.
  4. 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.
  5. 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.
  6. 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.md

Response shape:

  1. "Parsed scope: single file sources/2026-04-20-new-llm-paper.md. No focus narrowing. Ontology: agent-chosen from content."
  2. "Reading the source … identified 4 concepts: mixture-of-depths, dynamic routing, conditional compute, expert-choice."
  3. "Existing wiki pages: [[mixture-of-experts]] is relevant and will be updated."
  4. "Plan: 1 source-summary, 3 new synthesis pages, 1 updated synthesis page."
  5. Write files.
  6. "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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.