Docs as code

Docs as code, for product walkthroughs.

Docs as code keeps documentation in the repository, reviews it in pull requests and builds it in CI. Stagewright does the same for the walkthroughs, videos and help articles that show customers how to use your product, and adds the one step docs as code doesn't have: running them against the product.

What docs as code already gives you

Docs as code treats documentation like software: plain-text files next to the code, changed in pull requests, reviewed by the people who changed the product, built and published by CI. It works well for reference and conceptual docs, and tools like Mintlify and Promptless now draft those text changes from the diff.

It has always stopped short of the parts of documentation that show the product: screenshots, videos and step-by-step guides. Those are captured by hand, outside the repo, and nobody reviews them in the pull request that makes them wrong. Mintlify’s own media guide says it plainly: “Every screenshot you publish is a commitment to update it when the UI changes. Every video becomes outdated when the flow it shows changes.”

The same idea, for walkthroughs

Docs as code Stagewright
Markdown in the repo A walkthrough is YAML in .walkthroughs/: steps, narration, and a check on each step that changes the screen
Reviewed in a pull request Reviewed in a pull request, with before and after frames of every step that changed
Built in CI Recorded in CI against the PR’s preview, only for the walkthroughs the change can affect
A broken build fails the check A flow that broke fails the check and is filed as an issue with the video
Published on merge Published when a person approves the new recording: the player, the help article and the course update together
Configuration in the repo stagewright.config (TypeScript, JSON or YAML) holds environments, locales, CI rules, issue tracking and the coverage map’s features; secrets stay out

What docs as code can’t do on its own is run the thing it describes. Text can be reviewed; whether it’s still true can only be found by doing it. That’s the idea behind Docs as Tests, which Manny Silva set out and built into the open-source Doc Detective. A walkthrough applies it to video and help articles: the thing customers watch is the thing that ran. More on that on the Method page.

Where to start

  • You have Playwright tests. Import the ones that tell a story as walkthrough files, without moving them: Record product walkthrough videos from your Playwright tests.
  • You have a docs site. When you connect the repository, Stagewright reads Mintlify, Docusaurus, MkDocs, GitBook, VitePress or Starlight navigation and turns each how-to group into a course of lessons to record. Docs pages that embed videos become one more course: the videos to re-record as walkthroughs that stay current.
  • You’re starting fresh. npx stagewright init writes a sample walkthrough and a config, and npx stagewright record records it on your machine with no account. See Developers.

If you already keep text docs current with Promptless or Mintlify, keep them: here’s how the two fit together.

Try it on your own product

Record a first walkthrough on your machine with no account. PR checks, approvals and publishing are in private beta: join the waitlist and we'll set you up by hand.