Try Eat Lecture Notes

TRY-EAT Lecture Notes

Create a coherent self-study or instructor-edition lecture note, not a slide dump. Preserve the source's technical meaning while rebuilding its teaching sequence around questions, representation changes, evidence boundaries, and active practice.

Required outcome

Deliver an editable XeLaTeX project and its compiled PDF. Unless the user requests another layout, use the files in assets/ and organize the output as:

<output-folder>/
|-- main.tex
|-- tryeatnotes.sty
|-- chapters/
|-- figures/
|-- source-map.md
|-- source-coverage.md          (required in exhaustive coverage mode)
|-- source-coverage.json        (machine-readable coverage ledger)
`-- <descriptive-name>.pdf

Keep source-map.md traceable to slide/page numbers or Markdown headings. Repair verified source errors in the notes and retain correction evidence in internal records. Do not invent citations, turn examples into general results, or strengthen claims beyond the input evidence.

Incremental maintenance of an existing project

For an existing lecture-note project, read references/incremental-maintenance.md before reading source decks or changing notes. Plan from local source/artifact fingerprints and the project learning profile; preserve accepted chapters and analyze only new/modified content and affected dependencies. No changes means reuse the existing deliverable, not regenerate it. Use scripts/incremental_state.py for file-level planning and safe checkpoints. The user's accepted depth is a baseline for new content, not permission to rewrite finished chapters or a page-count target.

Exhaustive coverage and insufficient-detail revisions

When the user asks for all content, no omissions, detailed coverage of each slide, or says existing notes are not detailed enough, read references/exhaustive-notes.md. Compare the sources with the existing instructional body before revising. Cover meaningful source details in integrated explanatory notes; neither a source-slide appendix nor a raw extracted-text appendix substitutes for this work.

Respect output preferences independently of completeness. For text-only or notes-only requests, do not embed slide bodies, screenshots, facsimiles or a page-by-page transcript appendix. When source-page references are unwanted, keep all deck/page identifiers and coverage records outside the final PDF. Internal source-map.md and source-coverage.json retain provenance. Removing an appendix or page labels must not remove the course content: rewrite its meaningful material into the main chapters.

Use a page-level inventory and a semantic-unit ledger for definitions, equations, algorithm steps, examples, tables, visual relationships, conditions and limitations. Page counts, extracted character counts and one heading per slide do not establish completeness. Report unverified content honestly; do not mark an unresolved visual or damaged equation as covered merely because its page is listed.

Source-aligned depth, objectives, and notation

For detailed slide-to-note requests, the acceptance target is an independently learnable account of the supplied material and its learning objectives. Preserve each meaningful example, table entry, equation, diagram relationship, comparison, caveat and classroom question. Reconstruct the explanation around them rather than substituting a convenient example, broad summary, longer glossary or unrelated advanced material. State the source learning objectives and map them to sections and observable exercises; keep source provenance and editorial additions traceable in internal records.

Read references/depth-and-notation.md when authoring or revising detailed notes. Define every symbol locally before its first substantive use, including its object type, domain or index range, vector/matrix shape, conditioning direction and relevant conventions. A notation table is a lookup aid, not a replacement for explanation near the formula. Explain derivation steps and why they are valid, then reproduce source calculations with their original data and interpretation. Every exercise needs sufficient inputs and a worked answer, not an answer-shaped slogan.

Treat a request for greater detail or tighter source alignment as a content revision even when source hashes are unchanged. Reuse caches and sound explanations, but re-audit the explicitly requested scope; a previous covered flag or a file-level no_op cannot override the new quality request. Do not record a newly expanded version as user-accepted until the user actually accepts it.

Correct knowledge and clean reader-facing prose

The final notes teach the corrected content directly. Fix verified typos, malformed notation, arithmetic, signs and inconsistent tables; do not reproduce a known error in the main body merely to announce that the source is wrong. Put original values, evidence, changes and repair choices in source-corrections.md or the coverage ledger. If a repair is not unique, state the modeling convention only where needed to use the result, without claiming to know the author’s intended value. Preserve legitimate technical notation: verify an unfamiliar token before changing it, and explain meaningful suffixes or special characters locally.

Write as a coherent textbook, without recurring phrases such as “原材料指出”, “原文写成”, “原例”, “教学补充” or commentary about how the notes were assembled. Keep mathematical assumptions, useful qualifications and necessary citations; move source comparisons and maintenance history outside the reader-facing PDF. Source alignment means faithful learning goals and correct substance, not retention of mistakes or repetitive attribution.

When asked to update this skill, update the existing installed skill at the user-provided/original location, including affected references; a staged workspace copy alone is not completion.

Route the work

1. Read references/pedagogy.md before planning chapter structure or writing questions.
2. Read references/input-conversion.md for the actual source type. Follow its PDF-slide or Markdown branch; use both for mixed inputs.
3. Read references/latex-style.md before authoring the LaTeX project or changing the style package.
4. Use scripts/extract_source.py for new or changed sources when useful; reuse unchanged extraction/render caches in existing projects.
5. Use scripts/scaffold_project.py only for a new project. Reuse an existing editable project; do not scaffold over or replace it.
6. When output changes, use scripts/build_and_check.py to compile, render, and report structural warnings. For unchanged output, reuse it; for incremental verification, follow the maintenance reference.

Workflow

1. Inspect before restructuring

Identify audience, language, prerequisite level, source order, learning outcomes, equations, figures, citations, examples, and explicit uncertainties. Infer audience and language from the material when the user has not specified them. Keep a source inventory and mark pages with little or no extractable text for visual inspection or OCR. For a first exhaustive reconstruction, enumerate every page before writing chapters. In later incremental runs, retain the inventory and audit only the delta and affected dependencies; do not reread unchanged decks in full. Treat the page image as authoritative for layout, diagrams, tables, labels, and annotations, and treat extracted text as a searchable aid. Create the coverage ledger before drafting and update it as each page is represented in the instructional chapters. Keep internal audit records separate from reader-facing prose.

2. Build a learning map

Write a compact map of:

• the unifying course or chapter question;
• prerequisite concepts and dependency order;
• the smallest running example that exposes the central difficulty;
• representation bridges required by the topic;
• claims and their evidence status;
• checkpoints and question difficulty levels.

Reorder slide fragments only when it improves dependency order. Record meaningful reorderings in source-map.md.

3. Author the chapter as a guided argument

Use this default chapter rhythm when the material supports it:

1. Overview and measurable learning objectives.
2. Concept map, local notation, and a short study route.
3. A deliberately useful opening question or running example.
4. Definitions and mechanisms, with worked examples and representation bridges.
5. Core results, derivations or sourced statements, proof checks, and limits.
6. Common traps and scientific/computational interpretation.
7. A mastery checkpoint and concise checkpoint answer.
8. TRY-EAT activities.
9. Layered exercises, first-move hints, and separated solutions.
10. Historical notes and further reading when the source supports them.

This is a design vocabulary, not a quota. Omit boxes that add no teaching value and never create empty sections merely to match the template.

4. Make TRY-EAT substantive

Treat TRY-EAT as two linked loops:

• TRY - Test, Repair, Yearn: retrieve without notes, repair a named prerequisite with a concrete action, then pose a question that makes the next idea necessary.
• EAT - Explain, Apply, Transfer: explain under a useful constraint, apply to a small observable task, then change a condition or domain and state what still transfers.

Each activity must be answerable from the chapter and must produce observable evidence. Avoid generic prompts such as "review this" or "think about applications."

5. Preserve technical fidelity

Check every newly authored or modified equation, symbol convention, theorem hypothesis, algorithm input/output, complexity variable, metric, baseline, and figure label against the source; on a first reconstruction this covers the entire new body. Reuse existing verified material unless a relevant dependency changes or a correction is requested. For current or external claims, verify only when the user requested updating or fact-checking; otherwise preserve and clearly attribute the source's date and scope.

6. Compile and inspect

When the PDF content changes, compile with XeLaTeX through scripts/build_and_check.py. Inspect rendered changed sections and affected page transitions, equations, tables, TOC and references. On a first build or global layout change, broaden QA to title/front matter, chapter openings, dense equations, floats, exercise transitions and the final page. Reuse the existing PDF when there is no relevant change. In exhaustive coverage mode, reconcile semantic units with the final instructional body and check the requested notes-only/no-source-reference constraints. Do not use the presence of an appendix or page labels as evidence of coverage. Fix all clipping, overlap, missing glyphs, broken references, bad page breaks, and visibly awkward whitespace. Resolve meaningful overfull-box warnings; do not deliver a PDF that has not been rendered and visually checked.

Defaults and boundaries

• Default to a self-study/instructor edition with complete solutions, unless the user requests a student edition.
• Keep solutions after the complete exercise set so retrieval practice remains possible.
• Preserve local figures as editable/vector assets when allowed. For text-only notes, explain diagram nodes, edges, axes, values and conclusions in prose or editable mathematics/tables; do not include slide screenshots.
• Keep prose precise, but do not compress away meaningful source examples, derivation steps or boundary conditions. Requested detail and bilingual terminology take priority over brevity.
• Preserve authorization boundaries: converting supplied material does not authorize publishing, sharing, or changing the source files.