literature-search

Literature Search (shared toolchain)

This skill is not a loop — it is the literature-retrieval dependency several loops use for paper discovery and novelty checks. It bundles tools/lit_search.py (a stdlib-only entrypoint) and the tools/lit/ package: Semantic Scholar (S2) for semantic search + snippets + the citation graph and arXiv for full-text reads (the keyless core), plus optional OpenAlex, Perplexity Sonar (ask), and bgpt.pro (bgpt) when their keys are set. Every subcommand prints JSON; on a terminal failure it prints {"error","fallback"} and exits non-zero so the caller degrades to its built-in WebSearch/WebFetch. No installs, Python ≥3.9.

How a loop uses it

A consuming loop resolves these once at setup and reuses them:

• <lit_skill_dir> — where this skill is installed. After cp -r loops/* ~/.claude/skills/ it sits as a sibling of the calling loop, e.g. ~/.claude/skills/literature-search/ (adjust per host). If it cannot be resolved, the caller falls back to WebSearch/WebFetch — depending on it never hard-breaks a loop, it only enriches it.
• <lit> — the literature CLI as a single command token: <lit_skill_dir>/tools/lit_search.py. The entrypoint is executable and carries a #!/usr/bin/env python3 shebang, so it runs directly with no python3 prefix. To reuse a cache across calls, append --cache-dir <sandbox_root>/literature/.cache after the subcommand (a per-subcommand flag, not global).
• <lit_py> — only needed for the fallback form on a host that doesn't honour the execute bit: <lit_py> <lit_skill_dir>/tools/lit_search.py, with <lit_py> = python3 (any ≥3.9 interpreter).

Invoke <lit> as one command — keep it a single shell token. In particular zsh does not word-split unquoted variables, so storing the two-word python3 .../lit_search.py in a variable and calling $VAR tries to exec one long (nonexistent) filename. Use the executable single-token form above, call the script path directly, or split explicitly (${=VAR} in zsh).