` `role="main"` on its one obvious candidate. | Each repaired element is marked with `data-wao`, so an agent can tell inferred names from ones the page wrote. Switch a repair off with `optimise({ repairs: { landmarks: false } })`. ## Rules [#rules] Heuristics can't know what a control means. Rules can, and they override the page: ```ts optimise({ rules: [ { selector: "#hdr .links", role: "navigation", label: "Primary" }, { selector: ".btn-go", label: "Check out", description: "Pays for everything in the basket", }, ], }); ``` With the script build, set `window.waoOptions` before the script loads. ## Reports [#reports] `report()` lists every change in effect and what WAO found but could not fix (`unnamed-control`, `image-without-alt`, `no-main`). Each issue is a good candidate for a rule, or for a fix in the site itself. Inferred names are a best guess for agents. A site that people use with assistive technology still needs real labels. ## Next steps [#next-steps] - **[Read the full API on GitHub](https://github.com/stunt-double/stuntkit/tree/main/packages/wao)** - **[Give an AI agent a safe browser](/stuntkit/browser-toolset)** # Automate from Claude (/tutorials/automate-with-mcp) # Automate Stunt Double from Claude [#automate-stunt-double-from-claude] This tutorial connects Claude and uses it to run your workspace from a conversation. The **[MCP server](/mcp)** pages cover authentication and every tool. ## Connect Claude to your workspace [#connect-claude-to-your-workspace] Follow **[Connect](/mcp/connect)** for Claude Desktop, or the **[Claude](/mcp/clients/claude)** and **[Claude Code](/mcp/clients/claude-code)** pages. The first time Claude calls a tool, it runs the OAuth flow and asks you to sign in to your workspace. Once you approve, Claude can list and call tools on your behalf for the rest of the session. ## What you can ask Claude to do [#what-you-can-ask-claude-to-do] With the server connected, you can drive most of the platform in plain language instead of clicking through the dashboard: - "Run the checklist for our signup flow and tell me if anything failed." - "Create an actor for a first-time free-trial user and give it browser access." - "Launch a new round of our onboarding interview and summarize the top themes." - "List the workflows that ran in the last day and flag any failures." Claude translates each request into the appropriate tool calls, actors, checklists, workflows, interviews, and reads back the result. ## Scope tokens to least privilege [#scope-tokens-to-least-privilege] Grant only the scopes a given client needs. There are three: `mcp:read` to read a workspace, `mcp:write` to create and edit, and `mcp:run` to start runs. A client that only reports on results needs `mcp:read`, and nothing more. A client that requests no scope gets all three. See **[authentication](/mcp#authentication)** for what each covers. ## Next steps [#next-steps] - **[Automate multi-step workflows](/tutorials/building-workflows)**, for automations that don't need a human in the loop at all. - **[API overview](/api)**, for driving Stunt Double from your own tools instead of Claude. # Build workflows (/tutorials/building-workflows) # Automate multi-step workflows [#automate-multi-step-workflows] A checklist verifies one flow in one run. A workflow chains several steps together into a single repeatable automation, so you can wire up a whole process instead of a single check. ## Step types available [#step-types-available] A workflow is built from steps, each with its own configuration: - **Run Checklist**, executes an existing checklist and carries its result forward. - **Condition**, branches the workflow based on the result of a previous step. - **Notification**, sends an alert when the workflow reaches that step. - **Delay**, waits before continuing, useful for giving an async process time to finish. - **GitHub Comment**, posts a comment back to a pull request. - **Actor PR Review**, has an actor review a pull request and report its findings. ## Example: verify a pull request automatically [#example-verify-a-pull-request-automatically] A common workflow for a product team: 1. **Run Checklist**, runs the checklist for the flow the pull request touches. 2. **Condition**, checks whether every check in that run passed. 3. **Actor PR Review**, if the condition passes, has an actor review the change directly. 4. **GitHub Comment**, posts the outcome back to the pull request either way, so the result is visible without leaving GitHub. Each step only needs to know about the step before it, which is what makes it possible to compose a whole review process out of a handful of pieces. ## Toggle a workflow on when you're ready [#toggle-a-workflow-on-when-youre-ready] A new workflow can be built and tested without affecting anything else. Toggle it on only once you've run it a few times and are confident in the result, since an enabled workflow runs automatically going forward rather than waiting for you to trigger it by hand. ## Next steps [#next-steps] - **[Turn runs into insights](/tutorials/reviewing-runs)** - **[Automate Stunt Double from Claude](/tutorials/automate-with-mcp)** # Write checklists (/tutorials/effective-checklists) # Write checklists that catch real regressions [#write-checklists-that-catch-real-regressions] A checklist is only as useful as the checks inside it. This tutorial covers how to write checks that hold up over time, and how to read a run so a "failed" badge tells you something you can act on. ## Write one check per outcome, not per click [#write-one-check-per-outcome-not-per-click] A check is a single description of what should be true. It's tempting to write mechanical, step-by-step instructions, but checks written that way break the moment your UI changes, even when the underlying behavior didn't: - Weak: "Click the discount field, type SAVE10, click Apply." - Strong: "Confirm the cart shows the discounted price after applying code SAVE10." The strong version tells the actor what outcome to verify and leaves it to work out how to get there, which is exactly what makes checklists resilient to redesigns. ## Point checks at the moment that matters [#point-checks-at-the-moment-that-matters] Group checks around the state that actually needs verifying, not the navigation that gets you there: the confirmation screen after checkout, the inbox after a signup, the dashboard after a plan change. If a flow has several outcomes worth confirming, write a check for each one rather than one check trying to cover all of them. ## Choose what each check is worth [#choose-what-each-check-is-worth] Not every check deserves to stop a release. Each one has a type, set in the create dialog or the flow editor's inspector: - **Pass / fail** is blocking. One failure fails the whole run. Use it for the things that must work: checkout completes, the signup email arrives. - **Weighted** contributes its weight to a run score rather than blocking. Weights run from -100 to 100, default 1, so "checkout completes" can outweigh "the footer year is current". A weight below zero is a **penalty**: it adds nothing when the check passes and deducts that many points when it fails, without raising the maximum. Phrase a penalty as what should be true ("no placeholder text is left in the copy"), so passed still means good. - **Informational** is never judged. The actor records what it observed ("the headline price is $29 per month") and that text is the deliverable, which is how drift in prices, copy or plan names gets caught between runs. A checklist's **Passing score** decides the verdict for its weighted checks. It defaults to 100, which reproduces the old all or nothing rule, so a checklist you already have behaves exactly as it did until you lower it. The two hurdles are independent on purpose: no blocking check may fail, **and** the weighted score must reach the threshold. Folding pass/fail checks into the score would let "the user cannot check out" survive as long as enough cosmetic checks passed. A check that errors is inconclusive rather than failed. A check the run never reached says nothing about your product, so it stays out of the score. ### Writing a scoring rubric as a checklist [#writing-a-scoring-rubric-as-a-checklist] A rubric like "40 points for the core flow, 30 for clear messaging, 20 for accessible controls, 10 for visual polish, minus 20 for a blocking error, out of 100" is five weighted checks: four with those weights and one with a weight of -20. The maximum is the positive weights only, so the run really is out of 100. Partial credit ("15 if the messaging is only partly clear") is two checks of 15 rather than one of 30, since a check has one verdict. The passing score is a percentage, and the editor shows the points it works out to at the current weights (75% of 100 is 75 points). Under **Grades**, name the ranges a score can land in, best first: Optimal from 75%, Partial adoption from 37.5%, Pushed back below that. A run then reports its grade next to its score. Grades only label the score; the passing score still decides whether it passed. ## Order the checks, and let one depend on the last [#order-the-checks-and-let-one-depend-on-the-last] Checks run top to bottom. Drag a check vertically to reorder it, or use Move up and Move down in the inspector. Order matters because a check can depend on how the one before it turned out. Set its run condition to: - **Always**, the default: it runs whatever the check before it found. - **If previous passed**, for a follow-up that only means anything once the step before it worked ("the confirmation shows the right total"). - **If previous failed**, for an inspection that is only reachable when the step before it broke ("the error message explains what to fix"). Without conditions, both shapes produce a misleading report: one failure counted twice, or a check that fails because the product worked. A check whose condition is unmet is recorded as **skipped**, naming the check it depended on, and left out of the score entirely. It did not fail, and it is not inconclusive either. A condition is only unmet when the previous check's verdict contradicts it: an antecedent that errored, or an informational one with no verdict at all, leaves the condition undecidable, and the check runs. Quietly testing less is the one outcome a testing product must never produce. One thing to know before you reach for informational checks: they need the actor to read the page, so a checklist containing one always runs the full agent rather than replaying its recorded script. ## Read the evidence, not just the pass/fail badge [#read-the-evidence-not-just-the-passfail-badge] A run reports a verdict, a score for its weighted checks, and the evidence behind every check. Each check carries its own screenshot, taken on the page the actor was actually on when it reached its verdict. A run report has tabs for: - **Results**, each check's status and a short explanation. - **Screenshots**, the page as the actor saw it at each step. - **Recording**, the full session if you want to watch it play out. - **Knowledge**, which knowledge entries the actor drew on. When a check fails, read the explanation and screenshot before deciding whether it's a real regression or an ambiguous instruction. A surprising number of "failures" turn out to be a check that needs to be more specific about what counts as success. ## Read a run against the one before it [#read-a-run-against-the-one-before-it] A finished run is compared with the previous completed run of the same checklist, under **Since the previous run** on the report. It names what changed rather than what is red, which is the difference between a report you read every time and one you stop opening. Informational checks are compared as text, so "$29 per month" becoming "$39 per month" shows up even though no pass or fail state moved. Editing a checklist keeps its history: checks you did not touch keep their ids and their past results, so a comparison still has something to compare against. ## Re-run before you trust a result [#re-run-before-you-trust-a-result] An actor working through a hosted browser can hit a transient issue, a slow page load, a flaky third-party script, just like a human tester can. Before filing a bug from a single failed run, re-run the checklist once. A result that reproduces consistently is worth acting on immediately. ## Next steps [#next-steps] - **[Turn runs into insights](/tutorials/reviewing-runs)** - **[Automate multi-step workflows](/tutorials/building-workflows)** # Collect feedback (/tutorials/feedback-widget) # Collect stakeholder feedback on a prototype [#collect-stakeholder-feedback-on-a-prototype] Share a prototype and the notes come back as screenshots in Slack, with no way to tell which page or which build they were about. The feedback widget is one script tag on the prototype: reviewers pin a comment on the exact spot, and it arrives with a screenshot and the page context already attached. ## 1. Turn comments on for a project [#1-turn-comments-on-for-a-project] Open the project holding the prototype and go to **Comments**. If comments have never been enabled, you get a short explainer and an **Enable comments** button. Enabling switches the feature on and mints the project's **API key**, which ties the widget on your site back to this project. Each project has its own key and its own inbox, so a round of feedback on one prototype never mixes with another. ## 2. Add the widget to the prototype [#2-add-the-widget-to-the-prototype] The Comments view then shows the install step with two tabs. **With Claude** gives you a prompt to paste into Claude, Claude Code, or any coding assistant. It describes both script tags and where they go, which is usually the fastest route if an agent already has your repo open. **Code** gives you the snippet directly. Add it just before the closing `` tag. Set `data-sd-version` to your build ID if you want each round of feedback kept apart (see [Prototype versions](#prototype-versions) below). The [integration reference](/integrations/feedback-widget#the-snippet) explains every attribute. There is no package to install and no build step, so this works on a staging deploy, a preview URL, or a throwaway static build just as well as on your production site. ### Confirming it works [#confirming-it-works] The install screen polls while you work. Add the snippet, deploy or reload the prototype, and visit any page carrying it. Within a few seconds the screen flips from **Waiting for widget connection** to **Widget detected** and moves you on to the Comments view. No manual verification step, and nothing to paste back. If it never flips, the two usual causes are a mistyped key and a domain that is not allowed yet. Both are covered under [Control who can use it](#control-who-can-use-it). ## 3. Hand it to your stakeholders [#3-hand-it-to-your-stakeholders] Before you send the link, decide who should be able to comment. For an internal review, turn on **Require sign in** under **Comments → settings**. Only signed-in members of the workspace can then read or leave comments, which is the right setting for an unreleased prototype on a public staging URL. Reviewers get a **Sign in to review** button instead of an anonymous form: it opens a popup, they sign in to Stunt Double as normal, and the popup hands the widget a short-lived token proving workspace membership. Their replies are badged **Team**, and their name comes from their account rather than a form field. The token lasts an hour, so a long review session may ask for a fresh sign-in. Because a cross-origin widget cannot read the Stunt Double session cookie, this token is the only thing that unlocks gated data: the sign-in state the widget shows is cosmetic on its own. For a wider round, with customers or people outside the workspace, leave sign-in off and send the link. Commenting then takes three actions: 1. Click the floating button in the bottom-right corner, or press **`c`**. 2. Click the spot the comment is about. A pin lands there. 3. Type a name, optionally an email, and the comment, then send. **Escape** cancels at any point. The name and email are remembered in that person's browser, so their second comment only needs the comment itself. The email is optional and only used to notify them when someone replies to or resolves what they left. Every submission carries more than the text: a screenshot of the page as it looked, the page URL, the pin position, viewport size, scroll offset, and basic device information. That is what makes "this bit is confusing" actionable a week later. Keep **Show comments on page** enabled for a group review and existing pins are drawn on the page, so five stakeholders discuss one thread instead of filing the same note five times. Turn it off when you want independent reactions: the widget still collects everything, it just does not show anyone else's. ## 4. Triage what comes back [#4-triage-what-comes-back] The project's **Comments** view is where feedback lands. It opens on the **Open** queue with counts across the top: total comments, how many are open, how many pages they came from, and how many are resolved. Comments are **grouped by page**, because that is how you fix them. Expand a page to see every pin left on it, collapse the ones you have dealt with, or use **Collapse all** when the list gets long. Where the pins cluster is where the prototype is failing. Opening a comment shows the full detail: the screenshot with the pin in place, the device and viewport it was left on, the thread of replies, and the status control. From there you can: - **Reply** in the thread. If the person left an email they are notified, and the reply appears on the page for them under a **Team** badge. - **Change status** between **new**, **reviewed**, **resolved**, and **dismissed**. Resolving notifies the author, which is what turns a round of feedback into a closed loop rather than a list nobody hears back about. - **Resolve all** to clear the whole open queue at once, after a round of fixes. Resolved and dismissed comments are filed under **Resolved** rather than deleted, so you can still show why a decision was made three iterations ago. ### Prototype versions [#prototype-versions] Prototypes change fast, and a comment about a button you have since removed is noise unless you know which iteration it referred to. The widget hashes the page content with each comment and groups them into versions: **v1** is the earliest snapshot that received a comment, and the newest is badged **Latest**. A page group with more than one version shows a small timeline, and selecting a version filters the group to the comments left on it. By default the hash is computed from the rendered page, and recomputed as you navigate a single-page app. If you would rather tie versions to your own iterations, set `data-sd-version` on the script tag to a release tag, build ID, or commit SHA. When it is set, the widget uses it verbatim and never re-hashes. That is the cleaner option when you are showing the same prototype to a new group each week. ## Control who can use it [#control-who-can-use-it] Your API key sits in your page source, so it is an identifier, not a secret. What controls access is the project's **allowed domains** list under **Comments**, then settings. For a prototype review: - Add your preview host, or `*.your-domain.com` if each build gets a new URL. - Turn on **Require sign in** for staging and internal reviews, so only workspace members can read or leave comments. - **Rotate** the key when you stop maintaining a prototype. Every setting, the fail-closed rule and the workspace-wide controls are in the [integration reference](/integrations/feedback-widget#control-who-can-use-it). ## Beyond the prototype [#beyond-the-prototype] The same install works unchanged once the thing you were prototyping ships. Leave the snippet in place with sign-in off, and you have a standing feedback channel on production: people report what bothers them where it bothers them, grouped by page and version, in a queue rather than a support inbox. ## Working with comments over the API [#working-with-comments-over-the-api] Feedback is available through the MCP server, so an assistant can triage it with you: `list_feedback` (filter by status when working the new queue), `get_feedback` for one item and its replies, and `update_feedback_status` to resolve or dismiss. Reading needs the `mcp:read` scope and changing a status needs `mcp:write`. See **[MCP](/mcp)** for connecting a client. A natural pairing: read the open comments for a page, then run a checklist against that page to reproduce what your reviewers reported before deciding what to fix. ## Tips [#tips] - Install it on the staging build with **Require sign in** on, before anyone external sees the prototype. Your team gets a low-friction way to leave notes in context, and nothing is exposed publicly. - Ask for the email field when you actually intend to reply. Silence after a feedback round is worse than no widget. - Set `data-sd-version` to your build ID if you iterate daily. Version grouping by content hash is good; grouping by release is unambiguous. - Resolve aggressively between iterations. The Open queue is only useful if it reflects what is genuinely outstanding, and resolved comments are still there to look back on. - Pair it with an interview on the same prototype: actor personas show you what a careful user hits, the widget shows you what your stakeholders actually noticed. ## Next steps [#next-steps] - **[Run a user interview](/tutorials/running-an-interview)** to put persona participants through the same prototype the stakeholders reviewed. - **[Write checklists that catch real regressions](/tutorials/effective-checklists)** to turn a recurring complaint into a check that runs on every deploy. # Build an actor (/tutorials/first-actor) # Build an actor that behaves like your audience [#build-an-actor-that-behaves-like-your-audience] The **[Quickstart](/getting-started)** has you create a minimal actor to run one checklist. This tutorial goes further: writing instructions and knowledge that make an actor behave like a genuine member of your audience. ## Start with a persona, not a checklist [#start-with-a-persona-not-a-checklist] Instructions work best when they describe who the actor is standing in for, not what you want it to click. A persona has a goal, a level of product familiarity, and a tone: > You are a small business owner evaluating whether to switch invoicing > software. You are price-sensitive, comfortable with software but impatient > with jargon, and you will abandon a signup flow if it asks for a credit card > before showing you the product. An actor written this way makes the same kind of judgment calls a real visitor would, rather than mechanically executing steps. ## Give it knowledge to draw on [#give-it-knowledge-to-draw-on] Knowledge entries are the reference material an actor can pull from mid-run: facts about your product, test account credentials, brand or tone guidelines, or answers to questions it might otherwise get wrong. Add a knowledge entry for anything you would otherwise have to explain to a new team member on day one. Keep entries short and specific. A dozen focused entries work better than one long document, since the actor only needs to draw on what's relevant to the step it's on. ## What an actor can do [#what-an-actor-can-do] Out of the box an actor works through your product the way a real visitor would: - **Drives a real browser** through your product, observing each page and deciding what to do next. - **Reads email** sent to its own inbox, so it can pick up verification codes and magic links during signup and verification flows. - **Searches the web** when it needs information beyond your product. - **Remembers context** it has seen before, carrying useful state between runs. You don't have to wire any of this up. Give the actor a clear persona and the knowledge it needs, and it draws on whatever is relevant to the step it's on. ## Test it before you rely on it [#test-it-before-you-rely-on-it] Before building a whole checklist suite around a new actor, run one small checklist against it and read the result. Confirm it interprets your instructions the way you intended, then expand from there. ## Next steps [#next-steps] - **[Write checklists that catch real regressions](/tutorials/effective-checklists)** - **[Run a user interview](/tutorials/running-an-interview)** # Tutorials (/tutorials) # Tutorials [#tutorials] The **[Quickstart](/getting-started)** gets you from an empty workspace to a first checklist run, and **[Core concepts](/concepts)** explains what each building block does. These tutorials go further: practical, task-oriented guides for getting real value out of each part of the product as your usage grows. ## The series [#the-series] ## Next steps [#next-steps] Each tutorial stands on its own, so start where your team needs it most. To connect Slack, GitHub, Linear, Figma or Vercel, see **[Integrations](/integrations)**. To drive Stunt Double from an assistant, see **[MCP](/mcp)**. # Review runs (/tutorials/reviewing-runs) # Turn runs into insights [#turn-runs-into-insights] Every run an actor completes, whether it's a checklist, an interview round, or a workflow, is recorded in full. This tutorial covers how to read a run report and how to use the insights Stunt Double surfaces on top of it. ## Read a run report [#read-a-run-report] A run report is organized into tabs: - **Results**, the pass, fail, or error status for each check, with a short explanation for each one. - **Journey**, the pages the actor visited and the emails it read, in order. - **Screenshots**, the page as the actor saw it at each step, useful for spotting a visual regression that a pass or fail badge wouldn't catch. - **Recording**, the full session, step through it in order or watch it play out end to end. - **Knowledge**, which knowledge entries the actor drew on for that run, useful for checking whether it's relying on something out of date. Start with Results to get the headline, then drop into Screenshots or the Recording when a result needs more context than the explanation gives you. ## What surfaces automatically as an insight [#what-surfaces-automatically-as-an-insight] Not everything worth knowing fits into a pass or fail. As actors work, Stunt Double surfaces insights: notable observations from a run that fall outside strict pass/fail, a confusing step, a broken link, an unexpected result the actor flagged on its own. Insights turn a pile of session recordings into a short list of things worth your attention, without requiring anyone to watch every replay. Review new insights on a regular cadence rather than only after something breaks; the most useful ones are often things nobody thought to write a check for. ## Share findings with your team [#share-findings-with-your-team] Runs and insights are most useful when they reach the people who can act on them. Connect **[Slack](/integrations/slack)**, **[Linear](/integrations/linear)** and **[GitHub](/integrations/github)** (all listed under **[Integrations](/integrations)**) so failed runs and new insights land where your team already works, instead of waiting to be checked manually. ## Next steps [#next-steps] - **[Automate multi-step workflows](/tutorials/building-workflows)** - **[Automate Stunt Double from Claude](/tutorials/automate-with-mcp)** # Run an interview (/tutorials/running-an-interview) # Run a user interview [#run-a-user-interview] An interview is a structured conversation Stunt Double runs with your users at a scale a manual research process can't match. This tutorial covers how to structure one, who to recruit, and how to read what comes back. ## Structure sections and items [#structure-sections-and-items] An interview is organized into sections, and each section holds a series of items. An item is either: - A **question**, asked directly, useful for opinions, priorities, or recalling past experience. - A **task**, where the participant is asked to attempt something (in your live product or a Figma prototype) and then reflect on it. Mixing the two in a section works well: a task that puts the participant in a flow, followed by questions that surface what confused them or what they expected instead. ## Recruit participants: actor personas or real people [#recruit-participants-actor-personas-or-real-people] Participants can be AI actor personas, real people, or a mix of both in the same round. Actor personas give you a fast, repeatable panel for testing a direction before you're ready to recruit, while real participants give you an authentic voice you can't get any other way. A common pattern is to run an actor panel first to catch obvious problems, then bring in real participants to validate what's left. ## Launch a round [#launch-a-round] When the guide and participant list are ready, launch a round. Each round is a complete pass through the guide with every recruited participant. As you make product changes, launch another round against the same guide to see how perception shifts, rather than starting from scratch each time. ## Read the report [#read-the-report] Every round produces a report with: - **Overview**: the counts and a **summary** of what the round found. - **Findings**: the patterns that came up across participants, each backed by evidence drawn straight from the interview. - **By question**: what most participants did, where they differed, and the outliers. - **Recommendations**: ranked by priority, ready to track as goals. - **Usability** and **Transcripts**: the questionnaire scores and every participant's session in full. Because every finding and recommendation is tied to evidence quotes, you can check a claim against what a participant actually said before acting on it. ## Next steps [#next-steps] - **[Turn runs into insights](/tutorials/reviewing-runs)** - **[Automate multi-step workflows](/tutorials/building-workflows)** # Test behind a firewall (/tutorials/self-hosted-worker) # Test a product behind your firewall [#test-a-product-behind-your-firewall] If the product you want to test is only reachable inside your network, a hosted browser session can't reach it. A self-hosted worker runs on your side of the firewall instead, so actors can reach an internal product without opening anything up. Self-hosted workers are part of the Enterprise plan, and only a workspace owner or admin can turn them on and add workers. The page is marked **Experimental** in the app. ## Add a worker [#add-a-worker] 1. Open **Settings > Workers** and select **Enable for this workspace**. 2. Select **Add worker**, name it, then **Create worker**. 3. Copy the Docker snippet the app shows. It runs the published image `ghcr.io/stunt-double/worker:latest` with your worker's API key in `SD_WORKER_API_KEY`. The key is shown once, so store it somewhere safe before you close the dialog. The snippet can also add Watchtower to keep the image up to date. 4. Run it on a machine inside your network, then select **Test connection** to confirm it reaches Stunt Double and your target product. The worker dials out to Stunt Double rather than waiting for an inbound connection, so your firewall needs no changes. Your security team can pull and inspect the image before it runs. ## Control what it can reach [#control-what-it-can-reach] Each worker has an access setting with three modes: - **Allow all domains**: no restriction. - **Allow specific domains**: only the domains you list. - **Block specific domains**: everything except the domains you list. A new worker starts on Allow all domains, so it works as soon as it connects. To restrict it, switch to Allow specific domains and list only what your actors need to reach. ## Pin actors and checklists to a worker [#pin-actors-and-checklists-to-a-worker] Once a worker is connected, assign the actors and checklists that need to reach your internal product to it. Everything else keeps running on hosted browser sessions as normal, a workspace can mix both freely. ## Watch connection status live [#watch-connection-status-live] The Workers page reflects connection status live: a worker's heartbeat flips its status without needing a page refresh, so you can tell at a glance whether it's online before kicking off a run that depends on it. ## Run a worker on your Mac [#run-a-worker-on-your-mac] The Stunt Double desktop app for Mac can act as a worker too. With Workers enabled, open **Settings > Workers**, select **Use this device as a worker**, then **Enable this device**. ## Next steps [#next-steps] - **[Automate multi-step workflows](/tutorials/building-workflows)** - **[Turn runs into insights](/tutorials/reviewing-runs)** # Design review in Slack (/tutorials/slack-design-review) # Review designs from Slack [#review-designs-from-slack] Someone drops a staging link in the design channel and asks what everyone thinks. Two days later there is one reply and nobody has opened it. Connect Slack to Stunt Double and that message gets an answer in the thread: the screen opened in a real browser, looked at, and written up with the problems ranked. One Slack app covers two jobs. **Design review** watches for a message that carries a link and reads like a request for feedback, then replies in the thread with a summary and prioritized findings. **The agent** handles the rest of the conversation. Message Stunt Double directly, or @mention it in a channel, and it answers questions about your workspace and starts checklists and workflows for you. ## 1. Connect Slack [#1-connect-slack] Open **Integrations** > Slack and select **Install Slack agent**, then **Add** your Slack team to the workspace (a workspace owner or admin does this step). That is the whole setup. The Slack app already asks for the permissions it needs, so nothing has to be wired up by hand. Review settings live under **Design reviews > Settings**. The **[Slack](/integrations/slack)** page covers permissions, and the difference between **Remove** (one workspace) and **Disconnect** (your account, every workspace). From the moment the connection exists, anyone in your Slack workspace can message Stunt Double directly and ask for a review. Channels are optional and covered in [step 4](#4-turn-it-on-in-a-channel). Figma is the one extra, and only for Figma links. Connect it from **Integrations** ([Figma](/integrations/figma)) and Figma frames are rendered and reviewed. Without it, a Figma link comes back with a **Connect Figma** button instead of feedback. Web links are reviewed either way. If your workspace connected Slack before direct messages were supported, the page shows **Reconnect Slack**. An installation keeps whatever permissions it was granted, so Slack quietly delivers nothing rather than reporting an error. Reconnecting grants the two permissions the direct-message surface needs. ## 2. Ask for a review [#2-ask-for-a-review] A review starts when a message carries a link **and** reads like a request for feedback. Both halves matter: people paste links all day, and a review opens a real browser and calls a vision model. Phrasings that count as asking: - Can I get some feedback on this? - Design review please - Thoughts on the new onboarding screen? - wdyt - Take a look when you get a chance - Any comments before I ship this? Where you post decides how explicit you have to be: | Where | Starts a review when | | ---------------------------------------- | ----------------------------------------- | | A direct message to Stunt Double | a link and a request phrase | | A channel with design review turned on | a link, and a request phrase or a mention | | Any other channel it has been invited to | a link, a mention, and a request phrase | | A reply in a thread that holds a review | the reply is addressed to us, see below | The last row is what keeps mentions predictable. "@Stunt Double run the checkout checklist against `https://...`" is a request for a checklist, so it goes to the agent rather than coming back as a design review. A reply inside a thread is different. If the thread already holds a review, a reply continues it: the reviewer opens the product again, carrying what it already found plus whatever you just said ("walk the whole checkout", "try it signed out"). That is how you steer a review without repeating yourself, and it is why a reply does not need a link or a request phrase. It also means a reply costs a review. In a channel with design review turned on, every reply in a review's thread is treated as addressed to us, so a thread where three people talk through the findings is three more reviews. Somewhere else the bot has simply been invited, a reply only continues the review when it mentions the bot or answers a question the bot asked. If you want to talk about a review rather than extend it, do it outside the thread, or in a channel that does not have design review turned on. Up to three links from a single message are reviewed. Anything past that is ignored, so one message cannot spend an afternoon of browser time. ## 3. What comes back [#3-what-comes-back] The thread answers immediately, before any work has started: "On it, taking a look at the link." It stops short of promising feedback on purpose, because the next thing it says might be a question. That same message is then edited in place as the review progresses, so the thread holds one message that keeps up to date rather than a progress log. In a direct message there is no status message at all: Slack's own loading indicator carries the progress and clears itself when the review lands. **The bot may ask one question first.** It opens the first link and looks at it before deciding, so if the page is behind a sign-in wall, or the request could mean any of several flows, it turns that same status message into a single short question with up to three quick-reply buttons. Click one or just reply in the thread; either way the review starts from your answer. Nothing is left hanging in the background while it waits, so an unanswered question costs nothing. Otherwise it reviews straight away. A web page is reviewed by **using** it: the reviewer drives a real browser, opens menus, fills forms and walks the flow, and the reply names the screens it went through. Where it cannot do that (a Figma link, a page that will not open), it falls back to reviewing what it can capture. When it captures instead of driving, that happens per link: - A **web page** is opened in a hosted browser and captured from the top down, several screens' worth. Deliberately not the full page: a page capture 20,000 pixels tall is downscaled into an unreadable strip before a model ever sees it, which is the worst possible input for a review of the visual design. - A **Figma link** is rendered through your workspace's Figma connection. A URL that names a node renders that frame; without one, the file's first frame. The reply is a short summary and then the findings, most serious first. Each finding carries a severity (critical, issue, suggestion, info) and a category (usability, accessibility, visual, content, interaction, performance). A long review is trimmed to the top eight findings with a count of what was left out, so the thread stays readable. A link that cannot be opened costs that link, not the review: the others still come back, and the thread says which one failed and why. ## 4. Turn it on in a channel [#4-turn-it-on-in-a-channel] Direct messages work on their own. A channel is for teams that share work in the open, where nobody should have to remember to mention a bot. Under **Design reviews > Settings**, add the channel. Every message posted there that carries a link and asks for feedback then starts a review, with no mention needed. Two things have to be true for that channel to work, and the settings page checks both against live Slack state rather than a stored flag: - **The bot is in the channel.** Run `/invite @Stunt Double` in it. Slack only delivers messages from channels the app has joined, so without this the channel looks configured and silently never fires. - **The connection can read messages there.** Being mentioned in a channel is a different permission from reading it, and public and private channels differ again. A connection made before the permission was requested keeps its old grant, so the page prompts for a reconnect naming the channel it affects. **Try it** on the same page posts a request in the channel as the bot and reviews it, so you can watch the whole flow before asking your team to use it. Turning a channel off removes the automatic behavior, not the feature: an @mention with a link and a request still starts a review anywhere the bot has been invited. ## 5. Ask the agent for anything else [#5-ask-the-agent-for-anything-else] Anything that is not a link plus a request for feedback goes to the agent. It runs against one workspace, with the same read and dispatch surface as the [MCP server](/mcp): - List the projects, actors, checklists, and workflows in the workspace. - Start a checklist run and hand back the run it created. - Start a workflow run. Both surfaces work: a direct message, or an @mention in any channel it has been invited to. Replies stream in as they are written rather than landing all at once. A thread is one conversation. The first message starts a session that stays warm for a day, and every follow-up in that thread feeds the same conversation, so "run that one again" resolves to the checklist you were just discussing. The direct message also pins a few starting prompts to the top of the Messages tab. Runs started from Slack are attributed to the person who asked, as long as they have linked their Slack identity in their notification settings. Everyone else's runs are attributed to whoever installed the connection, which is worth fixing before a team leans on this: attribution is what makes a run's history legible a month later. ## When nothing happens [#when-nothing-happens] Slack failing quietly is the normal failure here, so work down this list in order: 1. **The message has no link, or no request phrase.** Both are required on every surface. Add "can I get some feedback on this?" and post it again. 2. **It was a reply in a thread nobody has reviewed yet.** A reply only starts a review when the thread already holds one. Post the link as a new message. 3. **The bot is not in the channel.** Run `/invite @Stunt Double` there. 4. **The connection is missing a permission.** **Design reviews > Settings** names this against each configured channel, with a reconnect button. 5. **The workspace is over a usage limit.** The thread says which limit was hit rather than going silent. Reviews and agent runs are metered against your plan like any other browser work, plus the tokens the review spends. A review that drives the page uses one browser session for the whole thing, however many links the message carried; one that falls back to capturing screens uses one per link. ## Tips [#tips] - Turn design review on in the channel where work already gets shared, rather than making a new one. The point is that nobody changes what they do. - Ask for the review before the internal critique, not instead of it. It clears the obvious contrast, hierarchy, and label problems so your team spends its time on the decisions that need judgment. - Link your Slack identity if you plan to start runs from Slack. Attribution costs nothing to set up and cannot be backfilled. - Send a Figma link with a node selected. The frame you are asking about beats the first frame in the file. ## Next steps [#next-steps] - **[Write checklists that catch real regressions](/tutorials/effective-checklists)** to turn a review finding that keeps coming back into a check that runs on every deploy. - **[Collect stakeholder feedback on a prototype](/tutorials/feedback-widget)** to gather comments in context from the people reviewing the same screens. - **[Automate Stunt Double from Claude](/tutorials/automate-with-mcp)** for the same read and dispatch surface in an assistant rather than in Slack.