Comments

Leave feedback on an element or a passage of text, right inside the prototype. Each thread belongs to the version and screen you reviewed; comments on version 1 don’t appear on version 2.

How it works

1. Open the prototype’s preview link. The review widget is added automatically when you set up and publish with Artor.
2. Choose Comment, then click a button, heading, card, or other element.
3. Type your feedback and press Enter or the send button.

Comments stay with the element and version you’re reviewing, and the pin follows the element as you scroll the page or a panel inside it, resize, or the layout changes. Open a pin to read and reply; the back arrow (or T) returns to the list of threads. If the element isn’t on screen, the thread is still in the list. Reviewing a moving prototype? Pause its animations first.

Signed-in members see the profile picture of the teammate who wrote each comment, and of everyone in the @mention list. That includes signed-in teammates who arrive through a public link. Guests, public viewers and anyone viewing the link as a guest see initials, and a picture that can’t load is tried once more, then shows initials.

While the Comment tool is on, a click on the prototype places a comment and does nothing else: buttons don’t press, links don’t open and toggles don’t flip, even while you’re typing a comment. To use the page without turning the tool off, hold Option (Mac) or Ctrl (Windows, Linux) while you click. The widget’s own controls (the toolbar, pins, the thread panel and the comment box) keep working as usual. Clicking outside the comment box closes it right away when it’s empty; if you’ve typed something, the box shakes on the first outside click (or Esc) and closes on the second, so a stray click never loses your draft.

Commenting on selected text

Select the words you want to discuss, then click the Comment button beside the selection. The quote is highlighted while its thread is open, or while you point at its pin or its row in the comment list, including text that wraps onto several lines. The rest of the time the page reads normally. The quote is also included when an agent reads the thread.

Replying to a thread

Open a thread, type your reply, and press Enter (Shift+Enter adds a line break). While you type, the prototype’s own keyboard shortcuts are paused. Esc closes one thing at a time.

Participants may get an email, depending on their notification settings. Guests aren’t emailed.

Resolving a thread

Choose Resolve when feedback has been addressed. Its pin stays on the page, dimmed, and the thread leaves the comment list; turn on Show resolved in the widget’s settings (R) to see resolved threads in full. Reopen brings a thread back. Any member with access to the version can resolve or reopen any thread.

Mentioning a teammate

Type @ in a comment or reply and choose a teammate. They may get an email if they’ve turned mention emails on in Email notifications.

Editing and deleting your own comments

• Edit: use the pencil on your message. Cmd/Ctrl+Enter saves; Esc cancels. Edits don’t send another notification.
• Delete a message: use its trash icon. You can Undo until you close the thread. Deleting the last message removes the thread.
• Delete a thread you started: choose Delete thread in the thread’s ··· menu. This can’t be undone.

You can’t edit other people’s comments. Guest feedback has its own moderation controls.

Who can comment

Signed-in members with access to a version can read its discussion and add to it from the version’s preview link or the dashboard. Signed in, they also comment as themselves from a public link; members who can’t open the prototype’s Space can get the same widget there, without guests’ email addresses, when the organization allows it. See Teammates on a shared link.

Who can comment through a public link is the link’s Comments on this link setting: Off, Members, or one of three choices that also let people without an account comment. New links use your organization’s default, which asks visitors for a name. See Comments on a shared link.

Comments from people without an account

Depending on the link’s setting (Anyone, Name, or Name and email), guests comment anonymously or give a name (and, with Name and email, an email) with their first comment. They can start threads, reply in their own threads, and edit or delete their own messages.

• Guests only see their own threads, including your team’s replies there.
• Names and emails aren’t verified.
• Guests can’t resolve threads, mention people, or use AI ignore.
• Feedback stays with its version. When a link moves to a new version, earlier guest notes stay on the previous one.
• Guests return in the same browser. Clearing cookies or switching devices makes them a new guest.

See Guest commenting for link settings and moderation.

Triage from the dashboard

Open a prototype in the dashboard to see all its feedback. Versions are listed on the left with their comment counts (“3 comments · 1 new”); pick one to see its threads. Open a thread to read, reply, resolve or reopen it. Guest feedback is labelled as guest.

Filter by Status (open, resolved, or all), Mark all read, or switch between This version and All versions. Each thread’s ··· menu (or right-click) lets you open it in the prototype, copy a link to it, mark it read, resolve it, exclude it from AI, or delete it (threads you started, or guest threads if you moderate guest feedback).

The thread menu in the prototype offers Copy details for AI (for handing one thread to an agent by hand), Copy link, Mark unread, and Delete thread. An orange dot marks threads with something you haven’t read; in the widget, unread status is kept per browser.

If access to a version is turned off or the prototype is trashed, its comments can still be read but not changed.

New comments appear on their own

You don’t need to reload. While you’re looking at the page, new comments, replies, resolves and deletions show up within a few seconds, both in the prototype and in the dashboard. Nothing you’re in the middle of (a draft, an open thread, an Undo) is interrupted.

Reading comments from the CLI

This is how a coding agent works through feedback: read the comments, make the changes, publish the next version, and resolve what it fixed. The Artor skill runs this loop for you; in Claude Code, /artor:address-comments reads the comments on a version and works through them. For setup, see Installing the CLI.

Run these in your linked project folder:

artor comments                       # feedback on the latest version
artor comments --open                # unresolved threads only
artor comments --version 3 --json     # version 3, in a format an agent can read
artor comments --guests-only          # guest feedback only
artor comments --no-guests            # team feedback only

Each thread includes the screen, the element or quote, the messages, and its status.

Resolving from the CLI

artor comments resolve <thread>       # mark feedback handled
artor comments reopen <thread>        # reopen it

Use the thread ID printed by artor comments, or a quoted row number such as "#3". Row numbers change as the list changes, so use the same filters you listed with. Replying, editing and deleting are done in the prototype or the dashboard.

Excluding a thread from AI

Turn on AI ignore to leave a thread for a person when an agent works through feedback. It’s separate from resolving.

artor comments ignore <thread>       # leave this thread for a person
artor comments unignore <thread>     # include it again

How a pin finds its element

A pin remembers what you clicked, not a spot on the screen, and finds that element again each time the page loads, using its text, its test id (data-testid) if it has one, and its position on the page. A test id is the most reliable. If the element can’t be found (for example it’s inside a closed drawer), the thread waits in the comment list and gets its pin back when the element appears.

Comments inside dialogs, menus and tabs

When a comment was left inside something that opens and closes, such as a dialog, a popover, a collapsible section, a tab or a menu, the comment list tells you where it is while that part of the page is closed, for example “Inside the ‘Confirm plan’ dialog”. The same line shows in the thread panel.

For a comment left by a member of your organization, or for a guest’s own comment when that guest is the one looking, an Open it button can appear next to that line. Clicking it presses the control that opens the dialog, tab or menu, scrolls the page to the comment, and the pin appears on the element. Artor offers it only for the opening control the comment recorded, re-checked on the live page: it needs a stable identifier (a data-testid is best; a readable unique id also works) and must be recognizable as a plain opener, such as a button outside any form, a tab, or the <summary> of a collapsible section (see Making a prototype easy to review). Links, labels, buttons inside a form, custom elements, controls with a link or a label around them on the page, and controls set to close or hide something are not offered. Artor checks what the control is, not what the prototype’s code does when it’s clicked, so the result isn’t guaranteed (see Limits).

Otherwise the line stays as a hint, and you open that part of the page yourself. That’s the case for comments left by guests through a public link, for a dialog or popover the prototype opens from its own code rather than from a control tied to it, for some component libraries’ dialogs and menus that don’t tie their opening button to what it opens, and for tabs that only link the selected tab to its panel.

Comments on other states of a page

A different path or hash route (/#/settings) is a different page, with its own comments. A different query string (?tab=insights) is another state of the same page: a comment left there also shows where you are when the element has its own test id and the same text. Otherwise it’s listed under Other states of this page, and selecting it takes you there.

Making a prototype easy to review

Give the parts reviewers comment on a unique data-testid, and every pin lands exactly where it was left, even when the same label appears several times:

• Tag interactive elements and meaningful blocks: buttons, links, inputs, tabs, cards, rows, dialogs. Put a short, readable name on the element itself, such as checkout-apply-coupon.
• Tag the buttons that open dialogs, menus and tabs too, and tie them to what they open (the usual aria-controls, or popovertarget for a popover). That lets reviewers reopen a comment left inside with one click (see Comments inside dialogs, menus and tabs).
• Name repeated items by their own ID, not their position: order-row-o-1042, not row-5.
• Keep state out of the id: nav-insights, not nav-insights-active.
• Label things without text. Chart bars, legend items and icon-only buttons need a test id and an aria-label.
• Never reuse an id on the same page, and don’t remove ids that already exist.

<button data-testid="checkout-apply-coupon">Apply</button>
<li data-testid="order-row-o-1042">…</li>
<button data-testid="toolbar-share" aria-label="Share">…</button>

If you build with a coding agent, you don’t need to explain this: artor init and artor publish add these rules to your project’s agent instructions. See Review-anchor notes for coding agents.

Adding the widget to your project

artor init adds the review widget to your app for you, in Next.js, Vite, Create React App and Angular projects. If it can’t find where to add it, it tells you what to add yourself. A project that already has the widget is left alone, and running artor init again changes nothing.

Keeping the widget up to date

Each version keeps the widget it was published with. For a project that lists the widget as "latest" (what artor init sets up), publishing is all it takes to get the newest one:

artor publish

artor publish updates the widget before it builds. If your project pins a version instead, set it to "latest" in package.json. Avoid npm i @artorapp/web-sdk@latest: it saves a fixed version range, and later publishes then leave the widget alone. Static HTML prototypes always get the current widget. See Keeping the review widget current.

Limits

• Comments are plain text, without formatting or embedded images.
• A thread stays on the version where it was left; it doesn’t carry over to the next version.
• New comments don’t appear while the tab is in the background; they arrive when you come back.
• If a link moves to another version while you have it open, reload the page to review the new one.
• Deleted threads can’t be recovered. Deleting a version or permanently deleting a prototype deletes its comments.
• Without test ids, a pin can land on whatever took the element’s place, such as the next row after a row was removed. A unique test id prevents this.
• The review widget runs inside the prototype. Only review prototypes you trust with what you type, including guests’ names and email addresses.
• While a teammate has the prototype open, any script in it, including third-party scripts it bundles such as analytics or session replay, can collect the profile pictures of everyone in your organization who has one, along with their names. Keep that in mind before adding third-party scripts to a prototype.
• Open it presses a control in the prototype for you, only when you click it, only on a comment from a member of your organization (or, for a guest, on their own comment), and only a control the prototype ties to that dialog, tab or menu. If that control also does something else in the prototype, that happens too. A button that a component’s hidden internals wrap in a link follows that link, just as your own click would. Open it has been tested in Chromium-based browsers, such as Chrome and Edge, and in Safari’s engine; Firefox is untested.
• While the Comment tool is on, the page ignores mouse and touch clicks, but keyboard use (Enter or Space on a focused control) still reaches it, and so does anything inside an embedded frame. On a touch screen, the prototype’s own touch handlers still run. On a Mac, Ctrl-click opens a context menu rather than clicking, so turn the tool off (C) to use the page.

Related

• Reviewing a prototype
• The publish → review loop
• Public sharing
• Email notifications