# Slop Off

> Process Slop Off browser reports via the slop-off MCP server and apply the edits to the current project's source. By default keeps looping over reports until the user stops. Use for "/slop-off", "apply my edit report", "wait for my browser edits", or after the user has made edits in the browser with the Slop Off extension.

- Skill: `wbso-ai/slop-off` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wbso-ai/slop-off`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wbso-ai/slop-off/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: wbso-ai (https://skillmd.com/u/wbso-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wbso-ai/slop-off

---


# Apply browser edits

Process reports from the `slop-off` MCP server and apply them to the
source. Everything happens in the MAIN thread — no subagents — so every
report gives an immediate "✅ …" line and nothing sits between the queue
and the work.

## Mode

- **Default (loop)**: say once "Waiting for browser edits — say 'stop'
  when you're done", then loop:
  1. Call `wait_for_report` with timeout_seconds: 60. Empty? Call it
     again, silently — empty waits are normal. After ~10 consecutive
     empty minutes, mention in one line that you're still waiting (don't
     ask, don't stop); repeat that at most once an hour.
  2. Report received → apply it per "Apply edits" below, then follow
     "Per processed report".
  3. Loop again immediately — more edits may already be queued.
  Stop only when the user says "stop" (or "done").
- Argument `once`: process exactly one report and stop.
- Argument `latest`: call `get_latest_report` (don't wait), process,
  stop.
- Argument `list`: call `list_reports`, show the queue, ask which one.
- Argument `clear`: call `clear_reports` and report in a single line how
  many reports were cleared. Process nothing, then stop.

## Apply edits

The report contains per-URL sections with Before/After HTML pairs and/or
Element/Instruction pairs, each with a CSS selector as a hint.

1. For each edit find the source file that renders that page/HTML: search for
   distinctive text from the Before block (literal strings first,
   then fuzzy). The URL says which route/page; the selector where in the DOM.
2. Replace the Before content with the After content. Preserve existing
   formatting, indentation and templating (translate HTML changes into the
   template/JSX/component if the source isn't plain HTML).
3. Not found? Report it explicitly with the closest match — never
   silently guess or skip. Then just continue the loop.
4. Placeholder, href and other attribute changes are attribute edits;
   change only that attribute.
5. Element/Instruction pairs are annotations: find the element (selector +
   Element snippet) and carry out the instruction on that element in the source.
   These are free-form tasks ("make this shorter", "different color") — carry
   them out to the best of your judgment and report what you did.

## Per processed report

- Run a quick check if the project has one (typecheck/lint; no
  full build per report in loop mode).
- ALWAYS call the slop-off MCP tool `notify_browser` with a concrete 1-2
  line summary of what changed (e.g. "Hero heading and CTA text updated in
  index.html") — also on failure, never with an empty message. The
  extension shows it as a toast on the page, and the call marks the report
  as done in the browser HUD: skip it and the report stays stuck on
  "applying" for the user.
- Report to the user in a single line: "✅ N change(s) applied — file1,
  file2 · M still queued" (N and M come from the report header; when M is
  0 say "· queue empty, waiting"). Only if something failed a second
  line: "⚠️ not applicable: …". No further explanation.
- Go straight back to waiting.