read-arxiv-paper
- Repo stars 54,549
- Author updated Live
- Author repo nanochat
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @karpathy · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: read-arxiv-paper
description: Use this skill when asked to read an arxiv paper given an arxiv URL You will be given a URL of a…
category: other
runtime: no special runtime
---
# read-arxiv-paper output preview
## PART A: Task fit
- Use case: Use this skill when asked to read an arxiv paper given an arxiv URL You will be given a URL of an arxiv paper, for example: https://www.arxiv.org/abs/2601.07372 The goal is to fetch the TeX Source of the paper (not the PDF!), the URL always looks like this: makes outbound network calls. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Part 1: Normalize the URL / Part 2: Download the paper source / Part 3: Unpack the file in that folder” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use this skill when asked to read an arxiv paper given an arxiv URL You will be given a URL of an arxiv paper, for example: https://www.arxiv.org/abs/2601.07372 The goal is to fetch the TeX Source of the paper (not the PDF!), the URL always looks like this: makes outbound network calls. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Part 1: Normalize the URL / Part 2: Download the paper source / Part 3: Unpack the file in that folder” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/src`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Part 1: Normalize the URL / Part 2: Download the paper source / Part 3: Unpack the file in that folder”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: read-arxiv-paper
description: Use this skill when asked to read an arxiv paper given an arxiv URL You will be given a URL of a…
category: other
source: karpathy/nanochat
---
# read-arxiv-paper
## When to use
- Use this skill when asked to read an arxiv paper given an arxiv URL You will be given a URL of an arxiv paper, for exa…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Part 1: Normalize the URL / Part 2: Download the paper source / Part 3: Unpack the file in that folder” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "read-arxiv-paper" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Part 1: Normalize the URL / Part 2: Download the paper source / Part 3: Unpack the file in that folder
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} You will be given a URL of an arxiv paper, for example:
https://www.arxiv.org/abs/2601.07372
Part 1: Normalize the URL
The goal is to fetch the TeX Source of the paper (not the PDF!), the URL always looks like this:
https://www.arxiv.org/src/2601.07372
Notice the /src/ in the url. Once you have the URL:
Part 2: Download the paper source
Fetch the url to a local .tar.gz file. A good location is ~/.cache/nanochat/knowledge/{arxiv_id}.tar.gz.
(If the file already exists, there is no need to re-download it).
Part 3: Unpack the file in that folder
Unpack the contents into ~/.cache/nanochat/knowledge/{arxiv_id} directory.
Part 4: Locate the entrypoint
Every latex source usually has an entrypoint, such as main.tex or something like that.
Part 5: Read the paper
Once you've found the entrypoint, Read the contents and then recurse through all other relevant source files to read the paper.
Part 6: Report
Once you've read the paper, produce a summary of the paper into a markdown file at ./knowledge/summary_{tag}.md. Notice that 1) use the local knowledge directory here (it's easier for me to open and reference here), not in ~/.cache, and 2) generate some reasonable tag like e.g. conditional_memory or whatever seems appropriate given the paper. Probably make sure that the tag doesn't exist yet so you're not overwriting files.
As for the summary itself, remember that you're processing this paper within the context of the nanochat repository, so most often we will be interested in how to apply the paper and its lessons to the nanochat project. Therefore, you should feel free to "remind yourself" of the related nanochat code by reading the relevant parts, and then explicitly make the connection of how this paper might relate to nanochat or what are things we might be inspired about or try.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review