abzu-slides

Files (1)

• SKILL.md

SKILL.md (first lines)

# Slides proposal

Write all newly authored slide titles, prose and visual notes in the task's selected output language.
The App configures XeLaTeX and portable Chinese fonts when CJK text is present. Keep source quotations,
formulas, names and text inside original figures intact. Identify each source passage's language before
translation; if it already matches the target language, skip translation and duplicate paraphrases.

The audience is researchers. They should leave able to assess the problem, contribution, mechanism, evidence,
assumptions, boundary, and relation to prior work without first reading the paper. Analyze the argument before
selecting frames. Do not mechanically copy the paper's headings or abstract, and do not use classroom language
such as “lesson”.

Use five audience jobs as the default structure: (1) problem/background, (2) core claim, method or innovation,
(3) experimental results, (4) boundaries, discussion or future work, and (5) summary/takeaway. Rename, split,
or merge these jobs only when the paper's argument is genuinely clearer that way; never omit a job silently.
Use concise, phrase-like declarative frame titles. Aim to keep each title on one line in the selected template;
shorten the claim when it wraps rather than relying on a fixed character count. Keep standalone section-divider
frames and a clickable Overview when the planned length affords navigation pages; omit them when they crowd out
substantive content. Logical sections remain even without divider pages. Never repeat or prefix section names in ordinary frame titles. Within
each section, frame titles must form a connected progression rather than unrelated labels. Do not prefix
section titles with numbers; Overview adds numbering itself.

Each frame has one narrative job and one claim the audience can retain. Let figures, tables, equations,
comparisons, and measured results carry the argument whenever the evidence supports them. Lists are appropriate
for categories, procedures, table reading, or synthesis, but every list frame also needs a prominent `body`
claim, an `equation`, or a source figure; a title followed only by bullets has no visual focus. A dense evidence frame may combine a
short claim with a source visual or display equation; a sparse frame is useful only when the argument genuinely
needs a transition or emphasis. Variation in density is a secondary presentation benefit, not the outline logic.

The App offers these low-token deterministic layouts when they fit:

- `single`: one titleless sentence in `body`, centered at the standard sparse-page size. Use it for a claim
  that genuinely deserves an isolated beat; do not simulate it with an empty titled frame.
- `question-list`: one key question in `body` plus 2–6 concise answers in `bullets`; keep `title` empty.
- Formula explainer: a one-line `title`, one `equation`, and a short `body` or useful list.
- Figure explainer: a one-line `title`, `visual_note`, source figure, and a short `body` or useful list for a
  single figure; multi-figure comparisons reserve the page for figures and the note.
- Focus sequence: use two or more consecutive `focus` frames with empty titles and body only. Each frame adds
  one new sentence; the App carries all earlier sentences forward in gray and renders only the new sentence in
  black. All lines use the same size. A non-focus frame or a new section ends the sequence, so each sequence
  remains one coherent line of thought. Write only the new sentence in each proposal frame.

These layouts are options, not a complete design system. Keep freely composed statement, figure-plus-text,
and multi-figure comparison frames when they communicate the evidence better; vary silhouettes deliberately.

Questions are optional. Use one only when it exposes a real unresolved tension; never repeat what the section
or frame title already says and never ask merely to create a sparse page. For a motivation, conceptual buildup,
or forward-looking discussion with no useful figure, table, or equation, prefer a short consecutive focus
sequence over disconnected questions or repetitive lists. `question` followed by `answer` remains a two-step
focus sequence for compatibility; use `focus` when the thought needs more than two steps. Never add “Guiding
question:” or put a question in a bullet. Use `equation` for one important
display formula, writing only the LaTeX math body without `$`, `\[` or `\]`; inline math in prose must use
`$...$`. Other body styles are `statement` and `takeaway`. Every figure frame uses the separate
`visual_note` field for one short italic sentence that tells the audience why to inspect the figure. List styles
are only `bullets` and `steps`. Avoid cards, pills, badges, dashboard
panels, ornamental quote treatments, and repeated color boxes.

Use one sans-serif family throughout. Express hierarchy only with size, weight, alignment, spacing, and
restrained sans-serif italic for the figure note. Keep established technical terms such as token,
Self-Attention, BLEU, Query/Key/Value and LayerNorm unchanged. Do not paste long source paragraphs or expose
planning notes.

Inventory all available source figures, architecture diagrams, result plots and tables before outlining.
When the user's page budget permits, use every figure that contributes to the argument; omit only duplicates,
decorative material, or figures that cannot be explained. Prefer one dominant source figure per frame. Put
two or three figures on one frame only when they are variants, comparisons, or parts of the same reading task.
The App supplies a compact source caption under every figure and shortens overly long captions to protect the
layout. For every figure frame, write one short
`visual_note` above it that says what the figure helps the audience see; do not restate the caption. Existing
supporting_outputs from summary/report may guide emphasis, but the paper evidence remains authoritative.

Every frame must cite one or more current-paper `evidence_refs`; include their union in the top-level
`evidence_refs`. The App uses these internally for verification and does not render a citation footer. When
visible attribution matters, write a concise human-readable author/year citation in the frame itself. Never
show raw EvidenceRef strings or transport tokens.

## Plan before drafting frames

The user-approved short-deck benchmark below is the reference for compact research presentations. Apply its
prioritization and visual clarity, not its paper-specific content or a mandatory ten-page structure.

After reading the paper and inventorying visuals, make a compact page-by-page plan before drafting prose:

1. Identify the paper's central contribution and what researchers must understand to evaluate it. Rank supporting
   material as essential, useful, or expendable; do not allocate equal space to every topic.
2. Reserve room for the central contribution first. For an architecture paper such as Attention Is All You Need,
   the model architecture and its working mechanism deserve multiple explanatory frames, not one squeezed diagram
   after several motivation pages. Other papers may instead center a result, dataset, or theoretical argument.
3. Set the total budget and decide whether Overview and section-divider pages earn their space. Under a tight
   budget (commonly ten pages or fewer), normally omit both and fold motivating questions into content frames.
   Retain direct, concise content titles on these frames; avoid spending two pages on a question and its answer.
4. Assign each planned page a content title, takeaway, source visual/equation/evidence, and narrative job. Cover
   the five audience jobs through content, not necessarily five sections. Record what is cut or merged and why.
5. Check the physical page total and whether the core contribution is actually explained. If it does not fit,
   remove navigation and repeated setup before cutting the mechanism or decisive evidence. Then draft the proposal.

Planning is a composition step, not another model/tool round trip or a new approval gate. Do not render the plan
in the deck or add unsupported planning fields to the proposal. Return only this complete proposal:

```json
{
  "schema_version": "abzu-slides-proposal/1.0",
  "paper_id": "paper-...",
  "expected_revision": 0,
  "title": "...",
  "subtitle": "...",
  "author": "...",
  "institute": "...",
  "max_pages": null,
  "include_overview": true,
  "section_dividers": true,
  "evidence_refs": ["evidence-..."],
  "references": [{"authors": "...", "title": "...", "venue": "...", "year": "...."}],
  "sections": [{
    "title": "...",
    "frames": [{"title": "...", "body": "...", "body_style": "statement", "bullets": ["..."], "list_style": "bullets", "equation": "", "visual_note": "...", "figure_source_refs": [], "evidence_refs": ["evidence-..."]}]
  }]
}
```

From zhangzejing/ThinkReader, MIT.

More from zhangzejing/ThinkReader