Back to Details

neuroarxiv

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
Vibecoders并非因能力不足而浪费时间，而是因为他们在开始构建前，没有先确认核心难题是否已被解决并发表，且相关失败模式已为人所知。arXiv是全球最大的“是否有人做过这件事”的事实来源——但几乎所有即将编写代码的人都不会先查阅它。本技能让Agent先完成这项查阅工作。

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>
."
本技能的成本较高：需要真实调用arXiv接口获取数据，每篇论文大约需要一次独立的Agent调用（通常为10-20篇），再加上打分、聚类和收敛步骤。当不存在真正值得查找的现有研究时，请勿付出这些成本。
步骤1. 显式调用检查
如果用户输入了
/neuroarxiv
，明确要求“检查arXiv”“查阅现有研究”或“运行NeuroArxiv”，跳过本节剩余内容，直接进入第一阶段。用户已主动选择使用本技能。
步骤2. 自我判断（仅当步骤1未匹配时执行）
问自己三个问题。若任何一个问题的答案为否，则终止执行。
  1. 是否存在需要研究的技术机制？ 变量命名、搭建CRUD表单或拼接两个有文档的SDK这类工作，没有值得询问的现有研究问题。而设计缓存策略、共识/协调方案、排序或检索方法、机器学习训练或推理技术、新型协议，或任何“naive版本在规模化场景下会失效”的内容，则属于此类。
  2. 用户是否即将为此投入实际精力？ 一次性脚本不值得进行文献检索。而作为架构核心的组件，或一旦构建错误就需付出高额返工成本的组件，则值得。
  3. 用户是否未限定实现方式？ 如果用户已经指定了具体的算法/论文/库，或表示“就用简单方式实现”，说明他们已确定方案——不要重新开启讨论。终止执行。
如果三个检查全部通过，进入第一阶段。
若任何一项不通过，终止执行并直接进行实现。可选择性添加一句话：“如果您希望先对照arXiv现有研究进行检查，请运行 
/neuroarxiv <您的问题>
。”

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.
分为三个阶段。获取数据并非发散思考——而是找到真实文档，然后独立阅读每一篇，最后收敛到统一方案。跳过独立阅读步骤会让LLM对未实际阅读的论文进行猜测。

Phase 0 — Categorize

阶段0 — 分类

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.
CategoryCovers
cs.AIgeneral AI systems, agents, planning, knowledge representation
cs.LGlearning algorithms, training methods, model architectures
cs.CLNLP, language models, text processing
cs.CVimage/video understanding, generation, perception
cs.IRsearch, ranking, recommendation, retrieval-augmented systems
cs.DCdistributed systems, consensus, sharding, replication, scheduling
cs.DBstorage engines, query processing, indexing, transactions, consistency
cs.SEdevelopment practices, testing, program analysis, tooling
cs.PLlanguage design, type systems, compilers, runtimes
cs.CRprotocols, authentication, adversarial robustness, privacy
cs.NIrouting, congestion control, edge/CDN
cs.OSkernels, schedulers, memory management, virtualization
cs.HCinterface design, usability, interaction models
cs.MAcoordination, negotiation, emergent behavior among agents
cs.ROcontrol, perception, manipulation, motion planning
cs.DSalgorithmic techniques, complexity, data structure design
cs.GTmechanism design, auctions, incentive-compatible systems
stat.MLstatistical learning theory, probabilistic models
eess.SP / eess.SYsignal processing / control theory
math.OCoptimization, 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.
将构建问题映射到3-5个arXiv主题分类和3-6个具体搜索词（需为技术机制相关词汇——比如“cache invalidation”，而非“caching system”）。可从下表中选择，或在确定的情况下自行指定其他分类ID。
分类涵盖范围
cs.AI通用AI系统、Agent、规划、知识表示
cs.LG学习算法、训练方法、模型架构
cs.CL自然语言处理（NLP）、语言模型、文本处理
cs.CV图像/视频理解、生成、感知
cs.IR搜索、排序、推荐、检索增强系统
cs.DC分布式系统、共识、分片、复制、调度
cs.DB存储引擎、查询处理、索引、事务、一致性
cs.SE开发实践、测试、程序分析、工具链
cs.PL语言设计、类型系统、编译器、运行时
cs.CR协议、认证、对抗鲁棒性、隐私
cs.NI路由、拥塞控制、边缘/CDN
cs.OS内核、调度器、内存管理、虚拟化
cs.HC界面设计、可用性、交互模型
cs.MAAgent间的协调、协商、涌现行为
cs.RO控制、感知、操作、运动规划
cs.DS算法技术、复杂度、数据结构设计
cs.GT机制设计、拍卖、激励兼容系统
stat.ML统计学习理论、概率模型
eess.SP / eess.SY信号处理 / 控制理论
math.OC优化、调度、资源分配
如果问题是纯产品/业务框架，无明显技术机制，请直接说明——但仍需尽力找到一个技术角度。大多数构建问题都隐含技术机制（缓存、一致性、排序、调度、检索），即使未明确表述。

Phase 1 — Fetch (real HTTP, no generation)

阶段1 — 获取数据（真实HTTP请求，不生成内容）

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.
针对每个选定的分类，调用WebFetch访问arXiv的真实导出API——请勿凭记忆复述此步骤，需实际发起请求：
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
要求WebFetch返回每个
<entry>
的以下内容：arXiv ID、标题、摘要、作者、发表日期，以及
abs
/
pdf
链接——需严格按照返回的Feed内容，不进行总结。这是真实的Atom XML Feed；所有字段均为事实数据，切勿编造Feed中不存在的论文、ID或细节。
如果某个分类返回的结果少于2条，去掉搜索词重新尝试该分类的查询（仅使用
cat:<CATEGORY>
）——不要为了达到目标数量而填充不相关结果。如果所有结果都很少，在输出中说明，而非编造发现。
注意事项： arXiv要求每次仅发起一个请求，且请求间隔需几秒。请逐个分类获取数据，不要并发请求。

Phase 2 — Diverge (read each paper in isolation)

阶段2 — 发散（独立阅读每篇论文）

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.
针对第一阶段收集到的每篇论文，发起并行的Agent/任务调用。每篇论文对应一次调用。每个Agent仅能获取：
  • 构建问题
  • 该单篇论文的标题、摘要、作者、年份——无其他论文信息
  • 以下指令
您处于发散阅读模式。您仅拥有一篇论文的标题和摘要，以及一个构建问题。您不知道其他论文的存在——请勿假设、编造或提及更广泛的调研内容。 请像为即将从零开始构建指定内容的人调研现有研究一样阅读此摘要。除少数连续词汇外，请勿直接引用摘要原文——请用自己的话转述。 提取以下内容：方法（1-2句话，核心机制）、可借鉴点（1句话，最具体的可实现要点——需为祈使句：“使用X来实现Y”；若关联性较弱，请直接说明）、局限性（1句话，关键弱点或失效场景）、相关性说明（针对指定问题的适配性短句）。 仅输出JSON格式：
{"approach":"...","borrow":"...","limitation":"...","relevanceNote":"..."}
关键原则： 这些调用必须是并行且独立的。如果某个阅读调用提到“与这里的其他论文相比”或“这些论文共同表明”，说明独立性已被破坏——丢弃该结果并重新单独运行该阅读调用。

Phase 3 — Converge (one path, not a shortlist)

阶段3 — 收敛（单一路径，而非候选列表）

After all reads return:
  1. Score. Rate each reading 0-10 on: relevance (fit to the stated problem), practicality (buildable by a small team without exotic infra), rigor (does the abstract itself show real evidence — benchmarks, proofs, a shipped system — vs pure concept). Flag a "trap" when a paper's own stated limitation implies a failure mode a builder would otherwise rediscover the hard way. Always pair it with a "strength" — the one concrete thing that paper's approach gets right.
  2. Cluster. Group readings into 3-6 clusters by underlying architectural angle (not by paper, not by keyword): "cache-invalidation plays", "consensus-free plays", "learned-index plays".
  3. Pick ONE. Choose the cluster with the strongest relevance + practicality combination — not the most novel, not the most cited, the one an engineer should actually build. This is the point of departure from wide-open brainstorming: NeuroArxiv commits to a single recommendation, because "here are 4 papers, you decide" is exactly the time-wasting the skill exists to prevent.
  4. Synthesize. For the chosen cluster, produce: a 4-8 sentence implementation sketch (actionable, not a lit-review summary), citations (paper id + title + url + role — "primary mechanism" / "supporting evidence" / "failure mode to avoid" — grounded only in fetched data), the first concrete step, the load-bearing risk, and an "avoid" list pulled from every paper's limitation (not just the winner's — a pitfall named by a paper in a rejected cluster is still worth avoiding).
  5. Name the runner-ups. One honest sentence per non-chosen cluster on the real trade-off that lost it the pick. Not a dismissal — the builder should be able to switch paths later knowing why.
  6. One open thread. A question the read papers raise but don't answer — worth a design-review checkpoint before shipping.
所有阅读结果返回后：
  1. 打分：为每个阅读结果从0-10打分，维度包括：相关性（与指定问题的适配度）、实用性（小型团队无需特殊基础设施即可实现）、严谨性（摘要是否展示了真实证据——基准测试、证明、已上线系统——而非纯概念）。当论文自身提及的局限性暗示了构建者可能会重新踩坑的失效模式时，标记为“陷阱”。需始终搭配说明其“优势”——该论文方法的一个具体可取之处。
  2. 聚类：将阅读结果按底层架构角度（而非按论文或关键词）分为3-6个聚类，例如：“缓存失效方案”“无共识方案”“学习型索引方案”。
  3. 选择唯一方案：选择相关性+实用性组合最强的聚类——并非最新颖或引用量最高的，而是工程师实际应该采用的方案。这是从开放式头脑风暴转向明确方案的关键：NeuroArxiv会给出单一推荐，因为“这里有4篇论文，您自己决定”正是本技能要避免的时间浪费。
  4. 综合整理：针对选定的聚类，生成：4-8句话的实现草图（可落地，而非文献综述）、引用（论文ID+标题+URL+作用——“核心机制”/“支撑证据”/“需避免的失效模式”——仅基于获取的数据）、第一个具体步骤、关键风险，以及从所有论文的局限性中提取的“避免事项”列表（不仅限于选中聚类的论文——被淘汰聚类的论文提及的陷阱也值得避免）。
  5. 说明落选方案：为每个未被选中的聚类用一句话说明真实的取舍原因。不要否定这些方案——构建者后续切换方案时应了解落选的原因。
  6. 遗留问题：阅读的论文提出但未解答的一个问题——值得在上线前的设计评审中重点讨论。

Output shape

输出格式

  1. Searched. Categories, search terms, paper count.
  2. Papers read. Grouped by cluster. Each paper: id, title, one-line approach, score chips 
    [rel8 prac6 rig7]
    .
  3. Prior-art pitfalls. Papers whose limitation flags a real trap — listed separately as watch-outs, not verdicts.
  4. THE PATH. The one chosen cluster: sketch, citations, first step, load-bearing risk, avoid-list. This is the deliverable — make it bold and unmissable, not buried under the paper list.
  5. Alternates considered, not chosen. One line each.
  6. Open thread. The unanswered question.
  1. 检索信息：分类、搜索词、论文数量。
  2. 已阅读论文：按聚类分组。每篇论文：ID、标题、一句话方法、评分标签 
    [rel8 prac6 rig7]
    。
  3. 现有研究陷阱：局限性标记为真实陷阱的论文——单独列为注意事项，而非结论。
  4. 推荐路径：选中的聚类：实现草图、引用、第一个步骤、关键风险、避免事项列表。这是核心交付内容——需突出显示，不要被论文列表掩盖。
  5. 已考虑但未选中的方案：每个方案一句话说明。
  6. 遗留问题：未解答的问题。

Anti-patterns

反模式

  • Cross-contaminated reads. If a paper's read mentions "compared to the other papers here" or "collectively these show", isolation broke — discard and re-run that read alone.
  • Hallucinated citations. Never state a paper detail (a number, a claim, a result) that wasn't actually in the fetched abstract. If unsure, re-fetch rather than infer from the title.
  • Shortlist-as-cop-out. Ending Phase 3 with "here are 3 good options" instead of one recommendation defeats the purpose. Commit.
  • Padding a thin result set. Zero or few relevant papers is a valid, useful finding — it means the mechanism is either genuinely novel or the search terms were wrong. Say so. Don't stretch tangential papers to look like coverage.
  • Treating a paper's abstract as the whole paper. The abstract is a pointer, not ground truth about implementation details it doesn't state. The "borrow" and "avoid" items should stay at the level of what the abstract actually supports.
  • 交叉污染的阅读结果：如果某篇论文的阅读结果提到“与其他论文相比”或“这些论文共同表明”，说明独立性已被破坏——丢弃该结果并重新单独运行该阅读调用。
  • 编造引用内容：切勿陈述未在获取的摘要中出现的论文细节（数字、主张、结果）。若不确定，重新获取数据而非从标题推断。
  • 用候选列表敷衍：第三阶段结束时给出“这里有3个不错的选项”而非单一推荐，违背了本技能的初衷。必须给出明确选择。
  • 填充稀疏结果集：零或少量相关论文是有效且有用的发现——这说明该机制要么真正新颖，要么搜索词不合适。直接说明即可。不要强行扩展不相关论文来凑数。
  • 将论文摘要等同于整篇论文：摘要是一个指向性内容，而非未提及的实现细节的事实依据。“可借鉴点”和“避免事项”应仅基于摘要实际包含的内容。

Calibration

校准

  • How many papers? Default 4 per category × 3-5 categories ≈ 12-20 papers. Scale down for narrow/well-known mechanisms (2 per category is enough when the space is small), up for genuinely unclear territory.
  • When to stop widening? If a category-only retry (terms dropped) still returns nothing usable, say so and move on — don't cascade into unrelated categories chasing a result count.
  • 论文数量：默认每个分类4篇 × 3-5个分类 ≈ 12-20篇论文。针对狭窄/知名的机制可减少数量（当领域较小时，每个分类2篇足够），针对真正不明确的领域可增加数量。
  • 何时停止扩大范围？ 如果去掉搜索词后重新尝试分类仍无法获得可用结果，说明情况并继续——不要为了凑结果数而扩展到无关分类。

Cost

成本

1 categorize + N isolated reads (typically 12-20) + 1 score + 1 cluster + 1 converge ≈ N+4 Agent-shaped calls, plus real arXiv HTTP fetches (~3s courtesy delay between categories). Not for every design decision — for the ones where getting the architecture wrong costs real rework.
1次分类 + N次独立阅读（通常12-20次） + 1次打分 + 1次聚类 + 1次收敛 ≈ N+4次Agent调用，加上真实的arXiv HTTP请求（分类间需约3秒的礼貌延迟）。并非适用于所有设计决策——仅适用于架构错误会导致实际返工成本的决策。

Companion library and CLI

配套库与CLI

This repo also ships a Node/TS implementation (
src/
) that runs the same loop against real arXiv HTTP and the Claude Agent SDK — useful outside Claude Code, for scripted/batch runs, or when you want the fetch and parsing to be deterministic code instead of a WebFetch call.
npm install
npm run build
neuroarxiv "how should I cache LLM completions across requests?"
The skill above gives you the same loop inside Claude Code with no install required.
本仓库还提供了Node/TS实现（
src/
目录），可针对真实arXiv HTTP接口和Claude Agent SDK运行相同流程——在Claude Code之外也可使用，适用于脚本化/批量运行场景，或当您希望获取和解析过程为确定性代码而非WebFetch调用时。
npm install
npm run build
neuroarxiv "how should I cache LLM completions across requests?"
上述技能让您无需安装即可在Claude Code中运行相同流程。