Neuroarxiv

NeuroArxiv

Vibecoders don't waste hours because they lack skill. They waste hours because they start building before checking whether the hard part has already been solved and published, with the failure modes already known. arXiv is the world's largest source of truth for "has anyone done this" — and almost nobody about to write code actually reads it first. This skill makes the agent read it first.

Pre-flight (run before Phase 1)

This skill is expensive: a real arXiv fetch plus roughly one isolated Agent call per paper (typically 10-20), plus scoring, clustering, and convergence. Do not pay that cost when there's no real prior art to find.

Step 1. Explicit invocation check.

If the user typed /neuroarxiv, explicitly asked to "check arXiv", "check prior art", or "run NeuroArxiv", skip the rest of this section and go straight to Phase 1. The user opted in.

Step 2. Self-judge (only if Step 1 did not match).

Ask yourself three questions. If the answer to any is no, ABORT.

1. Is there a technical mechanism to research? Naming a variable, wiring a CRUD form, or gluing two documented SDKs together has no prior-art question worth asking. Designing a caching strategy, a consensus/coordination scheme, a ranking or retrieval approach, an ML training or inference technique, a novel protocol, or anything where "the naive version breaks at scale" — does.
2. Is the user about to commit real effort to it? A one-off script doesn't earn a literature search. A component that will anchor the architecture, or that's expensive to redo once built wrong, does.
3. Did the user leave the approach open? If they already named the specific algorithm/paper/library to use, or said "just implement it the simple way", they've already converged — don't re-open it. Abort.

If all three checks pass, proceed to Phase 1.

If any fails, ABORT and proceed with the direct implementation. Optionally append one sentence: "If you want this checked against arXiv prior art first, run /neuroarxiv <your problem>."

The loop

Three phases. Fetching is not divergence — it's find real documents, then read each in isolation, then converge. Skipping the isolation step turns this into an LLM guessing about papers it hasn't actually read.

Phase 0 — Categorize

Map the build problem onto 3-5 arXiv subject categories and 3-6 concrete search terms (the technical mechanism words — "cache invalidation", not "caching system"). Pick from the table below, or name another category id if you're confident of it.

If the problem is pure product/business framing with no obvious technical mechanism, say so plainly — but still commit to a best-effort technical angle. Most build problems have one (caching, consistency, ranking, scheduling, retrieval) even unphrased.

Phase 1 — Fetch (real HTTP, no generation)

For each chosen category, call WebFetch against arXiv's real export API — do not paraphrase this step from memory, actually fetch it:

https://export.arxiv.org/api/query?search_query=cat:<CATEGORY>+AND+(all:"<term1>"+OR+all:"<term2>")&start=0&max_results=4&sortBy=relevance&sortOrder=descending

Ask WebFetch to return, per <entry>: the arXiv id, title, abstract, authors, published date, and the abs/pdf links — verbatim from the feed, not summarized. This is a real Atom XML feed; treat every field as ground truth, never invent a paper, id, or detail not present in the response.

If a category returns fewer than 2 results, retry that category's query with the search terms dropped (cat:<CATEGORY> alone) — don't pad the result set with irrelevant hits to hit a target count. If everything comes back thin, say so in the output rather than manufacturing findings.

Courtesy: arXiv asks for one request at a time with a few seconds between calls. Fetch categories one after another, not concurrently.

Phase 2 — Diverge (read each paper in isolation)

For every paper collected in Phase 1, spawn a parallel Agent/Task call. One per paper. Each Agent gets only:

• the build problem
• that ONE paper's title, abstract, authors, year — no other paper
• the instruction below

You are in DIVERGENT READ mode. You have exactly one paper's title and abstract, and one build problem. You do not know what other papers exist — do not assume, invent, or gesture at a broader survey. Read this abstract as if scouting prior art for someone about to build the stated thing from scratch. Never quote the abstract verbatim beyond a few consecutive words — paraphrase in your own words. Extract: approach (1-2 sentences, the core mechanism), borrow (1 sentence, the single most concrete implementable takeaway — imperative: "Use X to do Y"; if too tangential, say so plainly), limitation (1 sentence, the load-bearing weakness or breaking condition), relevanceNote (1 short clause on fit to the stated problem). Output JSON only: {"approach":"...","borrow":"...","limitation":"...","relevanceNote":"..."}

Critical invariant. These calls must be parallel and isolated. A read that has seen other papers' abstracts starts summarizing the SET instead of grounding in the ONE paper in front of it — that's a subtler failure than ADHD's cross-talk collapse, and easy to miss because the output still looks paper-specific.