Narrative Transitions

Use this skill when a piece is divided into sections, scenes, slides or steps and must still play or read as one line of thought. It governs the joins. Claims, evidence and sentence-level wording belong to the writing skill in use, such as reasoning-first-narration. A transition never adds a claim, consequence or contrast that the sources do not support.

Link by cause and known-to-new

A boundary works when the opening of the next section starts from something the audience already holds and moves to what is new. End a section on the idea the next one picks up, then open the next section from that idea. A recap of the whole section is not a link.

Connect sections by reasoning, not sequence. "And then" between sections produces a list. Prefer "therefore" (this follows from what we just saw) or "but" (what we just saw runs into a problem or limit), and use "but" only where the sources establish the tension. Every section should still serve the piece's one controlling idea; a transition that cannot say how the next section serves it usually signals a structural problem, not a wording problem.

An open question can carry attention across a boundary when a later section answers it. A question the piece never answers is a teaser, not a transition.

Decide who carries the turn

The medium decides how much the words must do. Decide separately at each boundary, because mixed pieces change medium between sections.

Cross into and out of code

A code walkthrough inside a demo or video is a change of medium, so its boundaries need their own care.

• Into code: start from the behavior or claim just shown and name where it lives, for example "That rejection happens in the installer's name check." Establish the file and function before the detail using the director's selected surface. In real editor footage, meaningful visible navigation can carry the move. In source-derived presentation, retain a file/function label and reveal the relevant excerpt. Neither route requires unrelated file-tree travel.
• Within code: keep one focal line or block at a time and narrate it while it is highlighted. Name each new file or function as the view changes to it, and pause briefly after the change.
• Out of code: carry the mechanism back to its consequence, either the behavior it produces next or the next question it raises, rather than leaving the viewer in the editor. A recap of the code just shown is not a link.

The first section has no earlier section to link from. Open it with a hook that passes the opening hook check in reasoning-first-narration.

Avoid these openings

• A read-out title or heading.
• The section's thesis compressed into a headline or slogan.
• A callback aphorism to earlier framing that the audience must decode.
• An agenda line such as "Next, I will talk about".
• A recap that restates the previous section instead of carrying one idea forward.

A plain signpost is acceptable when the structure itself helps, for example "Let's start with the review lane." Plain beats clever.

Audit the whole piece

Draft and review as one continuous experience, not section by section.

1. Write a one-sentence summary of each section in order, stating its idea and how it serves the controlling idea. Gaps, repeats and drift show up as jumps in that list. In an explanatory piece, a run of summaries shaped as "X does Y" is a list joined by bridges, a structural problem rather than a transition to reword.
2. At every boundary, compare the last two sentences before it with the first two after it. The new idea at the end should become the known starting point of the next opening.
3. Experience the piece in its medium: read spoken scripts aloud with headings removed, review video narration against the planned picture at each cut, and read written pieces straight through.
4. Fix every join that fails the medium's test, except joins inside sections with structural findings. Report those findings to the caller or the structure's owner and leave those sections unchanged.
5. When one transition is corrected, re-check every boundary before presenting the revision. A defect at one join usually exists at others.

Repeat the audit after material revisions, reordered sections or changed visuals.