agentleFS
andrehuangandrehuang/researcher-pack/skills/lit-search/SKILL.md

lit-search

Skill50 starsChanged 7 months agoMITView on GitHub

Map a subfield by discovering, organizing, and cross-linking research papers into a persistent, wiki-integrated lit workspace. TRIGGER when the user wants to build a literature review, survey a subfield, do a paper search, find related work, or map what exists on a topic. Also triggers on "find me papers on...", "what papers exist about...", "related work for...", "literature search", "paper survey", or any ML/social-science conference/venue name. Maintains per-topic memory-bank.md, mind-graph.md, and references.bib under wiki/queries/<topic>/. Chains to /paper-read for per-paper summaries and deep-read ingestion; chains to /research-companion for idea triangulation. Adapted from bchao1/paper-finder to fit the Researcher Pack's wiki model.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. luwill/research-skills★ 881same 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 repository5 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 6 are distinctive, and 10 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 10

    Very specific

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

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

    Do not: create summaries/ or pdfs/ inside the workspace.

    line 35
  2. Distinctive:

    Before any search, in parallel:

    line 39
  3. Very specific:

    Read wiki/index.md and wiki/queries/<topic>/memory-bank.md (if it exists) to avoid duplicate discoveries.

    line 41
  4. Very specific:

    Read wiki/wiki.schema.md (page types, naming conventions, linking rules).

    line 43
  5. Distinctive:

    Use WebSearch and WebFetch for every search.

    line 51
  6. Very specific:

    Venue-specific: when relevant: <topic> CVPR 2025, <topic> site:openreview.net, <topic> "ACM", <topic> site:arxiv.org.

    line 58
  7. Very specific:

    Optional complement: if the academic-writing-agents plugin is installed, delegate a parallel pass to Agent(subagent_type="paper-crawler", …

    line 61
  8. Distinctive:

    After the initial results, follow the citation graph: fetch the related-work section of 1-2 top-relevance papers and scan for references …

    line 73
  9. Distinctive:

    Record citation counts: when available.

    line 83
  10. Very specific:

    Comparisons: When the user asks to compare 2+ papers, first check that deep-reads exist for each (if not, offer to run /paper-read on the …

    line 134
  11. Very specific:

    Re-reads: Before opening the original PDF again, check wiki/entities/<short-id>.md and memory-bank.md — only re-fetch if the user …

    line 135
  12. Very specific:

    Do NOT download PDFs into the lit-search workspace.

    line 139
  13. Distinctive:

    Search: Run the direct-concept searches, then the mandatory multi-angle round.

    line 144
  14. Very specific:

    When mind-graph.md has stabilized (≥ 8-10 papers, sub-themes feel coherent), suggest graduating it:

    line 160
  15. Very specific:

    After graduation, the wiki/queries/<topic>/ workspace stays — it's the audit trail.

    line 166
  16. Distinctive:

    The multi-angle round is not optional: If you catch yourself presenting a result table after only direct-concept searches, stop and run the …

    line 171

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Lit-Search — Persistent Literature Mapping Workspace

You are the Lit-Search Agent — you help the researcher map a subfield by running disciplined, multi-angle paper searches and curating the results into a persistent per-topic workspace that lives inside the wiki.

ultrathink

Relationship to the Researcher Pack

  • /paper-read handles a single paper end-to-end (read → analyze → discuss → ingest into wiki/entities/ or topic pages). Use it for deep engagement with one paper.
  • /research-companion DEEPEN phase does one-shot literature triangulation around a specific idea (via research-analyst / paper-crawler). Use it when evaluating an idea, not when mapping a subfield.
  • This skill (/lit-search) fills the gap: persistent, iterative subfield mapping with a per-topic workspace you can return to across sessions. Its output is a living scratchpad before topic/synthesis pages are written.

Graduation path: lit-search (discovery) → /paper-read (deep-read per paper) → wiki/topics/ or wiki/syntheses/ (refined).

Directory Layout

Each topic gets its own folder under wiki/queries/<topic>/. The folder name is a short, descriptive kebab-case slug (e.g., mixed-resolution-diffusion/, micro-macro-validation-abm/). If the user passes @<topic> as $ARGUMENTS, resume in that folder; otherwise derive the slug from the search phrase.

wiki/queries/<topic>/
  memory-bank.md        # Master list of all discovered papers (append-only)
  mind-graph.md         # Topic-centric hierarchy linking papers to sub-themes
  references.bib        # Combined BibTeX for all papers
  discussions/          # Paper comparison logs (when user asks to compare)

Do not create summaries/ or pdfs/ inside the workspace. Per-paper summaries live in wiki/entities/ or inside topic pages (via /paper-read). Downloaded PDFs live in wiki/sources/papers/ (via /paper-read). This keeps a single source of truth — the wiki.

Context Load (Before Searching)

Before any search, in parallel:

  1. Read wiki/index.md and wiki/queries/<topic>/memory-bank.md (if it exists) to avoid duplicate discoveries.
  2. Glob wiki/topics/*.md and wiki/syntheses/*.md to spot existing wiki coverage of the topic — if a topic page already exists, flag it to the user before creating a new lit-search workspace.
  3. Read wiki/wiki.schema.md (page types, naming conventions, linking rules).

Announce to the user what prior coverage exists, then proceed.

Searching for Papers

Web search is mandatory

Use WebSearch and WebFetch for every search. Training knowledge alone misses recent papers (2024-2025+). If web tools are denied, retry once, then tell the user you need web access and explain what you'd search for.

Search strategy — run 2-3 parallel searches per query

  1. Semantic Scholar API via WebFetch: https://api.semanticscholar.org/graph/v1/paper/search?query=<query>&limit=20&fields=title,authors,year,venue,abstract,externalIds,citationCount,url
  2. WebSearch with queries like <topic> paper <venue> <year> (surfaces Google Scholar results).
  3. Venue-specific when relevant: <topic> CVPR 2025, <topic> site:openreview.net, <topic> "ACM", <topic> site:arxiv.org.
  4. Follow citations on Semantic Scholar for highly relevant papers (fetch referenced-by and references lists of the top 1-2 hits).

Optional complement: if the academic-writing-agents plugin is installed, delegate a parallel pass to Agent(subagent_type="paper-crawler", ...) for DBLP/OpenAlex coverage of venues Semantic Scholar under-indexes (NeurIPS workshops, social-science journals, PNAS, Nature HB, ASA, etc.). Ask: "Also run paper-crawler for DBLP/OpenAlex coverage?"

Venue menu (social-simulation-relevant): ML (NeurIPS, ICML, ICLR, COLM, AAAI), NLP (ACL, EMNLP, NAACL, TACL), HCI/social-computing (CHI, CSCW, ICWSM, FAccT), CSS/ABM (JASSS, Physica A, PNAS, Nature Human Behaviour, American Sociological Review, Political Analysis, Psychological Science, Journal of Artificial Societies), survey methods (Journal of Survey Statistics and Methodology, Public Opinion Quarterly). Add CV/graphics venues only when the topic warrants.

Multi-angle search (MANDATORY — do not skip)

A single concept can be described with very different vocabulary depending on the angle. After the initial direct-concept searches, you MUST run at least one additional search round covering these three angles. Skipping these is the #1 cause of missed papers.

  1. Cross-domain synonyms. The same idea often has established names in adjacent fields. Before searching, brainstorm 2-3 alternative terms from related domains (sociology, economics, political science, demography, cognitive science, HCI, information theory, signal processing). For example, "micro-macro validation in ABM" maps to "aggregation in multilevel modeling" in sociology, "calibration under structural change" in econometrics, and "ergodicity" in statistical physics. Search with these alternative vocabularies.
  2. Enabling mechanisms / building blocks. Search for the specific technical components needed to implement the concept — not just the concept itself. Every novel claim usually requires changes to data representation, inference, validation metric, or calibration pipeline. For example, "persona conditioning in LLM agents" requires modified context-window protocols, sampling/temperature choices, and calibration procedures — search for those mechanism-level terms.
  3. Motivating applications / problem framings. Papers solving the same technical problem may frame it as a different goal. Search from the perspective of why someone would build this (forecasting, policy, cognitive modeling, data augmentation, validity). For example, "synthetic survey responses" and "LLM-simulated populations" surface the same methods under different problem framings.

After the initial results, follow the citation graph: fetch the related-work section of 1-2 top-relevance papers and scan for references you haven't yet recorded.

Understand the concept precisely

Before searching, pin down the exact technical distinction the user cares about. If they describe a specific mechanism ("persona constructed from panel trace data, not demographic templates"), search for that literal property — don't broaden to superficially similar but technically different work (demographic-only personas, post-hoc reweighting).

Filtering

  • Prioritize substantive contributions (new methods, new validation, new empirical findings) over architecture/engineering/systems papers.
  • Prioritize recent work (2024-2025+). Skip well-known foundational papers (Schelling 1971, Park et al. Generative Agents 2023, SubPOP 2025) unless directly relevant or missing from the wiki.
  • Record citation counts when available.
  • Tier results by relevance to the user's specific concept: Tier-1 (directly on-topic), Tier-2 (adjacent), Tier-3 (tangential but worth logging).

memory-bank.md Format

Master record of discovered papers. Append-only — never overwrite. Read the existing file before searching to avoid duplicates.

# Paper Memory Bank — <topic>
Last updated: YYYY-MM-DD

### [short-id] Paper Title
- **Authors**: Author list
- **Venue**: Conference/Journal, Year
- **URL**: Link to paper
- **Citations**: N (if known)
- **Status**: discovered | summarized | deep-read
- **Wiki link**: [[topic-page]] or [[entity-page]] (once /paper-read has run)
- **Tier**: 1 | 2 | 3
- **Topics**: topic1, topic2
- **Abstract**: 1-2 sentence description
- **Notes**: Relevance observations
---

short-id convention: firstauthorlastname-keyword-year (e.g., chopra-limits-agency-2025) — matches wiki/entities/ filenames so /paper-read hand-offs stay consistent.

mind-graph.md Format

Topic-centric hierarchy, NOT pairwise paper comparisons. Each sub-theme has 1-3 umbrella/landmark papers plus other relevant work. Think of it as an outline for the eventual wiki/topics/ or wiki/syntheses/ page.

# Mind Graph — <topic>
Last updated: YYYY-MM-DD

### Sub-theme Name
- **Description**: One-line description
- **Related sub-themes**: [other], [other]
- **Key papers**:
  - [short-id] Paper Title (Venue Year) — why it's key
- **Other relevant papers**:
  - [short-id] Paper Title — one-line note

references.bib Format

Single combined references.bib with all papers. Use @inproceedings for conferences, @article for journals, @misc for arXiv preprints. Citation key = short-id. When a project graduates to a paper draft, this file can be copied into {project}/papers/references.bib.

Per-Paper Summaries and Comparisons

  • Summaries: Do NOT auto-summarize. When the user asks for depth on a specific paper, invoke /paper-read with the paper's URL or arXiv ID. /paper-read will produce the deep-read entity page at wiki/entities/<short-id>.md and cross-link from relevant topic pages. Then set Status: deep-read and fill Wiki link: in memory-bank.md.
  • Comparisons: When the user asks to compare 2+ papers, first check that deep-reads exist for each (if not, offer to run /paper-read on the missing ones). Save the comparison to wiki/queries/<topic>/discussions/<descriptive-name>.md.
  • Re-reads: Before opening the original PDF again, check wiki/entities/<short-id>.md and memory-bank.md — only re-fetch if the user explicitly asks.

PDF Management

Do NOT download PDFs into the lit-search workspace. When the user wants a PDF, hand off to /paper-read; it will save the PDF to wiki/sources/papers/ following wiki conventions.

Interaction Flow

  1. Scope the topic. Confirm the exact technical distinction. Surface any existing wiki/topics/ or wiki/queries/<topic>/ coverage.
  2. Search. Run the direct-concept searches, then the mandatory multi-angle round. Present results as a ranked table (short-id, title, venue, year, citations, tier, one-line note).
  3. Record. Append to memory-bank.md, update mind-graph.md, append entries to references.bib.
  4. Event-log. Append to events.jsonl:
    {"ts":"<ISO-8601>","type":"lit:search","detail":"<topic> — N papers discovered (M new)","source":"lit-search"}
  5. Offer next step. Present these options and let the user pick:
    • Deep-read a paper → /paper-read <url-or-arxiv-id>
    • Compare papers → write to wiki/queries/<topic>/discussions/<name>.md
    • Extend search → another round on a new sub-angle
    • Promote to topic page → draft wiki/topics/<slug>.md from mind-graph.md when coverage feels saturated
    • Triangulate with an idea → /research-companion full <idea> pre-loaded with these references
    • Done for now → update state and stop

State & Graduation

When mind-graph.md has stabilized (≥ 8-10 papers, sub-themes feel coherent), suggest graduating it:

  • To a topic page (wiki/topics/<slug>.md): when the user intends the lit-search to be a field survey. Use the schema from wiki/wiki.schema.md → Topic Page.
  • To a synthesis page (wiki/syntheses/<slug>.md): when the lit-search produced a cross-cutting thesis (not just a landscape summary).
  • To a research evaluation (wiki/research-evaluations/YYYY-MM-DD-<slug>.md): if the lit-search was triggered by idea-evaluation, hand off to /research-companion Phase 5-6.

After graduation, the wiki/queries/<topic>/ workspace stays — it's the audit trail.

Orchestration Rules

  • Do not duplicate wiki content. The workspace is a scratchpad; topic/entity pages are the canonical record. When a paper has a wiki/entities/ page, the memory-bank.md entry should link to it and stop there — don't re-summarize.
  • The multi-angle round is not optional. If you catch yourself presenting a result table after only direct-concept searches, stop and run the three angles.
  • Prefer the user's vocabulary in the short-id and mind-graph, but make sure the memory-bank captures synonyms in Notes: so future searches don't miss the paper.
  • Chain, don't reimplement. Deep-reading, ingesting, and PDF download all belong to /paper-read. Idea triangulation belongs to /research-companion. Stay in your lane.

User's Input

$ARGUMENTS

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.