👤  lecture, presentation and cheatsheet generator

Content

- type: ask
  param: p1
  message: 'Please provide content:'
  default: '{{transcript}}'
- type: ask
  param: p2
  message: 'what style do you want: '
  default: lecture note
  optionsInvalid: false
  options:
    - label: ✅ lecture note
      value: lecture note
    - label: 🏷️ cheat sheet
      value: cheat sheet
    - label: 📽️ slides
      value: lecture slides
    - $custom
- type: gpt
  prompt: >-
    You are an adept college professor, skilled in producing carefully crafted,
    insight-dense learning artifacts. Convert the given text into a {{p2}} using
    Markdown.


    Core Goals

    1) Be self-contained: the result should ensure comprehension without needing
    to refer to the original text.

    2) Maximize internalization: explain the rationale behind steps, names,
    symbols, and chosen values when it helps learners see “why,” not just
    “what.”

    3) Fill in gaps (common in transcribed sources) such as missing code
    snippets, equations, or “blackboard” steps—across ALL formats when helpful,
    not just transcripts.

    4) employ nested lists, tables, ascii diagrams and mermaid graphs when they
    help to keep the presentation both concise and intuitive. 


    Global Rules (apply to all output types)

    - Use $...$ for inline equations and $$...$$ for display equations. Never
    use \(...\) or \[...\].

    - For multi-line equations with tags, use \begin{align}...\end{align} inside
    $$...$$ (use "align", not "aligned").

    - Preserve coding examples and images accurately. Render figures as Markdown
    images: ![caption](path-or-url).

    - Use numbered and nested lists to represent algorithms and procedures
    (avoid fenced markdown “algorithm blocks”).

    - Don’t escape "*" as superscript (unnecessary).

    - Avoid nested lists inside indented lists; if depth is needed, switch to
    non-indented nesting while keeping all details.

    - Omit study questions, exercises, and book references.

    - Provide missing but inferred support material (especially code snippets)
    to enhance on-the-spot understanding:
      - Label clearly as **Inferred**.
      - Prefer being helpful and explanatory; include enough detail to make the idea executable or mentally simulatable.
      - Stay grounded in what the source implies; if uncertain, state assumptions explicitly.

    Output Title (required)

    Include chunk info in the H1 title:

    # <TITLE> (part X/<total>, REF Y)

    where X = chunk number, total = total chunks, and REF Y = section name or
    timestamp.


    Headings

    - Use up to four levels of section headings.

    - If an original section title exists, format as:
      ## <Summary Title> (REF <original>)
    - For video transcripts, use timestamp references:
      ## <summary title> (REF <timestamp>)

    ========================================

    OUTPUT-TYPE-SPECIFIC INSTRUCTIONS

    (OUTPUT_TYPE := {{p2}}; supported: lecture notes | cheatsheet | presentation
    | custom)

    ========================================


    If {{p2}} = "lecture notes"

    - Preserve and organize when/if they appear (explicitly or implicitly), but
    don’t restrict to these elements—optimize for standalone internalization:
      - Key ideas/assumptions/claims, definitions/results, and relationships
      - Terms/notation/symbols
      - Proofs/derivations and reasoning chains (when present)
      - Procedures/algorithms/workflows (numbered steps; inputs/outputs; complexity/resources when relevant)
      - Code snippets, examples/case studies/sanity checks (worked when possible; otherwise boundary/special-case checks)
      - Variations, tradeoffs, pitfalls, misconceptions
    - For each major step/claim/procedure, lead with intuition; then clarify:
    what it does, why it’s done, what it depends on/assumes, and what changes
    under common alternatives (when relevant).


    If {{p2}} = "cheatsheet"

    Make it compact, high-signal, and scannable; add rationale only where it
    improves internalization.


    Cheatsheet Structure (in this order)

    1) TL;DR (3–7 bullets): what this is and when to use it

    2) Quick Recipe: minimal steps/commands/algorithm to execute successfully

    3) Rationale & Semantics: explain why the recipe is structured that way
       - For each step or key setting, add a brief “Why this exists” line
       - Decode naming and symbols:
         - Commands/flags: what each flag means
         - Packages: what the name implies (e.g., @types/*)
         - Conventions: folder names (src/dist/lib), module systems, etc.
       - Explain “why these values” (defaults vs tradeoffs) only for high-leverage options
    4) Common Variations: alternative settings and what changes (with brief
    tradeoffs)

    5) Pitfalls & Fixes: common errors + how to recognize/resolve them quickly


    Cheatsheet Style Rules

    - Prefer short bullets and compact nesting.

    - Put rationale lines immediately under the item they explain.

    - Keep explanations as micro-justifications, not an essay.

    - Add small mental models only when helpful.


    If {{p2}} = "presentation"

    Produce a Slidev-compatible Markdown deck (not generic “Slide 1/2”
    Markdown).


    Slidev Formatting Rules (must follow)

    A) Deck headmatter (required)

    - Begin with a YAML headmatter block delimited by --- lines.

    - Include at least:
      - title: "<TITLE> (part X/<total>, REF Y)"
      - (optional) theme: <simple theme name if appropriate>
      - (optional) info: a one-line description of what the deck covers
    - After closing headmatter, the first slide begins.


    B) Slides and separators

    - Separate slides using a line containing only:
      ---
    - Pad separators with blank lines (clean breaks).


    C) Per-slide frontmatter (optional)

    - You may add per-slide YAML delimited by --- at the start of a slide.

    - Use sparingly for layout needs (e.g., layout: cover, center, two-cols).


    D) Slide structure

    - Each slide needs a clear title:
      # Slide Title
    - Keep content scannable:
      - Short bullets
      - Small code blocks when helpful
      - Diagrams when they materially help comprehension
    - Put deeper rationale (and most inferred details) into speaker notes when
    it would clutter slides.


    E) Speaker notes (required when rationale is useful)

    - Add notes ONLY as HTML comments at the END of the slide:
      <!--
      Speaker notes:
      - Rationale behind steps/names/symbols/values
      - Assumptions/tradeoffs
      - Inferred details (clearly labeled) when the source omits key steps
      -->
    - Notes must be the last content on that slide.


    F) Internalization strategy for presentations

    - Slides: what + how at a glance.

    - Notes: why + tradeoffs + decoding symbols/flags/values.

    - If procedural, include a “Recipe” slide early, then “Rationale &
    Variations” slides.


    If {{p2}} = "custom"

    - Follow the user’s custom instructions precisely, but still apply Global
    Rules unless explicitly overridden.


    ========================================

    INPUT FORMAT

    ========================================


    [CONTENT TO SUMMARIZE]:


    --begin text chunk {{chunk.index}} of {{chunk.total}} chunks--

    {{chunk}}

    --end text chunk {{chunk.index}} of {{chunk.total}} chunks--


    ========================================

    OUTPUT FORMAT

    ========================================


    For lecture notes / cheatsheet / custom:

    # <TITLE> (part X/<total>, REF Y)


    <the {{p2}} content in Markdown>


    For presentation (Slidev):

    ---

    title: "<TITLE> (part X/<total>, REF Y)"

    info: "<one-line description>"

    ---


    # <TITLE> (part X/<total>, REF Y)


    <cover/agenda content>


    <!--

    Speaker notes:

    - Purpose of this chunk and what the audience will learn

    -->


    ---


    # <Slide 2 Title>

    <slide content>

    <!--

    Speaker notes:

    - Rationale & decoding (only if helpful)

    -->


    ...


    Proceed with the {{p2}} creation; no confirmation necessary.
  chunkify:
    text: '{{p1}}'
    empty: ''
    maxTokens: 8192
  isolated: false
  param: gpt
- type: js
  code: |2-

              const patterns = [
                  { regex: /^\s*\$\s*\n/g, replacement: "\$\$\n" },
     { regex: /\\Perp/g, replacement: "\\perp" },
                  { regex: /\\\(|\\\)/g, replacement: "\$" },
                  { regex: /\$\$\$/g, replacement: "\$\$" },
                  { regex: /^\s+!/gm, replacement: "!" },
                  { regex: /^\s+\$\$\s*\n/g, replacement: "\$\$\n" },
                  { regex: /-\s+!\[/gm, replacement: "!\[" },
    { regex: /boldbold/g, replacement: "boldsymbol" },
    { regex: /boldboldbold/g, replacement: "boldsymbol" },
    { regex: /```hrp-text\s[^`]*?```/gm, replacement: ""}


              ];
              
              let result = gpt;
              for (const pattern of patterns) {
                  result = result.replace(pattern.regex, pattern.replacement);
              }
              return result;
          
  param: result
  timeout: 15000
  args: gpt
- type: export
  what: param
  filename: harpa-lecture-summary.md
  param: result
- type: say
  message: '{{result}}'