Create a narrated walkthrough. Pass its opening in opening: the reply then comes once that is voiced, with the handle, the playable link and the full authoring guide. Send the link to the user at once, in a message, before your next tool call; they watch while you add the body with add_slides. Without opening, the reply is short and your first add_slides call must carry the opening instead.

Append slides to a walkthrough, written in Markdown.

Calls:

• Opening: normally sent in start_walkthrough's opening (see its example). Only if it was not sent there, the first call carries it and nothing more: the title slide and one or two short spoken sentences. That call returns when the link is playable, with the full guide; send the link to the user then, before anything else.

• All other calls: first one short slide alone, then one to three whole slides. Never resend earlier Markdown. Never split a slide or its code block across calls.

• Replies list problems, each ending in a code; errors come first. Fix errors in sent slides now with revise_slide; fix warnings in later slides.

Format:

• Slide: each #, ## or ### heading starts one. Optional attributes: ## Title {#id .build}; .build reveals parts as cues reach them.

• Narration: every plain paragraph is spoken, labels included, each voiced separately: never start one with "Narration:" or "Slide 3:". Put identifiers in backticks; [text]{say="spoken"} fixes pronunciation.

• Shown text: > lines are shown, never spoken; under the first heading, one is the subtitle.

• Layout: > under a heading is its takeaway; {.side} puts one to three > lines beside the visual, {.pair} shows two visuals side by side, {.full} the visual edge to edge; a slide with only a > sentence is a statement. {icon=name} on a heading, and :name: before a list item, stat label or > line, add a Lucide icon. Vary the look from slide to slide.

• Visual: at most one per slide: fenced code, diff, mermaid diagram, math formula, pipe table, list, image , chart bar|hbar|line, terminal session, tree of files, stat numbers, chat exchange, svg drawing (consecutive svg step blocks are versions that glide into each other; svg sketch looks hand-drawn) or ```drawio file=path, a draw.io diagram the project already has. Syntax and examples: resource showntell://slide-kinds.

• Choose the visual by the idea's shape: a change → diff, not the new code alone; flow, steps, causes and effects → mermaid; numbers → chart or stat; something physical or spatial → svg drawing; commands → ```terminal; dated events → .timeline list. Lists and tables only for words with no shape, never three in a row.

• Code options: scroll for long code; consecutive ```lang step blocks are versions of one code slide.

• Code from disk, with an empty body and the file's own line numbers in the gutter:

Inline code may set start=10.

• Diff: python old then python new blocks; diff with -/+ lines, one hunk per slide; or diff file=path rev=A (against the working tree), rev=A..B (two commits) or rev=A...B (B against the commit where it branched off A: what a pull request shows).

• List: - **Title**: text {#id}; without {#id}, the id is the title, lowercased and hyphenated. 1. items are steps; .cards on the heading shows cards; .timeline puts dates, the bold titles, on a line; .quiz makes two to four - [ ] items with one - [x] a multiple-choice question, choices #a to #d, the answer shown when a cue points at it.

• Cues are links in narration around the words that name the target. The pointer lands as the label's first word is spoken, within the current slide only. label line 12 | #L12-18 a range | label only that text on line 12 | #-L5 old side, #+L7 new side of a diff | #id a list item, card, Mermaid node, chart bar or series, tree entry, drawing element (also by its or text as a slug) or draw.io cell (also by a unique label) | #row-2 the second table row, or a {#id} ending its last cell | # the whole visual; label finds that text in it. Also #step-2 (only with step blocks), #a->b->c flowchart edge path, #Sender->>Receiver a sequence-diagram message, #@l,t,w,h image, drawing or draw.io region; {.circle}, {.arrow}, {.zoom} etc. after a cue (see showntell://slide-kinds).

Replace one slide, found by its id, with new Markdown. Only narration whose text changed is voiced again; the rest keeps its audio. Omit the heading to keep the slide's title, classes and attributes. Use it for a slide a reply reported as broken, or to rework a finished walkthrough: find its handle with list_walkthroughs and read its Markdown from the resource showntell://walkthroughs/{id}. The reply's slide_url plays only the revised slide; share it when the user asked for the change.

Close the walkthrough after its last slide. Records the end questions and returns a summary: remaining problems, each slide's start time and look (kind, layout, takeaway, icons) and what could not be checked. It names runs of slides that look alike, with pictures of them; revise one in each run into a different look before telling the user. With Playwright installed it first draws every slide, so the summary already reports render and layout problems (render errors, text_too_small, overflow, drawing_overlap); fix them with revise_slide. Call preview_slides only for slides it names, a drawing or diagram you want to see, or when the user asks. Then tell the user it is finished and give the link; if they want a video or a file to send, call export_walkthrough.

Save a walkthrough as one file the user can keep or forward: an MP4 video (H.264 and AAC, with a subtitle track) or a self-contained HTML page that plays offline in a browser. Call it after finish_walkthrough and the fixes its reply names. It waits up to five minutes for narration still being voiced, then renders; an MP4 takes about a tenth of its length plus a few seconds. Use it when the user asks for a video, or for a file to share, send or attach. MP4 needs ffmpeg and Playwright Chromium, HTML neither; the error says what is missing.

List recent walkthroughs with their handles, titles and links. Use it to find the handle of a walkthrough to revise later, including one from an earlier session. Its Markdown source is the resource showntell://walkthroughs/{id}, where id is the part of the handle before the dot.

Look at slides as the viewer sees them: returns a small picture of each, fully revealed, plus any layout problems the player found while drawing them. Use it for chosen slides (one a reply named, a drawing or diagram, a revised slide) to check that code is readable, diagrams fit and nothing overlaps; finish_walkthrough already draws every slide and reports these problems, so a full preview after it is rarely needed. Needs Playwright on the machine running showntell; the reply says how to install it if missing.