paper-summarizer
Skill547 starsChanged 3 months agoMITView on GitHub
Agents should invoke this skill for academic or technical papers, arXiv/PubMed/IEEE/ACM links, PDFs, methodology review, limitations, practical implications, or extracting findings for engineering decisions.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 78
Check arXiv, PubMed, Google Scholar for open-access versions
- Distinctive: line 79
If behind a paywall, note this and work with the abstract and any available supplementary material
- Distinctive: line 80
Check for author's personal page (often has preprints)
- Distinctive: line 92
Before paraphrasing implications, list atomic claims the paper makes (results, bounds, contributions).
- Distinctive: line 98
If the answer is "nothing" — still summarize, but note low actionability
- Distinctive: line 99
If the answer is specific — tie each implication to a row in Claim–evidence map where possible
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Paper Summarizer
Extract actionable insights from academic and technical papers.
Summary Format
# Paper Summary: <Paper Title>
**Authors:** [Author list]
**Published:** [Journal/Conference, Date]
**Link:** [URL]
**Quality:** Peer-reviewed / Preprint / Workshop paper
## TL;DR
[1-2 sentence summary of the key contribution]
## Problem
[What problem does this paper address? Why does it matter?]
## Approach
[Methodology in plain language — what did they do?]
## Key Findings
Anchor each finding to the paper so readers can verify. Use **§** for sections, **Fig.** / **Table** when the evidence is visual or tabular.
1. **[Finding 1]:** [Description with key metrics/numbers] — *Evidence:* §[N] [section name]; [Fig. X / Table Y if applicable]
2. **[Finding 2]:** [Description] — *Evidence:* §[N] …
3. **[Finding 3]:** [Description] — *Evidence:* §[N] …
## Claim–evidence map
| # | Claim (one line) | Where in paper | Type |
|---|------------------|----------------|------|
| 1 | [Claim] | §3.2 Results, Table 2 | Empirical |
| 2 | [Claim] | §1 Introduction | Stated goal |
| 3 | [Claim] | Fig. 4 | Qualitative |
Use this table for citation-audit alignment against the project's own research notes. If the PDF has no section numbers, use **page** or **heading text** instead of §.
## Practical Implications
[What does this mean for practitioners? How can we use these findings?]
- For the current stack: [Specific applicability to Rust/TS/Python work]
- For current projects: [How this might inform current work]
## Limitations
- [Limitation 1: e.g., small sample size, specific domain]
- [Limitation 2: e.g., not replicated, theoretical only]
## Related Work
- [Paper 1] — [How it relates]
- [Paper 2] — [How it relates]
## Verdict
**Reliability:** High / Medium / Low
**Relevance to us:** High / Medium / Low
**Action:** Apply directly / Consider for future / Interesting but not actionableProcess
Step 1 — Access the Paper
- Check arXiv, PubMed, Google Scholar for open-access versions
- If behind a paywall, note this and work with the abstract and any available supplementary material
- Check for author's personal page (often has preprints)
Step 2 — Read Strategically
- Abstract — Get the overview
- Introduction (last paragraph) — Usually states the contribution
- Figures and tables — Often convey key results
- Conclusion — Summary of findings and limitations
- Methodology — If the findings are relevant enough to dig deeper
Step 3 — Extract claims with locations
Before paraphrasing implications, list atomic claims the paper makes (results, bounds, contributions). For each: section / figure / table reference (or page). Prefer primary evidence (results section) over abstract-only restatement.
Step 4 — Extract Practical Value
The most important question: "What can we do differently because of this paper?"
- If the answer is "nothing" — still summarize, but note low actionability
- If the answer is specific — tie each implication to a row in Claim–evidence map where possible
Step 5 — Assess Reliability
| Factor | Assessment |
| Peer review status | Published / Preprint / Workshop |
| Replication | Replicated / Single study / Theoretical |
| Sample size | Adequate / Small / N/A |
| Methodology rigor | Strong / Moderate / Weak |
| Author credibility | Established / New / Anonymous |
| Conflicts of interest | None apparent / Funded by [X] / Vendor paper |
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- BryceYuuu/open-workflow-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository54 other files it gives its agents.
- agentic-actions-auditorSkill
- agents-md-improverSkill
- agents-md-reviseSkill
- ai-slopSkill
- code-architectSkill
- code-explorerSkill
- codeqlSkill
- code-qualitySkill
- code-reviewerSkill
- code-reviewSkill
- design-patternsSkill
- differential-reviewSkill
- feature-devSkill
- fp-checkSkill
- frontend-designSkill
- hf-cliSkill
- hf-cloud-aws-context-discoverySkill
- hf-cloud-python-env-setupSkill
- hf-cloud-sagemaker-deployment-plannerSkill
- hf-cloud-sagemaker-iam-preflightSkill
- hf-cloud-sagemaker-production-defaultsSkill
- hf-cloud-serving-image-selectionSkill
- hf-memSkill
- huggingface-bestSkill
- huggingface-community-evalsSkill
- huggingface-datasetsSkill
- huggingface-gradioSkill
- huggingface-llm-trainerSkill
- huggingface-local-modelsSkill
- huggingface-lora-space-builderSkill
- huggingface-paper-publisherSkill
- huggingface-papersSkill
- huggingface-spacesSkill
- huggingface-tool-builderSkill
- huggingface-trackioSkill
- huggingface-vision-trainerSkill
- huggingface-zerogpuSkill
- humanizerSkill
- insecure-defaultsSkill
- mcp-builderSkill
- sarif-parsingSkill
- security-reviewSkill
- security-threat-modelSkill
- semgrep-rule-creatorSkill
- semgrep-rule-variant-creatorSkill
- semgrepSkill
- sharp-edgesSkill
- skill-creatorSkill
- supply-chain-risk-auditorSkill
- train-sentence-transformersSkill
- transformers-jsSkill
- trl-trainingSkill
- variant-analysisSkill
- vuln-reportSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

