Enloop.md - managing human attention in AI loops

The human is the slowest step in any AI feedback cycle. Enloop makes that step ruthlessly effective.

Fix the Bottleneck in Human-in-the-Loop. The human is the slowest step in any AI feedback cycle. Enloop makes that step ruthlessly effective. By handling the heavy lifting of context and instruction, it frees you to operate at the speed of thought, turning validation from a chore into a seamless flow. Enloop is a side panel that runs manual and automated test cases, and a set of agent skills — for Claude Code and Codex — that write those cases from your app's own source. WHAT THE PANEL DOES - A test case is one Markdown file in a folder you pick. No server, no account, nothing uploaded — diffable files you commit next to the code they test. - Run a case step by step: Go opens the screen a step names, Highlight scrolls to the element it points at and flashes it, quoted values type themselves into the page, and scripted steps run in the page and decide their own result. - One case, two depths: steps marked as the core path make a two-minute Quick run of the same case a Full run covers completely — written once, never duplicated. - Values resolve when the run starts, not when the case was written: a BASE_URL follows whichever deployment you have open, can be pinned to a domain pattern so a random tab is refused, and falls back to the environment the case declares. - Optionally capture what the page said during the run — console errors and failed requests land in the report beside the step where they happened. - Every run freezes the exact case it executed and writes a readable report, plus a feedback file where each comment is addressed to whoever it is for: developer, product, test writer, docs, ops. - Share a case as a link (the case travels inside the URL — still nothing uploaded), as a self-contained HTML page anyone can open with no install, or as plain Markdown. WHAT THE SKILLS DO The same repo ships agent skills for Claude Code and Codex that close the loop around the panel: - setup prepares an app repo once: the project name, the base URL cases default to, and the test-selector convention, so new UI arrives already instrumented. - quick writes the two-minute happy-path case for the branch you are on; full extends it into the complete article — edge cases, error states, cleanup. Every route, label and selector is read from your app's source, and the case is validated with the real parser before it lands. - check triages a finished run back in the repo: for every failure it decides — app bug (with file and line), defect in the case itself (fixed on the spot as a new version), or environment — and promotes standing feedback into project rules every future case obeys. - instrument adds missing test handles to your code, following the convention your repo already uses. Cases written by the skills meet a cold-runner bar: someone who has never seen the system can click through — every address one click away, every value prepared, zero questions before the run starts. Open source, MIT licensed. The extension, the parser, the online viewer and the skills are one repo: https://github.com/enloop-md/enloop # Enloop changelog ## 0.13.0 — 2026-09-02 Extension 0.13.0 · plugin 0.15.0 · grammar 0.0.9 · daemon 0.1.0 ### Writing cases - **Domains and environments.** A case declares every deployment it touches under `# Domains` (`## APP`, `## ADMIN`), each with a `Default:` origin and an optional `Match:` glob, and uses them as address prefixes: `Where: %APP%/admin/reports`. An **environment** is a named set of domain addresses and variable values — local, staging, prod — kept in `environments.json` beside the cases and picked before a run; pick none and the main domain follows the open tab. The legacy `BASE_URL` variable still parses; the linter asks for it to become the main domain. - **Variables are never asked of the tester.** Every variable resolves before the run from a `Default:`, a `Generator:` or the environment; one with none of the three is a linter error, not a prompt. - **Step groups.** A case covering a broad change is written as concerns: `# Steps: Log in`, `# Steps: Restore password`, each opening with its goal — what its steps prove together — before the first step. Groups head the step list in the panel with a running tally; `report.md` and `feedback.md` open with a **By group** summary. The linter requires the goal and refuses an empty or duplicated group (rule 9). - **Ratings feed the next case.** `enloop-case.mjs ratings` aggregates every rated case and step for a project, with the frozen step text and the tester's comments; the authoring procedure reads it, and the check skill treats a poorly rated step as a defect to fix. - **Where and Note reach the panel.** A step's `Where:` address and `### Note` were parsed and frozen but dropped on the way into the run screen. Both show now, with the Go control on the address. ### Running cases - **Star ratings.** Rate a step, or the whole case, one to five stars — independent of pass or fail. Ratings land in `run.json`, `report.md` and `feedback.md`, where four- and five-star steps are listed as the shape to write in and one- and two-star steps as the shape to avoid. - **Comments, faster.** The audience row is condensed to names, with a **What do these mean?** toggle for the legend that remembers its state. **Add comment** lights up the moment there is text and clears the ticks after. A one-tap **Combine with previous step** chip adds the standard note to the test writer; the check skill merges the two steps in the next version. - **Comments for all steps.** A finished run shows its feedback text — every comment, rating and failure, grouped by audience — with **Copy** and **Download .md**, so a tester with no agent on their machine can hand the run to someone who has one. The check skill accepts that file pasted in place of a run folder. - **The agent says what it is doing.** While a question is being answered, the panel shows the server's own status line — *Reading ResetForm.tsx*, *Found it — the step names a renamed button*, *Writing the answer* — and how long ago it changed, instead of one unchanging "working on the answer". The serve skill writes `progress.json` as it goes; the daemon reports every file the model opens and asks the model to narrate through a `progress` tool, and drives headless Claude Code with streamed output so its tool calls are read live. ### Plugin and daemon - The plugin's `setup` skill writes environments, the authoring skills read this project's ratings, and `brief` lists rule 9. - The daemon stamps its version into its watcher file and warns once per folder when the extension's heartbeat speaks a different channel protocol. 0.12.0 - The panel checks whether an agent is actually serving your folder — nobody listening shows setup instructions right where you'd otherwise wait (recommended: the new enloopd daemon — always on, no Claude Code session to keep open; or a one-off /enloop:serve pass). - Answers can come from the very session that authored the case: cases are stamped with their authoring session, and the daemon resumes it per question — even across multiple isolated projects on one machine. - The panel shows who is answering (Claude Code vs. the daemon); questions keep their page URL even on sites you haven't granted yet. 0.11.0 - Version history now says who wrote what: mid-run patches land as minor versions (v1 → v1.1, v1.2); authored versions stay whole numbers (v2). Runs, reports, and hot-swaps understand both. 0.10.2 - The panel shows when an agent has picked your question up ("working on the answer…"), not just that you're waiting. - The step you asked from can be fixed even after you marked it — loading the patch resets just that one result so you redo it against the new text. 0.10.1 - Questions carry their evidence: a screenshot and a snapshot of the page's structure (plus its URL) go along by default, so answers are grounded in what you're actually looking at. 0.10.0 - The live agent channel: Ask the agent from any step mid-run and get the answer in the panel; if the step itself was unclear, load the corrected version into the running test with one click — finished steps keep their results. Setup commands written in a case get a Run button with live output and Stop. - Extra steps: Kind: extra marks opt-in side-checks that number as 2.1/2.2 and start a run skipped; any step can be skipped mid-run, and skips land in feedback for the test writer. - Highlight and value insertion find elements inside iframes (cross-origin included), not just the top frame. (Shipped to the store as 0.9.1.) 0.9.0 - Published on the Chrome Web Store, with a stated privacy policy: no server, no account, nothing leaves your machine. - Environments: named value sets per project — pick one before a run and the case's variables fill themselves; the run records where it ran. - The cold-runner bar: cases are held to "runnable from a blank tab" — every address written as %BASE_URL%/route, a stated account, and the validator's cold run line saying how much is one-click. 0.8.0 - Capture every request during a run (not just failures, when you opt in), and read BASE_URL straight off the open page — with domain patterns so an unrelated tab is refused. 0.6.x - Comments ask who it's for (developer, product, test writer, docs, ops) instead of what kind it is — audiences become sections in the run's feedback file. - A comment you typed but never pressed Add on is saved anyway. 0.5.x - Connect several folders at once — the Library merges all of them, and repo-hosted case folders travel with a clone. - Console capture during runs, recorded beside the step where it happened; asked about up front, decided at finish. - Share links carry the case compressed in the URL fragment — still nothing uploaded. - The bundled example became a tour of every panel control; Enloop got its name, icon, and the quick/full authoring split.