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 prioritised 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

Open Settings > Design review and connect Slack for the workspace. That is the whole setup. The Slack app already declares the events and permissions it needs, so nothing has to be wired up by hand.

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.

Figma is the one extra, and only for Figma links. Connect it from the same page 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

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:

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.

Only a new top-level message starts a review. A reply inside an existing thread is follow-up conversation and goes to the agent, so you can discuss a review in its own thread without starting another one.

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

The thread answers immediately, before any work has started: "On it, reviewing the link and posting feedback here." 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.

Then, 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

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 Settings > Design review > Channels, 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 behaviour, 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

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:

• 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

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. Only a new top-level message starts a review.
3. The bot is not in the channel. Run /invite @Stunt Double there.
4. The connection is missing a permission. Settings > Design review 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: one session per link reviewed, plus the tokens the review spends.

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 judgement.
• 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

• Write checklists that catch real regressions to turn a review finding that keeps coming back into a check that runs on every deploy.
• Collect stakeholder feedback on a prototype to gather comments in context from the people reviewing the same screens.
• Automate Stunt Double from Claude for the same read and dispatch surface in an assistant rather than in Slack.