Borrowing it
Nothing to install: this file belongs to TOMOSIA-VIETNAM/open-pr. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/TOMOSIA-VIETNAM/open-pr/main/.claude/skills/e2e-loop/SKILL.mdgit clone --depth 1 https://github.com/TOMOSIA-VIETNAM/open-prWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tomosia-vietnam/open-pr/e2e-loop)<a href="https://agentmods.dev/skills/tomosia-vietnam/open-pr/e2e-loop"><img src="https://agentmods.dev/badge/skills/tomosia-vietnam/open-pr/e2e-loop.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00085 | $0.01396 |
| Opus 5 | $0.00043 | $0.00698 |
| Sonnet 5 | $0.00017 | $0.00279 |
| Haiku 4.5 | $0.00009 | $0.00140 |
Grade A, and why
e2e-loop scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
e2e loop
The unit suite proves the prompt graph is well-formed. It cannot prove a review still comes out right. This closes that gap: run → grade → diagnose → fix → re-run, with the running and the grading done by DIFFERENT agents so neither marks its own work.
Costs real money and posts to a real PR on open-pr-test. Never start a round the user did not ask for.
Why subagents rather than this session
A dev session already knows which defects the fixture plants and which rule was just edited. Reviewing from that context tests the session's memory, not the prompts. Each round therefore spawns fresh agents that were told nothing beyond what a real user's session gets.
Round budget
Ask for max_rounds if the user did not say; default 2. Stop early when every checklist row passes,
or when a round produces no NEW passing row — a loop that keeps editing without moving the score is the
failure mode this skill is most likely to hit.
Preflight
scripts/check.sh <base-ref>must be green. A red suite makes every later verdict unreadable.e2e/bootstrap.sh --pr <n> [--vendor …]if no fixture PR is open for this round.python3 scripts/vendor_lint.py --pr <n>— every documented Fetch command must run. A broken vendor command wastes a whole round: the review fails at fetch and every checklist row readsfailfor a reason that has nothing to do with the rules being tested. Seconds, and free.- Note the fixture URL. Every later stage refers to it.
Stage 1 — run the review (subagent, fresh)
Spawn a subagent whose whole brief is:
Read<repo>/src/commands/review.mdVERBATIM and follow it against<fixture PR url>. Wherever it says${CLAUDE_PLUGIN_ROOT}, substitute<repo>/src— you are exercising the WORKING TREE, not the installed plugin. You have no other instructions and no knowledge of what the PR contains.
FORBIDDEN: paraphrasing the command file into the brief, hinting at the planted defects, naming the stacks involved, or telling it what a good review looks like. Every one of those invalidates the round.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 113 lines · 85 tokens per session scan A 4963ab7b0863
e2e-loop is a skill published in the GitHub repository TOMOSIA-VIETNAM/open-pr (42 stars, last pushed 2d ago), licensed MIT. It adds 85 tokens to every session and 1,396 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
playwright-stability
Make a Playwright E2E suite stable and realistic — kill flaky tests and authenticate like a real user via storageState (login once, reuse). Use when E2E tests are flaky, slow, re-login in every test, mock auth instead of using it, or when hardening a suite before relying on it.
live-qa
Exploratory QA of a running app by driving a real browser like a user via the Playwright MCP server. Use when the user wants to "QA" a feature live, walk a flow as a real user, smoke-test before a PR, or find issues that scripted specs miss. Complements deterministic Playwright specs — this is the human-like…
tdd-workflow
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
e2e-testing
Playwright E2E testing patterns, Page Object Model, configuration, CI/CD integration, artifact management, and flaky test strategies. Use when writing Playwright tests, structuring page objects, or fixing flaky E2E runs in CI.
atf-testing
Build ServiceNow Automated Test Framework tests and suites — impersonation, form steps, assertions, server-side script steps, test parameters, and execution via snowcreateatftest / snowexecuteatftest.
acceptance
A skill for writing, running, and repairing human-written acceptance checks stored in an `acceptance/ACCEPTANCE.md` file. Acceptance checks are executable tests of whether the finished result matches the requested outcome.