In-Depth Paper Analysis & Presentation Material Generation

Transform one paper into five complementary deliverables: readable (in-depth reading), presentable (terminology + PPT), accurately positioned (citation context), and actionable (ideas).

The reason this skill exists: The real failure mode of a paper presentation is not "not doing enough," but misreading the paper and then making a 20-slide PPT. Therefore, the workflow prioritizes "verify first, then generate" over "maximize output."

Default Language & Delivery Format

When the user does not specify a language, the main text, PPT, script, and Word documents default to Chinese; paper titles, authors, model names, dataset names, formulas, DOIs, arXiv IDs, and code commands remain in their original language.
Deliverables A, B, D, E, and the new F (PPT Page-by-Page Script) are ultimately delivered as .docx. Do not use .md as the primary delivery file for the user. Markdown can serve as an internal draft, but before delivery, it must be converted into a well-structured, directly readable Word document.
The Word document should be more detailed than the PPT: provide a one-sentence conclusion first, then explain the background, method, evidence, limitations, and reproducibility; introduce technical terms on first appearance as "English (Chinese)" with an easy-to-understand explanation.
Word paragraphs should use native bullet or numbered styles, with left indentation and hanging indentation; do not manually type characters like • or 1、 into the text. Each coordinate paragraph must have a clear identifier and hierarchy level.

Step 1: Collect Parameters (Ask for Missing Items, Do Not Assume for the User)

Ask all questions at once, avoiding a back-and-forth, piecemeal interrogation:

Parameter	Why It Must Be Asked
Paper Source	File path / Title / DOI / arXiv ID. If a title is given, first verify it leads to a unique match before proceeding – many papers share the same title, and a retrieval error invalidates the entire deliverable set
Presentation Context	Group meeting literature report / Thesis proposal / Course pre / Thesis defense. Determines the level of detail and tone. PPT layout and style, regardless of context, must follow the example template `references/group-meeting-template.md` (originating from `references/group-meeting-sample.pptx`), maintaining consistency in style, font, and format
Audience	Same-field graduate students? Cross-field students? Advisor present? Determines how much terminology needs to be explained
Time & Page Limit	A 15-minute deck and a 30-minute deck have double the density. The page limit is more effective at constraining layout than "explain it clearly."
Language	Default Chinese; technical terms, titles, authors, model names, dataset names, and formulas retain their original English words, unless the user specifies otherwise
Output Directory	Specify an absolute path to avoid files scattering in temporary directories; text materials default to `.docx` output
Idea Delivery Format	Default output is the detailed `05_idea.docx`; if the user explicitly asks for "each idea as a separate file," split them into multiple `.docx` or single-page `.pptx` files following `references/idea-docx.md`
Search Tool	Does the user have an Undermind account? If yes, ask the user to run a search and paste the results, while simultaneously cross-validating with free sources (see `references/literature-search.md`)

Follow up on descriptions like "first presentation." This usually means the user is also a novice, making the "Limitations and My Thoughts" slide especially critical (it's where advisors ask the most questions), while methodological details can be appropriately condensed.

Step 2: Read Through, Then Pause and Confirm

Use the pdf skill to read the full text completely – main body + equations + figures + tables + references + appendices. Reading only the abstract before starting work is the #1 mistake this skill aims to avoid: a paper's actual contribution often differs from its abstract, and conclusions from ablation studies are frequently downplayed in the abstract.

After reading, first, deliver only a one-page outline: a one-sentence summary of the paper + PPT table of contents + filenames of the five deliverables. Get user confirmation before generating the formal deliverables.

This step may seem like a waste of time, but it's actually the most time-saving: if a misunderstanding is caught here, it only takes three lines to correct; if a misunderstanding is caught after the PPT is finished, everything must be redone.

Step 3: Five Deliverables

Detailed writing templates can be found in references/analysis-templates.md (itemized lists for deliverables A, B, and E).

Deliverable A: In-Depth Reading → 01_Paper_Deep_Read.docx
Deliverable B: Technology & Terminology → 02_Tech_and_Terms.docx
Deliverable C: Presentation PPT → 03_Presentation.pptx (For any presentation context, first read references/group-meeting-template.md and references/ppt-reference-notes.md; the primary base is references/group-meeting-sample.pptx, other templates are only used to absorb layout experience)
Deliverable D: Related Work & Citation Context → 04_Related_Work.docx (Search sources, APIs, anti-hallucination rules are in references/literature-search.md)
Deliverable E: Extendable Ideas → 05_Ideas.docx
Deliverable F: PPT Page-by-Page Script → 06_PPT_Script.docx

Text materials must be detailed enough for the user to read and present directly: every major conclusion should state its basis, meaning, limitations, and next steps; do not compress complete explanations into PPT-style short sentences to save space.

Deliverable F: Page-by-Page Script Rules. Every PPT slide must have a corresponding script; do not generate only an overview or repeat the slide text. Each slide's script must include at least: the question this slide aims to answer, an explanation of the slide's content in layman's terms, how to read the charts/formulas/flowcharts, the paper's evidence source, a relatable analogy or concrete example if necessary, and a transition to the next slide. The script should sound like a person explaining in a group meeting, not reading a title; start with the intuitive scenario, then introduce the English term and numbers. Clearly distinguish between "facts proven by the paper," "interpretations based on the charts," and "the presenter's inferences/next steps."

Examples in the script must serve understanding and must not introduce new facts unsupported by the paper. When involving models, datasets, metrics, figure numbers, or numbers, use the sources from the PPT and the paper; examples can use analogies like "restaurant meal sets, warehouse picking, city roads, expert teams, image compression" but require a clear statement that they are only analogies for understanding. The default suggestion is 40–90 seconds per slide; method, experiment, and limitation slides can be longer.

Hard Rules

These are the bottom-line requirements for a deliverable to be considered ready, more important than any formatting requirement:

Do not fabricate literature. Citation context is the most prone part to failure – LLMs fluently generate plausible but non-existent paper titles, authors, and years. The rule is: every citation must have a verifiable link (DOI / arXiv ID / conference page); if it cannot be found, it's better not to include it; if subsequent citations cannot be retrieved, explicitly state "no citations found yet / the paper is very recent," do not pad the list to 5 entries. The user would rather have 2 real citations than 10 fabricated ones.

Separate facts from interpretations. What the paper's text says is one thing; what you interpret is another. When the user presents this material, the advisor may ask, "Did the author say this, or are you inferring it?" Therefore, all speculative statements must be marked with [Inference].

All numerical values must have a source. Every metric and conclusion must be accompanied by a section number / figure number / table number / equation number. This is not just about rigor – it allows the user to immediately flip to the original page when questioned.

Write terms as "English (Chinese)." Chinese translations for technical terms are highly inconsistent (e.g., "attention" can be translated as "注意力" or "关注"). Keeping the original English word allows the user to search for it. Provide a Chinese explanation on first occurrence, then use the English term directly afterward.

Every slide must have the Central South University logo. All PPT pages – including the cover – must display the CSU logo (asset references/assets/csu-logo.png). For inner pages, place it uniformly in the top right corner (L=10.42" T=0.18" W=2.38" H=0.66"); on the cover page, place it in the same top right position. Ensure the logo is on every page from the first to the last, in a consistent position, and not obscured by other elements.

Paper figures must be complete; text outside the figure must be cleaned. When extracting a figure from the paper, retain the axes, ticks, curves, bars, sub-figures, and essential legends needed for the current conclusion; delete the paper headers, footers, page numbers, Figure numbers, Figure captions, main body paragraphs, and unrelated author information. Data within the figure must not be truncated; explanatory text outside the figure must not be brought into the PPT. Prioritize using scripts/extract_pdf.py figures to extract original figures; if that fails, render the full page at --dpi 300 then crop, and visually inspect each cropped figure.

Three-round layout check before delivery. After completing Deliverable C, three rounds of inspection are mandatory: (1) Run scripts/check_deck.py; all ERRORs must be zero, and WARNINGs must be individually confirmed; (2) Open the PPT and visually inspect it completely, specifically checking overall structure, text overflow, overlapping elements, cropped images, and the logo on every page; (3) Go through the checklist slide by slide, verifying font and size consistency, CJK-English alignment, figure notes not overlapping images, and complete speaker notes. If any round finds a problem, correct the deliverable and re-run all rounds.

Announce the completion of each deliverable. If all six materials are delivered at once, the user faces six unknown files; delivering them one by one allows the user to correct course during the process.

Text materials default to Chinese Word delivery. A, B, D, and E must be delivered as .docx, with a structure including a title, summary-like conclusion, hierarchical subheadings, native bullet points, tables, citation links, and "Author Fact / My Interpretation / Not Yet Verified" markers. Unless the user explicitly requests it, do not deliver only Markdown.

PPT must have a white background, text-image zoning, and font sizes large enough. Use a white page background and dark text; the title can use the sample's dark red color; avoid placing text on color blocks or large background color patches. Each page should preferably use one of four zones: text on the left with figures on the right, figures on the left with text on the right, text on top with figures below, or figures on top with text below. Figures and text should each occupy about half the space, with safe margins to prevent text, figures, and captions from intermingling. Body text should preferably be 22–24pt, titles around 30pt; if space is insufficient, split the page or shorten content, do not reduce the font size.

PPT structure labels and table of contents rules. Do not generate "Outline," "Table of Contents," "Agenda," "Contents," or any separate PPT overview page. After the cover page, go directly to the first content slide. The presentation structure is indicated by page order, speaker notes, and a concise English section label on each content slide. Every content slide must have a concise section label, chosen from: Background, Motivation, Problem, Related Work, Method, Design, System, Implementation, Evaluation, Results, Ablation, Limitations, Takeaways, Q&A. Section labels are only for positioning the current module; do not write them as complete sentences or repeat the main title. Page titles should use Chinese topic sentences. Unless the user explicitly requests it, do not replace content slides with a table of contents page.

PPT template reuse rules (highest priority). When generating the PPT, first use the complete template file provided by the user. The current global resource is references/group-meeting-template.pptx, sourced from skills补充/20260525_组会(1).pptx. Prioritize copying existing pages from the template that have the "title + body text + image below" layout, then replace the text and images; preserve all existing title boxes, body text boxes, horizontal lines, margins, fonts, colors, line spacing, indentation, and paragraph levels from the template. Only create a new page if the template truly cannot accommodate the content; new pages must also copy the XML style of the template. The PPT uses a white background and dark text; bullet points must not be placed on color blocks, cards, rounded rectangles, gradient boxes, or any colored background. Do not add decorative bars, side ribbons, or AI-style info cards to fill space.

PPT font and bullet point rules. Titles, subtitles, body text, text on figures, and figure captions must copy the format from the template sample pages; do not independently set fonts, sizes, colors, line spacing, first-line indentation, hanging indentation, or alignment. Body text should use the template's paragraph hierarchy and PowerPoint's native bullet points: if a major point has several sub-points, use a square bullet (e.g., ■) for the major point and an arrow bullet (e.g., →) for the sub-points, maintaining the template's indentation; only when points are fully coordinate should a small arrow be used, not a square. Do not manually write "1, 2, 3", and do not use colored shapes to fake bullet points. Each page typically has about 3 content points, with at most 2-3 major points, each with only the necessary 1-2 sub-points; the body text size must not be smaller than the template's body text size.

PPT comprehensibility rules. Each slide should answer only one question, and the slide title must be a Chinese sentence the audience can directly understand, e.g., "The historical state is too large to keep on the GPU" or "First, save a smaller intermediate state, then restore KV." When a technical term first appears, explain it in simple terms before writing the English term; remove details that do not help the audience understand the paper. The PPT is not a miniature print of the paper; prioritize the problem, core idea, key evidence, and limitations. Write only 2-3 short bullet points per slide; when there is too much text, delete content rather than reducing font size. Speaker notes should carry the supplementary explanation; the slide itself should remain concise.

PPT text-figure position & screenshot rules. Default to a template page layout with "short text on top, large image below." Unless the template already has a left-right layout that is clearly clearer, do not squeeze text and figures into two columns. Paper screenshots must be cleaned first: delete headers, footers, page numbers, Figure numbers, Figure captions, main body paragraphs, unrelated tables, and unrelated author information; retain what's necessary for understanding the data within the chart, such as axes and essential legends; do not add figure titles or explanations outside the figure. After each crop, manually compare the original figure and the cropped figure to confirm the axes, ticks, curves, bars, arrows, and sub-figures are complete. When the original figure cannot be extracted, use 300 DPI page rendering before cropping; screenshots must be clean and cannot be scaled-down full paper pages stuffed into the PPT.

PPT page adjustment rules. After generation, re-examine the overall layout of each slide. Each page should typically retain around 3 simple, easy-to-understand content points; if text is excessive, first delete secondary information or split the page. If a page is too empty, first enlarge the figure below, letting it occupy the main image area, then adjust the body text within the template's allowable limits; maintain the figure's aspect ratio, and if necessary, crop unnecessary white space or unrelated sub-figures, but do not crop the data needed for the current conclusion. Check the visual focus of the title, body text, image, logo, and margins; do not leave large meaningless empty spaces on the lower half of the page for long. No element may overlap, go out of bounds, or obscure the image. Avoid layouts with "every point in its own color block" and placing color blocks under text. Every page should look like it was generated from the same template, not as a collection of auto-generated cards.

PPT paragraphs must have hierarchical identifiers and indentation. Use PowerPoint's native bullet points and indentation within two levels; avoid using "1, 2, 3" or packing multiple sentences into one paragraph. Each point expresses only one idea; bold the first-level points, and use the second level to explain evidence or examples.

Iterative Revision & Delivery Cleanup for Existing Presentations

When a user requests modifications to an existing multi-presentation PPT, follow the closed-loop process below, rather than just adjusting a few text boxes:

First, inventory versions and scope. List all PPTs, Word documents, paper PDFs, screenshot directories, rendering directories, scripts, and inspection reports in the target presentation directory. Distinguish between "final delivery version" and "historical/intermediate versions." The first presentation, user-specified example PPTs, and formal materials not within the scope must not be overwritten.
Prioritize real examples over generalization rules. First, read the actual example PPT's slide layouts, theme, and XML from the user. The title position, body text size, color, line spacing, indentation, page numbers, logo, and bullet points in the example are the final authority; symbols like ■ and → in this skill only indicate hierarchy concepts and cannot replace the example's actual symbols.
Native bullet points must copy XML. If the example's bullet points are implemented via Wingdings, special characters, or theme-level XML, copy the example paragraph's <a:pPr>, <a:buFont>, <a:buChar>, <a:buClr>, indentation, and line spacing. Do not substitute them with Unicode squares, text prefixes, or drawn shapes. After modification, compare font, typeface, color, indentation, and line spacing for each paragraph; record the number of paragraphs passed.
First correct the content evidence, then the layout. Paper screenshots must come from the original figure or a high-DPI page rendering of the paper PDF. Each screenshot retains the axes, ticks, legends, arrows, and sub-figures needed for the current conclusion; clear headers, footers, page numbers, figure captions, main body text, and unrelated areas. After cropping, simultaneously view the original page, the cropped figure, and its actual effect within the PPT; do not replace paper evidence with redrawn fake figures.
Resolve "empty" and "crowded" on a per-slide basis. For empty pages, first enlarge the valid paper figure, crop irrelevant white space, merge figures that have direct evidential relationships, and add one or two "figure interpretation/evidence source" points; do not fill space with decorative color blocks, cards, repeated titles, or unfounded text. For crowded pages, first delete minor sentences, split the page, or shorten sentences; only then adjust dimensions while ensuring the size is not below the example's font size. Maintain image aspect ratio at all times.
Must render for practical acceptance. Do not rely solely on python-pptx XML checks. Render each target PPT as PDF/PNG or use an available Office/WPS viewer to inspect page by page; check title, body text, images, figure notes, logo, page numbers, text overflow, image cropping, overlaps, clarity, and page visual focus. If any page has a problem, correct and re-run the complete check; do not accept "since only this page was changed, a full re-check is unnecessary."
Save a recoverable original, then overwrite or save as. Before batch replacement, create a backup of the original with its path and hash. If the user modifies the original file during processing, do not overwrite their new changes; instead, generate a clearly named "layout-optimized version" in the same directory and note this in the delivery instructions.
Clean up the directory before delivery. Retain only the paper PDF, formal Word materials, and final PPT in each presentation directory; delete or move to the recycle bin older version PPTs, older Word files, rendered PNG/PDFs, screenshot caches, scripts, __pycache__, inspection reports, and temporary assets. Before cleanup, verify that formal Office files can be opened and have no dependencies on deleted external media; record the hashes of retained files. The first presentation and example directories are not included in the cleanup.

The minimum acceptance record for this closed loop should include: target file list, page count, actually rendered page count, number of text overflows, bullet point XML consistency, per-slide notes/logo check results, paper screenshot sources, and a list of formal files retained after cleanup.

Drawing Skill Routing

skills/ project already deploys the following drawing skills. Select the graphic type, and save the generated figures uniformly to the current task's figures/ or delivery directory:

figure-generation: For numerical values, axes, or method comparisons, generates 300 DPI PNG and vector PDF and retains reproducible scripts.
academic-plotting: Best for paper result figures, ablation plots, training curves, heatmaps, and statistical charts; prioritize colorblind-friendly color palettes.
figure-spec: The first choice for architecture diagrams, method overviews, and flowcharts. Uses deterministic JSON → SVG, which is easy to edit, review, and later place in the PPT.
mermaid-diagram: For quickly drawing simple flows, sequences, and relationship diagrams; for formal delivery, convert to editable SVGs or high-resolution images.

For academic figures with dense text or requiring precise labels, do not default to generative images. Generative diagrams are only suitable for qualitative concept diagrams and must be carefully checked item by item for text, arrow directions, module counts, and legends.

Finally: Pre-Delivery Self-Check (Deliverable C Must Undergo Three Rounds)

Round 1: Script Check. Run scripts/check_deck.py; all ERRORs must be zero, and WARNINGs must be individually confirmed. It automatically checks cover page elements, font size minimums, East Asian fonts, image resolution, speaker notes, text overflow, overlapping elements, logo presence on every slide, and images going out of bounds.

Round 2: Overall Visual Inspection. Open the PPT and flip through it completely. Check issues the script cannot find: overall pacing, slide crowding, text boxes obscuring images, images cropped by margins, logo presence and position consistency on every slide, and completeness of cover page information.

Round 3: Slide-by-Slide Checklist. Use the checklist below for each slide. The deliverable is complete only when all points pass:

If any round finds a problem, correct the deliverable and re-run all three rounds from the beginning; do not replace with "only fix this one thing." Post the verification results to the user item by item.

Tools

scripts/extract_pdf.py — Extract text (with page numbers), export embedded images, render pages at specified DPI. Use this to get original figures for PPT images; it's much clearer than screenshots.
scripts/check_deck.py — Check .pptx for cover page elements, font size, image resolution, speaker notes, text overflow, overlapping elements, logo on every slide, and image out-of-bounds.

python scripts/extract_pdf.py text   paper.pdf                 # Extract text
python scripts/extract_pdf.py figures paper.pdf -o figs/       # Extract embedded images
python scripts/extract_pdf.py pages  paper.pdf -o pages/ --dpi 300 --pages 3-7
python scripts/check_deck.py deck.pptx --report check.md

Reference Files

references/analysis-templates.md — Itemized templates and good/bad examples for Deliverables A / B / E
references/ppt-layout.md — PPT structure, layout values, image specifications, and common pitfalls
references/group-meeting-template.md — PPT layout template for paper presentations (default for all contexts), originating from references/group-meeting-sample.pptx: cover structure, title bar 28pt, body text 20pt, three content page layouts, font alignment / image completeness / text-image non-overlap rules, logo on every slide
references/ppt-reference-notes.md — Typography, paragraph, white background, text-figure column, and whitespace rules distilled from the primary example and other user-provided template PPTs
references/group-meeting-sample.pptx — Layout example (final authority for style, font, format; references/_sample_spec.txt is its full specification dump)
references/assets/csu-logo.png — Central South University logo asset, required on every slide
references/literature-search.md — How to do citation context, which sources to use, what to do when Undermind is unavailable, anti-hallucination rules
references/idea-docx.md — Specifications for .docx / single-page .pptx when the user requests "each idea in a separate file"
references/prompt-template.md — A ready-to-copy prompt for users who want to use this in other tools (e.g., claude.ai)

Aa242615/-skills-

-skills- 是什么？

在你喜欢的 AI 中提问

文档

In-Depth Paper Analysis & Presentation Material Generation

Default Language & Delivery Format

Step 1: Collect Parameters (Ask for Missing Items, Do Not Assume for the User)

Step 2: Read Through, Then Pause and Confirm

Step 3: Five Deliverables

Hard Rules

Iterative Revision & Delivery Cleanup for Existing Presentations

Drawing Skill Routing

Finally: Pre-Delivery Self-Check (Deliverable C Must Undergo Three Rounds)

Tools

Reference Files

相关技能

affaan-m/uspto-database

affaan-m/scholar-evaluation

affaan-m/literature-review

affaan-m/everything-claude-code

forrestchang/andrej-karpathy-skills

langgenius/backend-code-review