agentleFS
Sign inStart free
nikserburnikserbur/autolearn/skills/knowledge-ingest/SKILL.md

knowledge-ingest

Skill0 starsChanged 5 days agoMITView on GitHub

Builds the local knowledge base for retrieval (RAG) together with its curated router. Use when the user says "remember this", "add to the knowledge base", "build a page for this repo", after reading docs, wiki pages, code or tickets that will matter again, after a research round whose conclusions matter beyond its project, or when knowledge-search reported a miss. Distills sources into chunk-friendly topic and project pages with a source on every fact, registers them in the topic map with keywords and section pointers, embeds the new chunks into the vector store, keeps every file inside its size budget, and commits.

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. QuixiAI/agi-memory★ 623same name
    2. QuixiAI/Hexis★ 623same name
    3. EvolutionAPI/evo-nexus★ 545same name
    4. evolution-foundation/evo-nexus★ 535same name

    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 repository4 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every fact is one line ending with its source: (src: <url or path:line> ✅).

    line 32
  2. Very specific:

    Write for retrieval: one subject per ##/### section, a specific heading with the words a question would use, sections short enough to stand …

    line 33
  3. Distinctive:

    Do not copy long passages.

    line 35
  4. Distinctive:

    Never store secrets, credentials or personal data.

    line 43
  5. Very specific:

    Every chunk is indexed with its page's title and summary, so give a page a specific title and, if its first sentence does not say what it …

    line 70
  6. Very specific:

    Run python3 "${CLAUDE_SKILL_DIR}/scripts/kb_lint.py".

    line 77
  7. Very specific:

    If KB is a git repository: git -C KB add -A && git -C KB commit -m "kb: <topic> (+N facts)".

    line 82
  8. Very specific:

    If .router-log.tsv shows misses this ingest closes, say which.

    line 84

“Common” is measured: kept by at least 6 in 10 of the 4 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

knowledge-ingest - every page it writes is retrievable from day one

Target: ~/.claude/research-lab/knowledge/ (below: KB). Layout and the topic-block format are described in the knowledge-search skill. The rule of this skill: no page without a router entry, no router entry without a page or a source.

Argument: $ARGUMENTS

  • repo (or empty inside a git repo without a project page) -> build KB/projects/<repo>.md.
  • a URL or path -> distill that source into the matching topic.
  • a topic name -> collect what this conversation established about it.
  • a research folder -> promote the durable conclusions of its KB/KNOWLEDGE.md (not the journal) into topic pages, each fact pointing back to the experiment or review.

1. Read (cheaply)

  • Small source (< ~30 KB): read it directly.
  • Large source, many pages, or a whole repo: delegate to a subagent (Explore) with the question "what will someone need to know again?" and take back facts with citations. Do not pull the whole thing into the main context.
  • Pages the map marks ⛔: do not crawl them; record the link only.
  • Web sources, dates, cross-checks and what wins a disagreement: SOURCES.md.

2. Distill into the page

Topic page KB/topics/<slug>.md, sections in this order (skip empty ones): ## Summary (3-5 lines) · ## Facts · ## How to · ## Pitfalls · ## Contradictions · ## Open questions · ## Sources.

  • Every fact is one line ending with its source: (src: <url or path:line> ✅).
  • Write for retrieval: one subject per ##/### section, a specific heading with the words a question would use, sections short enough to stand alone as a chunk (~1.5 KB).
  • Do not copy long passages; restate in your own words, quote at most a short phrase.
  • Contradicting sources: keep both, say which one wins and why (code > ADR > docs > wiki > chat).
  • Say what a section is when it is not a plain sourced fact, on a line under its heading: kind: measurement · scope: ES Q3 2026, spread 0.25 · date: 2026-11-07 (kinds: measurement, conclusion, conjecture, expectation, snippet). A fact that turns out wrong or is replaced is not deleted: its section gets status: superseded · supersedes: <old heading> or status: invalid with the reason, so search leaves it out but the history stays. Promoted research facts carry the kind and scope of the research they came from.
  • Never store secrets, credentials or personal data. Sensitive pages: store a pointer and the note "restricted, ask the owner".

Project page KB/projects/<repo>.md (from the repo's README, CLAUDE.md, CONTRIBUTING, docs/, build files and CI config): ## Purpose · ## Layout (entry points with paths) · ## Commands (exact build / test / lint lines) · ## Conventions (with the source file) · ## Decisions (ADRs, links) · ## Pitfalls · ## Sources.

3. Register in the router (same step, not later)

In KB/topic-map.md, create or extend the topic block:

  • keywords: everything a future question might contain: synonyms, the user's language, module and file names, issue key prefixes, abbreviations.
  • read first: file#section pointers to the exact sections, most useful first.
  • sources: with status marks ✅ / 🔎 / ⛔.
  • updated: today. A project page is also registered as a topic block (## Project: <repo>).

4. Budgets (keep the router fast)

FileBudgetWhen exceeded
topic block in the map<= 8 linessplit the topic
topic-map.md<= 25 KBmove topics into KB/map/<area>.md and leave one block per area in the top map (hierarchical routing)
topic page<= 40 KBsplit into subtopic pages, each with its own block
project page<= 15 KBmove details into topic pages, keep pointers

5. Write for retrieval

Every chunk is indexed with its page's title and summary, so give a page a specific title and, if its first sentence does not say what it is about, a summary: ... line near the top. State relations plainly ("billing-api depends on Kafka", "X replaces Y"): the entity graph reads these sentences and answers "what breaks if Kafka goes down" from them. Keep periods in the title or headings ("Q3 2026"): questions about a period filter on them.

6. Lint, index, commit, report

Run python3 "${CLAUDE_SKILL_DIR}/scripts/kb_lint.py". The kb_autoindex hook has already embedded the new chunks; without hooks run python3 "${CLAUDE_SKILL_DIR}/../knowledge-search/scripts/kb_rag.py" index. Fix every ERROR (broken pointer, unroutable page, block without keywords) before committing; act on WARN budgets as the table above says. If KB is a git repository: git -C KB add -A && git -C KB commit -m "kb: <topic> (+N facts)". Report in two lines: what was added (pages, facts, keywords) and the new router keywords. If .router-log.tsv shows misses this ingest closes, say which.

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.

Check your setup, free