**Stagewright** · private beta # Product walkthroughs, checked in every pull request. Stagewright records guides, videos and help articles from your running product, re-runs them on every PR, and asks you to approve what changed or files what broke. Before merge, not after the release. [Join the waitlist](https://app.stagewright.ai/?waitlist)[Read the method](https://stagewright.ai/method) npx stagewright initRecords on your machine. No account needed. \[Illustration\] The Walkthroughs comment on pull request #412: ▲ 1 regression · Δ 3 UI changed · 6 unchanged. Invite a teammate regressed at step 4 (button “Send invite” is now “Send”) and was filed as ACM-231; three walkthroughs changed on purpose and wait for approval, with before and after frames. ## Stale content is a signal, not a content problem. Other tools notice the product changed and regenerate the video after you ship. Stagewright runs the walkthrough on the pull request and asks what the change means. Δ UI changed An intentional change. Approve the new recording, and the video, help article and course update when the PR merges. ▲ Regression The product broke. It's filed as an issue with the video before a customer finds it, and the fix PR is replayed to prove it. Built for product teams, not as a video tool. The recording is the start of the loop. **Recorded by Stagewright** · of Stagewright ## Our own dashboard, recorded from our own repo. These aren't drawings. Stagewright played three of the walkthroughs in its repository against its own dashboard and rendered them, the same way it would for your product. \[Video\] A 52-second recording of Stagewright's own dashboard, made by Stagewright from .walkthroughs/review-ui-change.yaml: Reviews for pull request #415 in the sample project, one changed step shown side by side with its baseline, then swipe, onion skin and highlight, then Approve all 3. Recorded 2026-10-12 against a local build with sample data (Acme Inc), narrated by a local text-to-speech voice. Video: https://stagewright.ai/media/dogfood/review-ui-change.mp4, captions: https://stagewright.ai/media/dogfood/review-ui-change.vtt Walkthroughs of Stagewright's own dashboard, recorded by Stagewright from the `.walkthroughs/` files in our repo (commit 6c8f970) on 2026-10-12, against a local build signed in as test personas with seeded sample data: Acme Inc, Northwind, and a drawn stand-in of the Acme Projects app inside the run and review frames. Not edited. Narration is a local text-to-speech voice, muted until you turn it on; captions are on. \[Video\] A 47-second recording of Stagewright's own dashboard, made by Stagewright from .walkthroughs/run-regression.yaml: Needs attention shows a regression from pull request #412, the failing run with the closest match for the missing button, the step against its baseline, and the prompt for a coding agent. Same date, build and sample data. Video: https://stagewright.ai/media/dogfood/run-regression.mp4 \[Video\] A 49-second recording of Stagewright's own onboarding, made by Stagewright from .walkthroughs/onboarding.yaml: a new organization (Northwind, sample data) names its project, skips GitHub and the test login, and lands on the first-video checklist. Same date, build and sample data. Video: https://stagewright.ai/media/dogfood/onboarding.mp4 **01** Record ## Recorded from your running product, from a script in your repo. A walkthrough is a YAML file next to the code: steps, narration, and a check on every step that changes the screen. Stagewright plays it against your app in Chromium, on your laptop against localhost, in CI, or on a runner inside your network, and renders a narrated video, a help article with screenshots, and a PDF guide from the same run. - Locale and time zone pinned, screenshots taken once frames settle, masks for what changes run to run. - Write it by hand, have a coding agent write it, draft it from the feature's code, or import a Playwright test. - Support and success edit narration in the dashboard and propose changes without repo access. \[Illustration\] A walkthrough file, .walkthroughs/invite-teammate.yaml: an id, the feature it covers, the source files it anchors to, and steps that each have narration, actions and an expect check. **02** Checked on every PR ## Every pull request gets a verdict, not just pass or fail. On each PR, Stagewright records the walkthroughs the change can affect against its preview deployment, compares every step with the approved frames, and posts one sticky comment and a Walkthroughs check. Each preview gets an unlisted page with the video and article as they'd publish. - A failed recording runs a second time before it's judged; a failure that doesn't repeat is flaky and never blocks. - GitHub through the App or Action; GitLab, Azure DevOps and Bitbucket through `stagewright ci`. - Only walkthroughs the change can touch are recorded. The rest keep their approved recording. \[Illustration\] How a pull request is judged: Unchanged passes. UI changed or new waits for approval. A failure that repeats where the PR touched the walkthrough's anchors asks for the walkthrough to be updated; one that repeats where it didn't is a regression, filed as an issue. A failure that doesn't repeat is flaky and never blocks. Walkthroughs the change can't affect are skipped. **03** Approve or file ## Approve what changed. File what broke, with the video. Approving an intended change makes it the new baseline and queues it to publish. A regression becomes an issue in Linear, Jira or GitHub Issues with the clip of the failing step, numbered repro steps, the failing selector and a trace, assigned to the PR's author. - Hand the fix to a coding agent from the issue: `/stagewright:fix ACM-231`, or Linear's agent delegation. - A PR that says `Fixes ACM-231` is replayed. Proven or not proven goes back on the PR and the issue. - One issue per cause: a repeat adds a comment, never a duplicate. \[Illustration\] Issue ACM-231 in Linear, filed by Stagewright: “Invite a teammate: Send invite button not found”. It carries the clip of the failing step at 0:58, numbered steps to reproduce, the failing check, the result of the automatic second run, the PR author as assignee, and how to hand the fix to a coding agent. Its activity ends with “Fix proven on PR #418 at 3f9a2c1”. **04** Publish ## Published where customers read it, with the build it came from. The player page and embed always show the newest approved recording, stamped with its build and when a run last passed. Help articles go to Productlane, Intercom or Zendesk as drafts for review by default, and the articles already there are read back in and checked against the product. - Public, private or password-protected links, and your own domain. - MP4, GIF, step screenshots, a PDF guide and short clips in 16:9, 1:1 and 9:16. - Courses, knowledge checks and SCORM or cmi5 packages that stream the current recording. \[Illustration\] The public player for “Invite a teammate” (Acme CRM): the recorded video with chapters and captions, and the stamp “Recorded from build a1b2c3d · verified 3h ago”. \[Illustration\] Help-center articles read back from Intercom, Zendesk and Productlane, each marked failing, stale, fresh or not checked, with the reason: a failing walkthrough, a UI change after the article's last edit, a label no screen has any more, or no walkthrough covering the feature. **05** Measure ## See the sentence people stopped on. Drop-off is counted by the second and lined up with the narration, so it points at a line of the script you can change, not just a timestamp. Support conversations are grouped by feature, so you can see which features people still ask about. Where we compare viewers with people who didn't watch, we say so: content lift is shown against similar non-viewers, with a holdout when you want to confirm it. We don't have customer results to publish yet, and won't show any we can't back up. \[Illustration\] Example: a still-watching curve for a 1:08 video. It falls from 81% to 64% between 0:40 and 0:46, during the narration line “Roles decide what they can see; admins can change them later.”, so drop-off points at the sentence people left on. ## The whole loop, both ways. Integrations pull in what customers already read and ask, not only push content out. 1. **Pull in**Help-center articles, support themes and issues, mapped to the features they're about. 2. **Verify**Every walkthrough on every PR: approve what changed, file what broke. 3. **Fix**Regressions filed with video, handed to a coding agent, proven on the fix PR. 4. **Publish**Video, article and course, where customers read, with a verified stamp. 5. **Measure**Drop-off to the second of narration, and support load per feature. [Integrations](https://stagewright.ai/integrations) · [The method](https://stagewright.ai/method) **Developers** ## Your agents write the code. Stagewright keeps the explanation honest. Hand setup to Claude Code, Codex or Cursor. The prompt installs the CLI, proves how your app starts and signs in, and records a first walkthrough on your machine. It stops and asks before signing in, approving or pushing. ``` npx stagewright init npx stagewright doctor --install npx stagewright record .walkthroughs/example.yaml ``` [CLI, CI providers, MCP and the agent plugin](https://stagewright.ai/developers) \[Illustration\] Copy prompt “Set up Stagewright and record a first walkthrough”. Hand this prompt to your coding agent to install the Stagewright CLI in your repo, prove how the app starts and signs in, and record a first walkthrough on your machine. Get the full text with: npx stagewright@latest prompt setup **Customer education** ## Every release ships with its training already updated. For SaaS vendors with formal customer training: courses and learning paths per role, built from the same walkthroughs that are checked on every PR. When a lesson's flow changes, its certificates lapse and learners see just what changed. [Stagewright for customer education](https://stagewright.ai/for/training) - SCORM 1.2, SCORM 2004 and cmi5 packages that keep playing the current recording - Each language recorded from the product in that language, and checked on the PR - Release training: "What changed in this release", from the approved UI changes - Private links, passwords and custom domains - GitLab, Azure DevOps and Bitbucket, and a runner inside your network for VPN-only staging - Knowledge checks drafted from the walkthrough, shown only after a person approves them ## Changelog [All changes](https://stagewright.ai/changelog) 1. 2026-10-12 [Sign-in behind a "Sign in" button, and runs on the default environment](https://stagewright.ai/changelog#2026-10-12-sign-in-button) The recorder now signs in to apps whose form opens from a button, and Run and Publish in the editor use the project's default environment. 2. 2026-10-12 [The player's frame is warm charcoal](https://stagewright.ai/changelog#2026-10-12-player-frame) The player, in the dashboard and where it's hosted or embedded, uses a warm charcoal frame in place of slate blue, with its own shade in dark mode. 3. 2026-10-12 [Declare the coverage map in stagewright.config](https://stagewright.ai/changelog#2026-10-12-features-as-code) `features:` in the config lists your product's features by key, with names, routes and personas. They're applied on sync, read-only in the dashboard, and in `stagewright` 0.3.0 on npm. 4. 2026-10-12 [Setup you can skip](https://stagewright.ai/changelog#2026-10-12-setup-skippable) The project overview shows what's left to set up under Needs attention, and each item can be skipped or marked done when you don't use that kind of tool. ## 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. npx stagewright init [Join the waitlist](https://app.stagewright.ai/?waitlist)[Developer docs](https://stagewright.ai/developers)