discover
Skill1.7k starsChanged 34 days agoMITView on GitHub
Build a ranked shortlist of candidate papers (anchor-driven, topic-driven, or derived from current wiki state) that the user — or an upstream skill — may decide to feed into `/ingest`. Use whenever the user asks "what should I read next", "find papers similar to this one", "recommend related work", "what's around this topic", or whenever `/ingest` is invoked with `--discover`. Does not ingest; only proposes.
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 39 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use these local references on demand:
- Very specific: line 76
If the user supplied negatives ("not these"), include them via --negative in anchor mode only.
- Very specific: line 146
Ranking is discovery-specific: do not import or duplicate tools/init_discovery.py's scoring helpers.
- Distinctive: line 155
S2 returns zero recommendations for an anchor: keep going with the remaining anchors.
“Common” is measured: kept by at least 6 in 10 of the 39 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
/discover
Produce a ranked shortlist of paper candidates from one of four seed modes. Surface them to the user (or to the calling skill) with rationales. Never auto-ingest —
/discoveris a proposal stage,/ingestis the action stage.
Use these local references on demand:
references/seed-modes.md— when to pick anchor / topic / wiki / venue mode and how to translate the user's phrasing into onereferences/ranking-signals.md— whattools/discover.pyscores on and why discovery does not share/init's survey preferencereferences/wiki-dedup.md— how candidates are filtered againstwiki/papers/and what to do with matches
Inputs
--anchor <id>(repeatable): one or more anchor paper IDs (arXiv IDs preferred; S2 paperIds also accepted). Drives the anchor mode — the primary use case, including the post-/ingest"what to read next" flow.--negative <id>(repeatable, optional): IDs to push recommendations away from. Only meaningful with--anchor.--topic "<str>": a topic / query string. Drives the topic mode — lighter alternative to/init's planner.--from-wiki: derive seeds automatically from the wiki's most recently modified papers. Drives the wiki mode.--venue <slug>+--year <int>: venue slug and year (e.g.neurips2024). Drives the venue mode — ranks papers from that venue/year by relevance to the existing wiki.--limit N(optional, default 10): max shortlist size.
Exactly one of --anchor, --topic, --from-wiki, or --venue must be given.
Outputs
.checkpoints/discover-{seed-slug}-{YYYY-MM-DD}.json— full shortlist payload, machine-readable; the seed slug is derived from the first anchor or the topic- a human-readable markdown summary printed to the user with rationale per candidate
wiki/log.md— one append line viatools/research_wiki.py logfor anchor/topic/wiki runs only
/discover does not write anywhere else in wiki/ and does not touch raw/. from-venue is stricter: it does not write to wiki/ at all, including wiki/log.md. Whether to actually pull a candidate into the wiki is the caller's decision (a follow-up /ingest).
Wiki Interaction
Reads
wiki/papers/*.md— frontmatterarxiv(or legacyarxiv_id) for dedup against already-ingested paperswiki/papers/*.mdmodification times — for--from-wikianchor selectionwiki/papers/*.md,wiki/concepts/*.md,wiki/topics/*.md— titles and body text for venue-mode relevance scoring
Writes
- anchor/topic/wiki runs:
wiki/log.md— APPEND viatools/research_wiki.py log - venue runs: none
Graph edges created
- none. Graph mutations belong to
/ingest, not/discover.
Workflow
Pre-condition: working directory contains wiki/, raw/, and tools/. Resolve the Python interpreter once and reuse it:
if [ -x .venv/bin/python ]; then
PYTHON_BIN=.venv/bin/python
elif [ -x .venv/Scripts/python.exe ]; then
PYTHON_BIN=.venv/Scripts/python.exe
else
PYTHON_BIN=python3
fi
export PYTHON_BINStep 1: Pick the seed mode
Translate the user's request into exactly one of from-anchors, from-topic, from-wiki, or from-venue. The decision rule lives in references/seed-modes.md; the short version:
- the user named one or more specific papers, or this is a post-
/ingest--discoverfollow-up → anchors - the user gave a topic / direction / keywords → topic
- the user asked open-ended "what should I read next" with no anchor and no topic → wiki
- the user asked for papers from a specific venue and year → venue
If the user supplied negatives ("not these"), include them via --negative in anchor mode only.
Step 2: Run the discovery tool
"$PYTHON_BIN" tools/discover.py from-anchors \
--id <arxiv-id> [--id <arxiv-id>...] [--negative <id>...] \
--wiki-root wiki \
--limit 10 \
--output-checkpoint .checkpoints/ \
--markdownFor venue mode, always pass --wiki-root so the tool can compute relevance against existing content. Venue mode requires a non-sparse wiki (the tool will fail clearly if the wiki is too empty).
Or for topic / wiki modes:
"$PYTHON_BIN" tools/discover.py from-topic "<query>" --wiki-root wiki --limit 10 --output-checkpoint .checkpoints/ --markdown
"$PYTHON_BIN" tools/discover.py from-wiki --wiki-root wiki --limit 10 --output-checkpoint .checkpoints/ --markdownAnchor (and wiki) mode run three S2 channels per anchor by default — recommend + references + citations. This is what makes /discover meaningfully different from /daily-arxiv: references surface older canonical work the anchor built on, citations surface high-impact follow-ups. Pass --no-citation-expand only if API cost forces the narrower recommend-only path; the quality regression is sharp.
The tool handles candidate gathering, wiki dedup, ranking, and writes the checkpoint. Always pass --wiki-root wiki so already-ingested papers are filtered out — surfacing duplicates wastes the user's review time.
If S2 is unavailable in topic mode, the tool will continue with whatever sources responded; check the output and report degraded discovery to the user. If every channel fails, abort with a clear message rather than emitting an empty shortlist as if it were a real recommendation.
Step 3: Present the shortlist
Show the markdown output to the user. For each candidate, the user needs enough to decide whether to ingest:
- title and arXiv ID (or S2 paperId fallback)
- one-line rationale (already produced by the tool: anchor count, influential citations, year)
- TLDR if the tool surfaced one (topic-mode candidates often have it; anchor-mode usually does not — the recommendations endpoint does not return TLDRs)
Append a short "next step" hint:
To ingest a candidate: /ingest https://arxiv.org/abs/<arxiv-id>Do not ingest anything yourself. The user picks.
Step 4: Log
"$PYTHON_BIN" tools/research_wiki.py log wiki "discover | mode=<anchors|topic|wiki> | seed=<short-desc> | shortlist=<N>"Skip this step for from-venue; venue discovery must not write to wiki/ or raw/.
Internal Callers
/discover is designed to be invoked both by users (manually) and by other skills (as a subroutine).
From /ingest --discover
When /ingest is invoked with the optional --discover flag (default off), it calls /discover after the final report, with the just-ingested paper's arXiv ID as the single anchor. The shortlist is appended to /ingest's report under a "Related papers you may want to ingest next" heading. /ingest never auto-ingests anything from this list.
From /init
/init does not call /discover. /init's planner (tools/init_discovery.py plan) has its own scoring that favors surveys, broad coverage, and seed anchors — appropriate for bootstrapping a wiki. /discover's ranking is intentionally different (no survey preference; weights anchor similarity and influential citations) and would dilute /init's shortlist if substituted in. Keep them separate.
Constraints
- Never auto-ingest:
/discoverreturns a shortlist and stops. Even when called by/ingest --discover, the caller surfaces results and the user decides what to ingest. - No content writes to
wiki/: paper pages, concepts, methods, graph edges all belong to/ingest. Anchor/topic/wiki runs may appendwiki/log.md;from-venuemust not write towiki/at all. - No writes to
raw/:/discoverdoes not download papers. The user runs/ingest <arxiv-url>afterwards if they want a candidate. - Always dedupe against the wiki: pass
--wiki-root wikiso the shortlist contains only papers not yet in the wiki. Surfacing duplicates is the most common low-quality failure mode. - Ranking is discovery-specific: do not import or duplicate
tools/init_discovery.py's scoring helpers. The two skills have different objectives —/initwants broad foundational coverage;/discoverwants relevant next reads. Seereferences/ranking-signals.md. - Three-channel anchor gather: by default, anchor mode pulls from S2
recommend+references+citationsper anchor. Removing the citation channels (via--no-citation-expand) collapses the result into a recency-biased semantic cluster that overlaps heavily with/daily-arxiv. Keep all three on unless API cost is a hard constraint. Seereferences/ranking-signals.md. - Some S2 endpoints have a flatter field set:
/citations,/references, and/recommendations/*reject nested selectors — noauthors.hIndex, notldr./paper/{id}and/paper/searchdo accept them, so topic-mode candidates carry full enrichment; anchor-mode candidates that entered only via citations/references/recommend do not. That is a real API constraint, not a bug. - Rate limits apply: each anchor in anchor mode costs up to three S2 calls (recommend + references + citations). Default per-anchor limit is 50 for recs and 30 each for references/citations. Multi-anchor runs multiply accordingly; with an API key (1 req/sec) a 3-anchor run takes ~10 seconds.
Error Handling
- All seed channels fail: report the failure, write no shortlist, and do not log a successful run.
- S2 unavailable, DeepXiv available (topic mode): continue with DeepXiv only; note the degradation in the report.
- S2 returns zero recommendations for an anchor: keep going with the remaining anchors; if all anchors return zero, treat as total failure.
--from-wikifinds no anchorable papers (wiki/papers/empty or all missingarxiv_id): tell the user the wiki is too sparse for wiki-mode discovery and suggest topic mode.from-venuewith a sparse wiki (too few terms extracted from wiki content): fail clearly and suggest ingesting papers or using topic mode. Venue mode relies on existing wiki content for relevance; without it the ranking would be arbitrary.- Anchor ID is malformed or unknown: S2 will return 404; surface the bad ID in the report and continue with any remaining anchors.
Dependencies
Tools (via Bash)
"$PYTHON_BIN" tools/discover.py from-anchors --id <id> [--id <id>...] [--negative <id>...] --wiki-root wiki --limit <N> --output-checkpoint .checkpoints/ --markdown"$PYTHON_BIN" tools/discover.py from-topic "<query>" --wiki-root wiki --limit <N> --output-checkpoint .checkpoints/ --markdown"$PYTHON_BIN" tools/discover.py from-wiki --wiki-root wiki --limit <N> --output-checkpoint .checkpoints/ --markdown"$PYTHON_BIN" tools/discover.py from-venue --venue <slug> --year <int> --wiki-root wiki --limit <N> --output-checkpoint .checkpoints/ --markdown"$PYTHON_BIN" tools/research_wiki.py log wiki "<message>"
Skills
/ingest— caller via--discoverflag; also the action the user takes on a chosen candidate/init— independent planner; does not call/discover
External APIs
- Semantic Scholar — recommendations (
/recommendations/v1/papers/forpaper/{id},POST /recommendations/v1/papers/), search, paper detail (viatools/fetch_s2.py) - DeepXiv — search fallback in topic mode (via
tools/fetch_deepxiv.py, optional; graceful fallback when unavailable) - Paper Copilot — public GitHub raw JSON (
papercopilot/paperlists) for venue/year paper lists. Live-site scraping is not used; do not vendor the dataset. Venue normalization should preserve documented relevance fields such as title, abstract, TLDR, keywords / primary area / topic, track, status, citations, ratings, reviews, and paper URLs when present.
Trending
More talk lately.thin dataabout the whole repository
Who's talking about PKU-DAIR/AutoSci
The biggest 1 of 1 mention linking to the repository that our crawl found. Each line is their own headline.
Other versions49 projects use a version of this.
Word for word · 3
- DAIR-AutoResearch/AutoSci★ 1.7k100% same
- skyllwt/AutoSci★ 1.7k100% same
- skyllwt/OmegaWiki★ 1.7k100% same
Edited · 1
- Lambenthan/empiricalwiki★ 8515% same
Wrote their own version · 45
- suboss87/FDEOps★ 940same name
- ZaxbyHub/opencode-swarm★ 511same name
- zaxbysauce/opencode-swarm★ 503same name
- hsantanna88/clo-author★ 262same name
- hugosantanna/clo-author★ 262same name
- fw-ai/cookbook★ 228same name
- kv0906/pm-kit★ 138same name
- ambient-code/platform★ 131same name
- konglong87/superPM★ 84same name
- AsiaOstrich/universal-dev-standards★ 82same name
35 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 repository30 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- runtime/CLAUDE.mdCLAUDE.md
- askSkill
- checkSkill
- daily-arxivSkill
- editSkill
- exp-designSkill
- exp-evalSkill
- exp-pilot-evalSkill
- exp-pilot-runSkill
- exp-runSkill
- exp-statusSkill
- hiera-experimentSkill
- ideateSkill
- ingestSkill
- initSkill
- noveltySkill
- paper-compileSkill
- paper-draftSkill
- paper-planSkill
- posterSkill
- prefillSkill
- rebuttalSkill
- refineSkill
- researchSkill
- resetSkill
- reviewSkill
- setupSkill
- surveySkill
- visualizeSkill
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.

