A tour guides someone through your product one step at a time, highlighting what to look at. It's the format for anything easier to show than to describe.
The editor opens your product and you build the tour there, pointing at real elements rather than describing them. That's what keeps a tour attached to the interface as it changes.
Cross-Origin-Opener-Policy: same-origin header — which has to be unsafe-none for the editor to connect.Allow dismiss — lets someone leave. Keep it on: a tour that can't be escaped is worse than no tour, and the people who want out weren't going to read it anyway.
Back button — lets people re-read a step they moved past too quickly.
Background glow — dims everything except the element in question, which is what makes a step legible on a busy screen.
Read text aloud — narrates the steps. Useful for onboarding; note that browsers start muted, so there's an option to prompt people to unmute.
Four or five steps is a tour. Twelve is a manual nobody finishes, and the drop-off is steep after the first few — so put the thing that matters early rather than building up to it.
Write each step as an instruction, not a label. “Click here to add your first project” moves someone along; “Projects panel” describes the furniture.
A tour can be made available to Kai, so a customer asking how to do something gets walked through it instead of reading about it. That needs the tour to be live, and — the part people miss — the description filled in, since that's all Kai knows about it.
Tours point at elements in your interface, so they break when the interface changes. A step whose target has moved is the most common failure, and nobody reports it — they just abandon the tour.
Run your own tours after any significant frontend change. It takes two minutes and it's the only way you'll find out.