bib-verify
Skill0 starsChanged 3 months agoMITView on GitHub
Verify, correct, and format bibliography references in academic papers. Use whenever the user wants to check, fix, clean up, verify, or format references, citations, BibTeX/biblatex entries, or .bib files; suspects hallucinated, fake, or LLM-generated references; wants arXiv preprints upgraded to their published versions; or mentions DOIs, venue names, or bibliography style in a LaTeX paper — even if they don't explicitly say "verify". Checks every entry against DBLP/Crossref/arXiv, prefers the published proceedings version, and applies house style (venue acronyms, shortDOI, minimal fields).
2 other projects use a version of this.
Adopted by
Most recently taken up by
- acprk/crypto-research-agentstheir own version, first seen Nov 4, 2026
- JinchengGao-Infty/agent-loadouttheir own version, first seen Mar 25, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- acprk/crypto-research-agents★ 15same name
- JinchengGao-Infty/agent-loadout★ 3same 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.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
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 36
Use the bundled lookup script for all API calls — do not hand-roll curl commands:
- Very specific: line 48
Always include "author" (first author's last name): DBLP ranking is unreliable on title alone.
- Distinctive: line 105
Title/author drift: when the arXiv and published versions differ, the published version wins.
- Very specific: line 106
Workshop papers: use the parent venue acronym + W (CVPRW, ICCVW, ECCVW, NeurIPSW), even when DBLP names the specific workshop.
≈ “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.
Files
Bibliography Verification & Cleanup
Why this skill exists
Reference lists rot in three ways. First, metadata copied from Google Scholar or arXiv disagrees with the camera-ready version: titles, author lists, venues, and years all drift between preprint and publication (e.g., arXiv's "Fixing Weight Decay Regularization in Adam" became ICLR 2019's "Decoupled Weight Decay Regularization"). Second, LLM-drafted text invents plausible-looking papers that do not exist. Third, entries accumulate noise (pages, publishers, addresses, full venue names) that the house style deliberately omits. The remedy is always the same: verify every entry against authoritative sources, prefer the published version, and reformat to the minimal house style described in references/conventions.md.
Source-of-truth hierarchy
- Published version (conference proceedings or journal). Camera-ready metadata wins over any preprint: if title or authors changed between arXiv and the proceedings, the proceedings version is correct.
- arXiv for papers never formally published →
@preprint. - A reference that cannot be found on DBLP, Crossref, arXiv, or the open web is presumed hallucinated → flag it, never delete it.
Lookup sources, in order of usefulness for CS/ML:
- DBLP — best for computer science. It lists the arXiv version (
"Informal and Other Publications") alongside conference/journal versions of the same paper, so one query answers "does a published version exist?" - Crossref — the DOI authority; best for journals and non-CS material.
- arXiv API — current preprint metadata (latest title, authors, arXiv id).
- OpenReview / publisher pages (CVF Open Access, ACM DL, IEEE Xplore, Springer) via WebFetch or WebSearch, when the APIs disagree or the paper is too recent for DBLP.
Workflow
1. Inventory
Read the target .bib file. If the user pointed at a paper or project rather than a lone .bib, find the .bib via \bibliography{...} / \addbibresource{...} in the .tex sources. Then grep the .tex files for citation commands (\cite, \citep, \citet, \parencite, \textcite, \autocite, and starred/optioned variants) and build two lists:
- Cited but missing from .bib — report as errors; these would break the build.
- In .bib but never cited — report informationally; do not delete them.
2. Verify in batch
Use the bundled lookup script for all API calls — do not hand-roll curl commands:
SKILL=${CLAUDE_SKILL_DIR}/scripts/biblookup.py
# One call verifies many entries (1s pause between queries; ~40 entries fit
# in a default Bash timeout — chunk larger files or raise the timeout):
printf '%s\n' \
'{"key":"ho2020denoising","title":"Denoising diffusion probabilistic models","author":"Ho"}' \
'{"key":"smith2023garment","title":"Garment-Aware NeRF for Try-On","author":"Smith"}' \
| python3 $SKILL batchAlways include "author" (first author's last name): DBLP ranking is unreliable on title alone. Each result line reports exact_matches (title-identical hits, arXiv and published alike), published_versions (the non-arXiv subset), and near_misses when nothing matched exactly.
For entries the batch pass could not settle, drill down individually:
python3 $SKILL search "TITLE AUTHOR" # DBLP, richer query
python3 $SKILL crossref "TITLE" # journals, non-CS, DOI lookup
python3 $SKILL arxiv 2010.11929 # or: python3 $SKILL arxiv "title words"
python3 $SKILL shortdoi 10.1109/TIP.2003.819861 # → {"suffix": "c7sr27"}Escalate to WebSearch/WebFetch (OpenReview, CVF, publisher page, Semantic Scholar) before declaring an entry unverifiable — very recent papers often lag on DBLP.
3. Resolve each entry
- Published version exists →
@inproceedings(or@articlefor journals). Use the camera-ready title, author list, venue acronym, and the venue's year (which may differ from the arXiv year and from the year embedded in the citation key — that is fine; see hard rules). - DOI: prefer the publisher's DOI (IEEE, ACM, Springer, Elsevier). If the venue issues no DOIs (ICLR, BMVC, NeurIPS most years — anything hosted on OpenReview or proceedings sites without DOIs), use the paper's arXiv DOI
10.48550/arXiv.<id>instead, while keeping the@inproceedingstype and venue. Either way, convert withshortdoiand store only the suffix. - arXiv only, never published →
@preprintwitheprint,eprinttype = {arxiv}, year of first arXiv submission, and the shortDOI of the arXiv DOI. - Websites, software, reports →
@misc/@reportwithurl; no DOI machinery. - Nothing found anywhere → keep the entry, add a comment line directly above it:
% UNVERIFIED (bib-verify YYYY-MM-DD): not found on DBLP/Crossref/arXiv/weband list it prominently in the report.
4. Rewrite
Apply the templates and field rules in references/conventions.md — read that file before editing. Work surgically: keep entry order and the % ==== section comment blocks intact, and leave already-conforming entries byte-for-byte untouched.
5. Report
End with a summary the user can act on:
## Reference verification: <file>
Checked N entries: V already correct, C corrected, U upgraded preprint→published, F flagged.
### Corrections
- key — venue "Proceedings of ..." → CVPR; removed pages/publisher; added doi
- key — title updated to camera-ready; year 2017 → 2019 (ICLR)
### Flagged as unverified
- key — searched DBLP/Crossref/arXiv/web; closest hit was <...>. Kept in place with % UNVERIFIED comment.
### Cross-check with .tex
- Cited but missing from .bib: key1, key2
- In .bib but never cited: key3 (left untouched)Hard rules
- Never rename citation keys. The .tex files reference them; a renamed key breaks the build. Keys keep their original year even when the
yearfield changes (dosovitskiy2020imagewithyear = {2021}is correct). New entries you create followfirstauthorYEARfirstword, all lowercase. - Never delete an entry, even one that looks fabricated. Flag and report; the user decides.
- Never guess an identifier. Every DOI, shortDOI suffix, and arXiv id must come from an API response or a page actually fetched this session. Fabricating identifiers is the exact failure this skill exists to prevent. If
shortdoifails, leave the entry without adoirather than inventing one. - Verify, don't pattern-match. An entry that "looks right" still gets checked — plausible-looking metadata is what hallucinations are made of.
- Ask before mass changes beyond the mandate. Reformatting verified entries is the mandate; do not, e.g., re-abbreviate author first names or restructure the file layout.
Edge cases
- Title/author drift: when the arXiv and published versions differ, the published version wins. Mention the change in the report so the user can update any in-text mentions of the title.
- Workshop papers: use the parent venue acronym +
W(CVPRW, ICCVW, ECCVW, NeurIPSW), even when DBLP names the specific workshop. - Same title, different papers: disambiguate by author list and year before touching anything.
- DBLP misses: DBLP indexes CS; economics/marketing/medicine papers live on Crossref. A DBLP miss alone never justifies an UNVERIFIED flag.
- Multiple published versions (e.g., conference paper later extended to a journal): keep the version the user cited unless they ask otherwise; note the other version in the report.
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.

