sluglist

Use case

Catch it while you build — feedback from yourself

The bug you find in your own app at 2am is the one that gets lost. A note in a scratch file loses the screenshot; a memory loses the console error. Click it instead: the report lands in a folder next to your code, and the agent that fixes it reads the same folder.

ForYou, with the app running on localhost.

01

Describing a bug costs one click

You are already looking at it. Click the element instead of writing a paragraph — the screenshot, the CSS selector, the nearest React component, the console error and your last few actions are attached for you.

02

Nothing leaves the machine

A sidecar bound to 127.0.0.1 writes into a local .sluglist/ folder. No account, no upload, no dashboard — and the folder is gitignored by the installer.

03

Your agent stops guessing where

component: AnimalForm plus a stable selector plus a PATCH 500 in the error trail usually names the file before the agent opens anything.

Set it up once

npm install sluglist
import { createFeedbackWidget, mountFeedbackWidget, LocalConnector } from "sluglist";

mountFeedbackWidget(
  createFeedbackWidget({
    connectors: [new LocalConnector()],
  })
);

Gate it behind an env flag so it never initializes in production — enabled: process.env.NODE_ENV !== "production".

Then, next to your dev server:

npx sluglist dev        # writes to ./.sluglist, port 4477

Browser JavaScript cannot write to disk, which is the only reason this process exists. It binds 127.0.0.1, has no authentication, and is not meant to be exposed.

Use it while you work

Click the launcher (or press Shift+F), pick an element, type what is wrong. Every issue arrives as a folder of plain files:

.sluglist/session-2026-08-16-a1b2/
  session.yaml
  01-save-does-nothing.md          # frontmatter + your comment + ## Errors + ## Actions
  01-save-does-nothing.png

When a bug needs a sequence, record mode captures a screenshot per click and navigation, so the report carries steps-to-reproduce as numbered frames instead of a sentence you have to write.

Hand it to the agent

npx sluglist init       # skills, .sluglist/checklists/, .gitignore rules, PROJECT.md

Then tell Claude Code "read feedback and fix it." The bundled sluglist-fix skill reads each issue, looks at the screenshot, localizes by component and selector, fixes the code, and records the outcome in fixes.yamlfixed, wontfix or needs_info, never a guess.

npx sluglist status     # what is still open, and what a pass left unanswered

Where it goes next

The same widget, one config line different, collects feedback from your team and from real users — with the same artifact format, so nothing downstream changes. And the whole cycle can run agent to agent when you want the tester to be an agent too.

Frequently asked questions

Does the widget slow down my dev build?

The screenshot library (html-to-image) is loaded lazily on the first capture, so it is not in your initial bundle. The widget itself is small, framework-agnostic, and lives in a shadow DOM so it cannot collide with your styles.

What if I forget to start the sidecar?

LocalConnector warns once in the console and the UI is never blocked. Any other connectors you configured still run, and undelivered issues persist in an IndexedDB outbox and retry on the next load.

Should .sluglist/ be committed?

No — sessions are local noise. `npx sluglist init` writes the .gitignore rules that keep sessions out while re-including the two things that belong in the repo: .sluglist/checklists/ and .sluglist/PROJECT.md.

Does this work outside React?

Yes. The widget has no framework dependency; the React component hint is an extra that resolves when a React fiber is present and is simply absent otherwise.

The other ways it is used