Does the client need an account or an app?

No. The widget lives on your staging site; the client just opens the link you already sent them. There are no sluglist accounts at all.

Can I see what the client didn't test?

Yes — that is the point of the coverage map. Every checklist item ends the session as pass, fail (linked to the flagged issue) or null (never checked), so untested areas are explicit.

Where do the reports and screenshots go?

To connectors you configure — typically a thin API route that writes to your own storage (Vercel Blob, S3/R2, Supabase). Nothing is sent to sluglist; there is no hosted service.

Can checklist verdicts carry over to the next session?

No, deliberately. The checklist is a session input and verdicts are its output; every session runs it from scratch. sluglist stays a capture tool, not a workflow tracker.

Client & team acceptance testing with a visual checklist

A release needs a sign-off, and “looks good 👍 in the chat” is not one. sluglist puts an acceptance checklist directly on the staging site: the reviewer checks each row off where the feature lives, flags what is wrong with an annotated screenshot, and the result is a machine-readable coverage map — plus one HTML file you can forward.

ForThe people who decide whether it shipped correctly — the client, the PM, the tester.

How it works

mountFeedbackWidget(
  createFeedbackWidget({
    project: "acme",
    connectors: [new HttpConnector("/api/feedback", () => token)],
    checklist: "/checklist.json",   // or an inline object
  })
);

A second circle appears above the feedback button. The reviewer opens it and sees your list — sections, items, hints, and "Open ↗" links that navigate to the right page. One natural motion per item: click the row to check it off; click the slug button to flag a problem (that opens the normal issue flow with screenshot and annotation, linked back to the item).

The output: a coverage map, not a thread

Every verdict lands in session.yaml:

checklist:
  items:
    - id: export-button
      title: "On Reports, the Export button downloads a CSV"
      verdict: pass
    - id: csv-columns
      title: "The CSV has all the expected columns"
      verdict: fail
      issue: "03"        # the annotated issue that documents it
    - id: email-sent
      title: "An email arrives after an export"
      verdict: null      # never checked — you know what wasn't looked at

Three states, not two: confirmed, flagged (with the evidence attached), and never checked.

Generate the checklist from the branch

Don't write the list by hand: the bundled sluglist-checklist skill turns the branch diff into a client-facing checklist — user-visible changes only, phrased for a non-developer. See Checklist mode.

Send back one file, not a folder

npx sluglist report

The session becomes a single self-contained HTML file: what passed, what failed, the fact observed behind each verdict, every screenshot inlined. It opens offline, forwards as one attachment, and prints to PDF cleanly — the artifact a client can actually read. See Reports.

Built for non-technical reviewers

Flagging a problem takes a comment and an automatic screenshot; annotation (arrow, box, text) is right there.
Smart links navigate the reviewer to the page under test; wildcard matches light up "You're here" on dynamic routes.
The checklist panel is fully usable on a phone.
Reporter form fields can ask what only they know (device, severity, which account).
They can attach their own files — a phone screenshot usually arrives via paste.

Where the feedback goes

Through a connector you own — an API route in front of Vercel Blob, S3/R2 or Supabase Storage is ~50 lines. No sluglist account, no third-party inbox holding your client's screenshots.

The same checklist can be walked by a QA agent instead of a person when you want a pass before the client sees it — the artifacts are identical either way.

Acceptance testing with your client, PM and testers

A coverage map instead of “looks good 👍”

Nothing for them to install or sign up for

You do not write the list by hand