research-wiki
Persistent research knowledge base that accumulates papers, ideas, experiments, claims, and their relationships across the entire research lifecycle. Inspired by Karpathy's LLM Wiki pattern. Use when user says "知识库", "research wiki", "add paper", "wiki query", "查知识库", or wants to build/query a persi
By wanshuiyin · 376 installs
npx skills add wanshuiyin/auto-claude-code-research-in-sleep --skill research-wiki
Source repository · Upstream listing
Research Wiki: Persistent Research Knowledge Base
Subcommand: $ARGUMENTS
Overview
The research wiki is a persistent, per project knowledge base that accumulates structured knowledge across the entire ARIS research lifecycle. Unlike one off literature surveys that are used and forgotten, the wiki compounds — every paper read, idea tested, experiment run, and review received makes the wiki smarter.
Inspired by [Karpathy's LLM Wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f): compile knowledge once, keep it current, don't re derive on every query.
Core Concepts
Four Entity Types
Entity Directory Node ID format What it represents
Paper papers/ paper:<slug A published or preprint research paper
Idea ideas/ idea:<id A research idea (proposed, tested, or failed)
Experiment experiments/ exp:<id A concrete experiment run with results
Claim claims/ claim:<id A theorem/headline with an honest PROOF status — born via /proof checker (see Hook 4)
Typed Relationships ( graph/edges.jsonl )
Edge type From → To Meaning
extends paper → paper Builds on prior work
contradicts paper → paper Disagrees with results/claims
addresses gap paper\ idea → gap Targets a known field gap
inspired by idea → paper Idea sourced from this paper
tested by idea\ claim → exp Tested in this experiment
supports exp → claim\ idea Experiment confirms claim
invalidates exp → claim\ idea Experiment disproves claim
supersedes paper → paper Newer work replaces older
Edges are stored in graph/edges.jsonl only. The Connections section on each page is auto generated from the graph — never hand edit it.
Capture hygiene (anti self poisoning)
Before persisting an idea / claim / experiment note, screen it for
operational noise that would harden into a self cited falsehood (see
[ shared references/capture antipatterns.md ](../shared references/capture antipatterns.md)).
Resolve the helper via the canonical chain (integration contract §2):
.aris/tools/capture filter.py → tools/capture filter.py →
$ARIS REPO/tools/capture filter.py (warn and skip if unresolved). Run
python3 <capture filter on the note text; if it flags env failure /
transient error / negative tool claim , do NOT store it as a durable node —
rewrite it to the fix / missing config / workaround , or drop it. Never store
"codex/gemini/the reviewer can't do X" — that gets loaded into every future
session and cited against the agent long after the real cause is gone. (The wiki's
"failed ideas → anti repeat memory" is the GOOD inverse: a class level research
finding, not operational noise.)
Wiki Directory Structure
Subcommands
Helper resolution (run before any subcommand below)
All wiki operations except plain directory bootstrap go through a single
canonical helper, tools/research wiki.py . Skills that touch the wiki
must resolve $WIKI SCRIPT via the chain below — never hard code
python3 tools/research wiki.py … . Hard coding silently fails when
the project does not have tools/ on disk (the post install aris.sh
default), which is exactly the failure mode that left a real user's
research wiki/ empty for a week.
/research wiki itself is the wiki tool — if the helper is missing the
skill hard fails . Caller skills that update the wiki as a side
effect ( /idea creator , /result to claim , /research lit , /arxiv ,
/alphaxiv , /deepxiv , /semantic scholar , /exa search ) use the
same chain but warn and skip instead of hard failing — their
primary output (idea list, claim verdict, paper summary) must still be
delivered to the user.
/research wiki init
Initialize the wiki for the current project. After resolving
$WIKI SCRIPT per the chain above:
The helper creates research wiki/{papers,ideas,experiments,claims,graph}/
plus index.md , log.md , gap map.md , query pack.md , and
graph/edges.jsonl , then appends "Wiki initialized" to log.md .
(Earlier versions of this skill described a prose only init that
omitted query pack.md — that drifted from the helper and made
/idea creator 's Phase 0 query pack check fall through to a
rebuild query pack invocation that, under the old hard coded path,
silently failed. Delegating init to the helper is the single source of
truth for the wiki schema.)
/research wiki ingest "<paper title " — arxiv: <id
Add a paper to the wiki. This subcommand is thin wrapping around
python3 "$WIKI SCRIPT" ingest paper … , which is the single
implementation of paper ingest in ARIS (per
[ shared references/integration contract.md ](../shared references/integration contract.md)
— one helper, no copies). The helper does all of:
1. Fetch metadata — queries the arXiv Atom API when arxiv id is given
2. Generate slug — <first author last name <year <keyword
3. Check dedup — skip an existing page unless update on exist
4. Create page — papers/<slug .md with the schema below
5. Rebuild index.md and query pack.md
6. Append log.md
Edge extraction (step 5/8 in the old manual flow) is not in
ingest paper ; do it as a follow up with add edge per relationship
identified:
Other skills ( /research lit , /arxiv , /alphaxiv , /deepxiv ,
/semantic scholar , /exa search ) call the same helper directly in
their own last step — they don't re route through /research wiki
ingest as a subcommand, so they don't need an LLM roundtrip.
/research wiki sync — arxiv ids <id1 ,<id2 ,...
Batch backfill: ingest one or more arXiv IDs that were read earlier
without being ingested (e.g., because research wiki/ was set up after
the reading happened, or a hook didn't fire).
Dedup is handled per id; already ingested papers are skipped silently.
This is the recommended manual repair step (see integration
contract §5 Backfill). sync does not scan session traces — callers
declare the ids explicitly.
Paper page schema (exactly what ingest paper emits — do not
handwrite alternative fields; lint will flag drift):
Additionally, when the paper was ingested via arxiv id and the arXiv
API returned an abstract, the helper appends an Abstract (original)
section after Relevance to This Project containing the raw abstract
text as a blockquote. Manual ingests (no arxiv id ) do not include
this section.
/research wiki query "<topic "
Generate query pack.md — a compressed, context window friendly summary:
Fixed budget (max 8000 chars / ~2000 tokens):
Section Budget Content
Project direction full sections Structured extraction from RESEARCH BRIEF.md by heading (Problem / Constraints / Direction / Background / Non Goals / Domain Knowledge / Existing Results), in priority order. No per field char cap — the 8000 char assembly loop is the only safety net. Falls back to a flat 600 char slice if the brief uses no known headings.
Top 5 gaps 1200 chars From gap map.md, ranked by: unresolved + linked ideas + failed experiments
Paper clusters 1600 chars 3 5 clusters by tag overlap, 2 3 sentences each
Failed ideas 1400 chars Always included — highest anti repetition value
Top papers 1800 chars 8 12 pages ranked by: linked gaps, linked ideas, centrality, relevance flag
Active chains 900 chars limitation → opportunity relationship chains
Open unknowns 500 chars Unresolved questions across the wiki
Pruning priority (when over budget): low ranked papers cluster detail chain detail. Never prune failed ideas or top gaps first.
Key rule: Read from short fields only (frontmatter, one line thesis, gap summary, failure note). Do not summarize full page bodies every time.
/research wiki update <node id — <field : <value
Update a specific entity:
After any update: rebuild query pack.md , update log.md .
/research wiki lint
Health check the wiki:
1. Orphan pages — entities with zero edges
2. Stale claims — claims still status: drafted or status: unproven older than 14 days
3. Contradictions — claims with both supports and invalidates edges
4. Missing connections — papers sharing 2+ tags but no explicit relationship
5. Dead ideas — stage: proposed ideas that were never tested
6. Sparse pages — pages with 3+ empty sections
Output a LINT REPORT.md with suggested fixes.
/research wiki stats
Quick overview:
Integration with Existing Workflows
All paper reading skills follow the same integration contract (see
[ shared references/integration contract.md ](../shared references/integration contract.md)):
single predicate — [ d research wiki/ ]
single canonical helper — python3 "$WIKI SCRIPT" ingest paper … after resolving $WIKI SCRIPT via the chain at the top of this SKILL
concrete artifact — papers/<slug .md + log.md entry
backfill — sync arxiv ids …
diagnostic — verify wiki coverage.sh (Policy E; resolved per integration contract §2)
Hook 1: After /research lit finds papers
Each paper reading skill ships its own Step "Update Research Wiki (if
active)" that calls the same helper once per paper it touched. The
business logic is not duplicated — only the loop over that skill's
specific result set differs.
Hook 2: /idea creator reads AND writes wiki
Before ideation:
After ideation (CRITICAL — without it, ideas/ stays empty; runs on EVERY
generation, including a re run with updated constraints): the page write is a
deterministic helper command , not a freehand step the model can skip:
Hook 3: After /result to claim verdict
Hook 4: Claim birth — from /proof checker (the ONLY birth point)
Wiki claim nodes are born here. /proof checker Phase 5.5 calls add claim
for each top level theorem/headline after writing PROOF AUDIT.json , stamping an
honest PROOF axis status and a provenance pointer to the audit trace. No other
skill creates a claim node: /result to claim (Hook 3) only adds empirical
supports / invalidates edges to an already born claim and never edits its status .
Claim status ∈ { drafted , unproven , sound modulo imports , verified ,
refuted , retracted } — the proof axis only . Empirical support is a separate
axis, carried entirely by edges (Hook 3), never written into status .
Re ideation Trigger
After significant wiki updates, suggest re running /idea creator :
≥5 new papers ingested since last ideation
≥3 new failed/partial ideas since last ideation
New contradiction discovered in the graph
New gap identified that no existing idea addresses
The system suggests but does not auto trigger. User decides.
Key Rules
One source of truth for relationships : graph/edges.jsonl . Page Connections sections are auto generated views.
Canonical node IDs everywhere : paper:<slug , idea:<id , exp:<id , claim:<id , gap:<id . Never use raw titles or inconsistent shorthands.
Failed ideas are the most valuable memory. Never prune them from query pack.
query pack.md is hard budgeted at 8000 chars. Deterministic generation, not open ended summarization.
Append to log.md for every mutation. The log is the audit trail.
Reviewer independence applies. When the wiki is read by cross model review skills, pass file paths only — do not summarize wiki content for the reviewer.
The wiki is UTF 8. All wiki files are read and written as UTF 8 so a research wiki/ stays portable across platforms and collaborators. A wiki created by an older ARIS on a non UTF 8 locale (e.g. cp936 on Chinese Windows) must be converted to UTF 8 once — back it up first; the helper reports the offending file by name instead of guessing.
Acknowledgements
Inspired by [Karpathy's LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) — "compile knowledge once, keep it current,