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