summarise-paper

Name: summarise-paper
Author: phira-ai

15stars0forks

How to install summarise-paper?

phira-ai/phi-skills/summarise-paper

$npx -y skills add phira-ai/Phi-Skills --skill summarise-paper

Installs into the current project.

Summary

Use when tasks involve reading and summarising an academic paper from either a PDF file or an arXiv URL. If the input is a PDF, convert it to images for accurate reading (equations/figures). If the input is an arXiv URL, download the LaTeX source to read. Output the summary as a

Files · 1

View on GitHub

SKILL.md

1	# When to use
2
3	- Reading and summarising an academic paper.
4
5	# Workflow
6
7	1. Determine whether the input is a PDF file or an arXiv URL.
8	2. If the input is a PDF file:
9	1. Use `pdftoppm` to convert the PDF into PNG images. Save them under `.cache/{paper name}/` as `[1,2,3,...].png`.
10	2. Read the converted images.
11	3. You MUST read the paper ONLY via these images (not via text-extraction tools). Papers often contain equations, figures, and charts that must be recognised accurately, and text extraction is unreliable for these.
12	3. If the input is an arXiv URL (e.g. `https://www.arxiv.org/abs/2601.07372`):
13	1. Normalise the input by replacing the `abs` in the URL into `src` for TeX source, e.g.: `https://www.arxiv.org/src/2601.07372`.
14	2. Download the source as a local `.tar.gz` archive and store it under `.cache/downloads/{paper name}/`.
15	3. Unpack the archive into `.cache/{paper name}/`.
16	4. Locate the entry point (e.g. `main.tex`) and read all relevant contents, including referenced figures.
17	4. Summarise the paper as a LaTeX research note and write it under `note/{paper name}/`, following the Paper Summarisation Instructions below.
18	5. The output note must be a standalone LaTeX file that can be compiled directly.
19
20	# Paper Summarisation Instructions
21
22	You are a senior researcher searching for new ideas for your next top-tier conference/journal paper. You read papers and summarise them into notes. Your goal is to produce a “weeks-later readable” research note: after reading many papers, I should be able to reconstruct the paper’s core ideas, methods, and evidence, and discuss it intelligently even if I have not read it recently.
23
24	## Core requirements
25
26	- Faithfulness: Use ONLY information supported by the paper. If a detail is missing or unclear, write “Not stated in the paper” (or “Not shown in the provided excerpt”) rather than guessing.
27	- Grounding: Where possible, cite the source of each key claim (section name, figure/table number, equation number, or page number).
28	- Clarity: Prefer intuition-first explanations, then formalisation/maths, then implications.
29	- Completeness: The Methodology section must be self-contained and read as a coherent story from inputs → computations → outputs, including training and inference pipelines if applicable.
30	- Language: You must use British English.
31
32	## Notation rules
33
34	- $\mathcal{C}$ denotes a set.
35	- Bold lowercase $\mathbf{x}$ denotes a vector; bold uppercase $\mathbf{X}$ denotes a matrix.
36	- Uppercase $X$ denotes a random variable; lowercase $x$ denotes a deterministic value.
37	- Use correct LaTeX ($...$ for inline maths, $$...$$ for display maths). Define symbols before using them.
38
39	Write the note using the EXACT structure and headings below:
40
41	### 1. Motivation
42
43	- What problem is being addressed?
44	- What failure mode or limitation of prior work is targeted?
45	- Why it matters.
46
47	### 2. Contributions
48
49	- Bullet list of the paper’s concrete contributions (methods, theory, benchmarks, analyses).
50	- Where possible, separate contributions into “new idea” vs “engineering/implementation” vs “evaluation/protocol”.
51
52	### 3. Methodology
53
54	- MINI-PAPER STYLE, single coherent story.
55	- Write this section as a flowing narrative (like the Methods section of a well-written paper), not as a report or checklist.
56
57	#### Hard constraints
58
59	- No sub-bullets or lettered substeps. Minimal headings are allowed, but prefer continuous prose.
60	- The story must flow in one direction: introduce concepts only when they become necessary.
61	- Each paragraph should lead naturally into the next (use transitions such as “To address this…”, “Concretely…”, “This enables…”, “At inference time…”).
62	- If a critical detail is missing, explicitly write “Not stated in the paper” rather than guessing.
63
64	#### Narrative guidance
65
66	- Present the method in the order the paper itself develops it (often: problem → idea → formulation → algorithm → training → inference → complexity).
67	- Include whichever of the following are relevant, but do not force all items or a fixed order:
68	- Problem setting and assumptions (inputs, outputs, constraints)
69	- Core insight and how it differs from prior work (if discussed)
70	- The main objects/components (model modules, memory, prompts, optimiser, data stream, etc.)
71	- Key equations/objectives (only if present; define symbols before use)
72	- The end-to-end procedure (including the training loop if applicable)
73	- Inference-time behaviour (if different from training or otherwise non-trivial)
74	- Notable implementation details or computational overheads (only if stated)
75
76	### 4. Experimental Setup
77
78	- A short “Implementation checklist”

People who liked this also viewed

6 picks

Type

summarise-paper

15stars0forks

View on GitHub

How to install summarise-paper?

phira-ai/phi-skills/summarise-paper

$npx -y skills add phira-ai/Phi-Skills --skill summarise-paper

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# When to use
2
3	- Reading and summarising an academic paper.
4
5	# Workflow
6
7	1. Determine whether the input is a PDF file or an arXiv URL.
8	2. If the input is a PDF file:
9	1. Use `pdftoppm` to convert the PDF into PNG images. Save them under `.cache/{paper name}/` as `[1,2,3,...].png`.
10	2. Read the converted images.
11	3. You MUST read the paper ONLY via these images (not via text-extraction tools). Papers often contain equations, figures, and charts that must be recognised accurately, and text extraction is unreliable for these.
12	3. If the input is an arXiv URL (e.g. `https://www.arxiv.org/abs/2601.07372`):
13	1. Normalise the input by replacing the `abs` in the URL into `src` for TeX source, e.g.: `https://www.arxiv.org/src/2601.07372`.
14	2. Download the source as a local `.tar.gz` archive and store it under `.cache/downloads/{paper name}/`.
15	3. Unpack the archive into `.cache/{paper name}/`.
16	4. Locate the entry point (e.g. `main.tex`) and read all relevant contents, including referenced figures.
17	4. Summarise the paper as a LaTeX research note and write it under `note/{paper name}/`, following the Paper Summarisation Instructions below.
18	5. The output note must be a standalone LaTeX file that can be compiled directly.
19
20	# Paper Summarisation Instructions
21
22	You are a senior researcher searching for new ideas for your next top-tier conference/journal paper. You read papers and summarise them into notes. Your goal is to produce a “weeks-later readable” research note: after reading many papers, I should be able to reconstruct the paper’s core ideas, methods, and evidence, and discuss it intelligently even if I have not read it recently.
23
24	## Core requirements
25
26	- Faithfulness: Use ONLY information supported by the paper. If a detail is missing or unclear, write “Not stated in the paper” (or “Not shown in the provided excerpt”) rather than guessing.
27	- Grounding: Where possible, cite the source of each key claim (section name, figure/table number, equation number, or page number).
28	- Clarity: Prefer intuition-first explanations, then formalisation/maths, then implications.
29	- Completeness: The Methodology section must be self-contained and read as a coherent story from inputs → computations → outputs, including training and inference pipelines if applicable.
30	- Language: You must use British English.
31
32	## Notation rules
33
34	- $\mathcal{C}$ denotes a set.
35	- Bold lowercase $\mathbf{x}$ denotes a vector; bold uppercase $\mathbf{X}$ denotes a matrix.
36	- Uppercase $X$ denotes a random variable; lowercase $x$ denotes a deterministic value.
37	- Use correct LaTeX ($...$ for inline maths, $$...$$ for display maths). Define symbols before using them.
38
39	Write the note using the EXACT structure and headings below:
40
41	### 1. Motivation
42
43	- What problem is being addressed?
44	- What failure mode or limitation of prior work is targeted?
45	- Why it matters.
46
47	### 2. Contributions
48
49	- Bullet list of the paper’s concrete contributions (methods, theory, benchmarks, analyses).
50	- Where possible, separate contributions into “new idea” vs “engineering/implementation” vs “evaluation/protocol”.
51
52	### 3. Methodology
53
54	- MINI-PAPER STYLE, single coherent story.
55	- Write this section as a flowing narrative (like the Methods section of a well-written paper), not as a report or checklist.
56
57	#### Hard constraints
58
59	- No sub-bullets or lettered substeps. Minimal headings are allowed, but prefer continuous prose.
60	- The story must flow in one direction: introduce concepts only when they become necessary.
61	- Each paragraph should lead naturally into the next (use transitions such as “To address this…”, “Concretely…”, “This enables…”, “At inference time…”).
62	- If a critical detail is missing, explicitly write “Not stated in the paper” rather than guessing.
63
64	#### Narrative guidance
65
66	- Present the method in the order the paper itself develops it (often: problem → idea → formulation → algorithm → training → inference → complexity).
67	- Include whichever of the following are relevant, but do not force all items or a fixed order:
68	- Problem setting and assumptions (inputs, outputs, constraints)
69	- Core insight and how it differs from prior work (if discussed)
70	- The main objects/components (model modules, memory, prompts, optimiser, data stream, etc.)
71	- Key equations/objectives (only if present; define symbols before use)
72	- The end-to-end procedure (including the training loop if applicable)
73	- Inference-time behaviour (if different from training or otherwise non-trivial)
74	- Notable implementation details or computational overheads (only if stated)
75
76	### 4. Experimental Setup
77
78	- A short “Implementation checklist”

People who liked this also viewed

6 picks

Type