sluglist

Use cases

One contract, four ways in

Feedback moves from whoever found the problem to whoever fixes it. Both ends can be a person or an agent, and in every combination the thing that travels between them is the same: a folder of plain files with a documented format. Pick the end you are standing at.

Whoever finds it

reports

Human
  • A client signing off a release
  • A PM or tester walking a checklist
  • A customer hitting a bug in production
  • You, on your own laptop
Agent
  • A QA agent driving a real browser

The artifact contract

a folder of plain files

session-2026-08-16-a1b2/
  session.yaml
  01-save-does-nothing.md
  01-save-does-nothing.png
  fixes.yaml
passfailnot tested

Versioned, additive-only, documented field by field.

Whoever fixes it

resolves

Human
  • A developer opening the report
  • Anyone the single-file HTML gets forwarded to
Agent
  • A fix agent that localizes and patches
  • Any script that can read files
Both ends can be a person or an agent, in any combination — the files in the middle do not change. That is the whole standard: the report is the interface, not a dashboard, an inbox or an API.

You, with the app running on localhost.

Click the bug on your running localhost app and it becomes a file: screenshot, selector, component, console errors, action trail — in a local folder your coding agent reads.

  • Describing a bug costs one click
  • Nothing leaves the machine
  • Your agent stops guessing where
Catch it while you build — feedback from yourself

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

Put a build on staging with a checklist of what shipped. The client, PM or tester walks it, checks items off, flags problems visually — and you get a coverage map, not a chat thread.

  • A coverage map instead of “looks good 👍”
  • Nothing for them to install or sign up for
  • You do not write the list by hand
Acceptance testing with your client, PM and testers

Real users in your beta or production app.

Let real users report problems with an annotated screenshot — inputs masked, PII scrubbed from text, delivery through an endpoint you own. MIT, self-hosted, no accounts.

  • The report arrives with the context you would have asked for
  • Privacy is the default, not a setting you remember
  • It cannot become your problem
A “Report a problem” button for beta & production

A repo where an agent can run the app in a browser and edit the code.

A QA agent walks the checklist in a real browser and writes evidence-backed verdicts; a fix agent answers them; a re-test round closes the loop — and sluglist status decides when to stop.

  • Evidence, not claims
  • The loop stops for the right reasons
  • You get an audit trail, not a “done”
An autonomous QA loop: test, fix, re-test, until green

Working with a specific tool