/neuroarxiv
Grounds a coding agent's architecture decisions in real arXiv prior art before it builds something new. Reads arXiv category-wise via real HTTP fetch, spawns parallel isolated reads across the papers found, scores/clusters them, then converges on ONE recommended path with
$ npx -y skills add UditAkhourii/neuroarxiv --skill neuroarxiv --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/neuroarxiv
Context preview
The summary Claude sees to decide when to auto-load this skill.
Grounds a coding agent's architecture decisions in real arXiv prior art before it builds something new. Reads arXiv category-wise via real HTTP fetch, spawns parallel isolated reads across the papers found, scores/clusters them, then converges on ONE recommended path with
SKILL.md
neuroarxiv.SKILL.mdname: neuroarxiv
description: Grounds a coding agent's architecture decisions in real arXiv prior art before it builds something new. Reads arXiv category-wise via real HTTP fetch, spawns parallel isolated reads across the papers found, scores/clusters them, then converges on ONE recommended path with citations, a first step, and known prior-art pitfalls to avoid. Use on /neuroarxiv, before designing non-trivial architecture, algorithms, ML/systems techniques, or protocols, or when the user asks "has anyone solved this", "what's the state of the art", or "am I about to rebuild something that already exists". Skip for trivial CRUD, glue code, or closed phrasing ("just", "quick", "standard"). Full pre-flight gate is in the skill body.
license: MITNeuroArxiv
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.
| Category | Covers | |---|---| | cs.AI | general AI systems, agents, planning, knowledge representation | | cs.LG | learning algorithms, training methods, model architectures | | cs.CL | NLP, language models, text processing | | cs.CV | image/video understanding, generation, perception | | cs.IR | search, ranking, recommendation, retrieval-augmented systems | | cs.DC | distributed systems, consensus, sharding, replication, scheduling | | cs.DB | storage engines, query processing, indexing, transactions, consistency | | cs.SE | development practices, testing, program analysis, tooling | | cs.PL | language design, type systems, compilers, runtimes | | cs.CR | protocols, authentication, adversarial robustness, privacy | | cs.NI | routing, congestion control, edge/CDN | | cs.OS | kernels, schedulers, memory management, virtualization | | cs.HC | interface design, usability, interaction models | | cs.MA | coordination, negotiation, emergent behavior among agents | | cs.RO | control, perception, manipulation, motion planning | | cs.DS | algorithmic techniques, complexity, data structure design | | cs.GT | mechanism design, auctions, incentive-compatible systems | | stat.ML | statistical learning theory, probabilistic models | | eess.SP / eess.SY | signal processing / control theory | | math.OC | optimization, scheduling, resource allocation |
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 ano
Read more
name: neuroarxiv
description: Grounds a coding agent's architecture decisions in real arXiv prior art before it builds something new. Reads arXiv category-wise via real HTTP fetch, spawns parallel isolated reads across the papers found, scores/clusters them, then converges on ONE recommended path with citations, a first step, and known prior-art pitfalls to avoid. Use on /neuroarxiv, before designing non-trivial architecture, algorithms, ML/systems techniques, or protocols, or when the user asks "has anyone solved this", "what's the state of the art", or "am I about to rebuild something that already exists". Skip for trivial CRUD, glue code, or closed phrasing ("just", "quick", "standard"). Full pre-flight gate is in the skill body.
license: MITNeuroArxiv
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.
| Category | Covers | |---|---| | cs.AI | general AI systems, agents, planning, knowledge representation | | cs.LG | learning algorithms, training methods, model architectures | | cs.CL | NLP, language models, text processing | | cs.CV | image/video understanding, generation, perception | | cs.IR | search, ranking, recommendation, retrieval-augmented systems | | cs.DC | distributed systems, consensus, sharding, replication, scheduling | | cs.DB | storage engines, query processing, indexing, transactions, consistency | | cs.SE | development practices, testing, program analysis, tooling | | cs.PL | language design, type systems, compilers, runtimes | | cs.CR | protocols, authentication, adversarial robustness, privacy | | cs.NI | routing, congestion control, edge/CDN | | cs.OS | kernels, schedulers, memory management, virtualization | | cs.HC | interface design, usability, interaction models | | cs.MA | coordination, negotiation, emergent behavior among agents | | cs.RO | control, perception, manipulation, motion planning | | cs.DS | algorithmic techniques, complexity, data structure design | | cs.GT | mechanism design, auctions, incentive-compatible systems | | stat.ML | statistical learning theory, probabilistic models | | eess.SP / eess.SY | signal processing / control theory | | math.OC | optimization, scheduling, resource allocation |
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 ano
### 🎮 Join the Discord → This is where the real-time thinking happens: arXiv category coverage, eval design, prior-art hunting, and neurodivergence-inspired research on reasoning architectures — shared with the ADHD community.