| name | go |
| description | Reads and summarizes ONE specific paper. Triggers on "read this paper", "summarize X", or when the user gives a specific paper title/link. |
go — paper reading & summary
Process
- Fetch the paper. If given a link, use WebFetch to retrieve it. If only given a name/title, use WebSearch first to locate the canonical source (arXiv, venue page, OpenReview) before fetching.
- Extract the core structure. Pull out: problem statement, method/approach, key results (with actual numbers, not vague claims), and stated limitations. Don't skip limitations — authors' own caveats are high-signal.
- Note venue and year. Record whether this is a peer-reviewed publication or an arXiv-only preprint, and the year.
- Write a structured summary note. Create a per-paper Markdown file under
_papers/ with sections for Problem, Method, Results, Limitations. Cite the paper itself at the top using the Markdown link citation format:
[Authors et al., Year — Title](link)
- Flag claims needing verification. If the paper makes a strong or surprising claim, flag it inline (e.g. "⚠ needs check") rather than silently accepting it — defer the actual verification to
citation_accuracy / source_verification, this skill only flags.
Anti-Rationalization
- "The abstract covers it" — the abstract oversells by design; always check the results section for the actual numbers before summarizing.
- "Limitations section is boilerplate" — authors often bury the real caveat there; read it, don't skip it.
- "I'll just paraphrase the conclusion" — a summary without concrete results/numbers is not a summary, it's a restatement of marketing copy.
Evidence
A summary is complete when: problem/method/results/limitations are all present, at least one concrete result number is quoted, venue and year are recorded, and the paper is cited with a working Markdown link.
Red Flags
- Summary with no numbers, only qualitative claims
- Limitations section omitted entirely
- Venue/year not recorded (can't tell preprint from published work)