Enloop.md - managing human attention in AI loops

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 past…