Skip to main content

Speaker notes

Place speaking guidance in :::notes; it is available in presenter view rather than the audience slide.

:::notes
{timing: 3min}
[요약]
- Explain the decision.
- Connect it to the measured evidence.
- Identify the remaining limitation.

Start by describing the observed failure and why it matters to the user.
Walk through the evidence supporting the selected fix, then explain what
its verification covers and which conditions still require follow-up.
{cue: question}
Ask which assumption the audience would test next.
{cue: transition}
Move to the example that exercises that assumption.
:::

Exact marker and language​

The current validator looks for the literal [요약] marker, meaning “summary,” on applicable content slides. Preserve that syntax even in an English deck. Write the bullets and spoken script in the requested presentation language; do not translate a required parser literal into an unsupported alias.

Timing and cues​

Use {timing: 3min} or {timing: 90s}. Cue markers such as {cue: demo}, {cue: pause}, {cue: question}, {cue: transition}, {cue: poll}, and {cue: break} mark delivery actions. Explain practical implications and transitions instead of repeating slide text.

Validation​

The source validator distinguishes missing, short, and unstructured notes, with slide-type exemptions. Its guidance recommends at least 150 characters and fuller notes where needed; the exact severity thresholds live in the validator. Keep source validation separate from the independent content-review score.

Presenter view​

P opens a separate view with current/next slide, notes, timing, and navigation. Splitters resize the slide/notes regions and store their ratios locally. The presenter and main window synchronize through the framework's channel; test that behavior with the actual generated deck.

Notes validation rules