Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/mentilead/shopify-app-skillWrote 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/commands/mentilead/shopify-app-skill/add-e2e-test)<a href="https://agentmods.dev/commands/mentilead/shopify-app-skill/add-e2e-test"><img src="https://agentmods.dev/badge/commands/mentilead/shopify-app-skill/add-e2e-test/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/mentilead/shopify-app-skill/add-e2e-test"><img src="https://agentmods.dev/badge/commands/mentilead/shopify-app-skill/add-e2e-test.svg" alt="Reviewed on agentmods" width="80" 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.00000 | $0.00537 |
| Opus 5.5 | $0.00000 | $0.00215 |
| Sonnet 5.5 | $0.00000 | $0.00107 |
| Haiku 4.5 | $0.00000 | $0.00054 |
Grade A, and why
add-e2e-test 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 1mo 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 — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Add E2E Test
Scaffold a Playwright end-to-end test with FrameLocator for embedded Shopify app testing.
Arguments
$ARGUMENTS = feature or page to test (e.g., "form editor page", "billing upgrade flow", "settings CRUD")
Instructions
- Parse the test target from
$ARGUMENTS. If empty, ask the user what feature or page to test. - Read
.claude/skills/shopify-app/references/testing-patterns.mdfor the three-tier strategy, FrameLocator pattern, and auth setup. - Determine which test tier is appropriate:
- Unit (Vitest) — for service function logic, key builders, mappers
- Mock-bridge CI (Playwright + mock) — for UI flows without Shopify auth
- E2E (Playwright) — for full embedded app flows inside Shopify admin
- Create the test file in the correct location:
- Unit tests:
tests/unit/<feature>.test.ts - E2E tests:
tests/e2e/<feature>.spec.ts
- Unit tests:
- For E2E tests, use the FrameLocator pattern:
- Import helpers:
getAppFrame,navigateToApp,waitForPageTitle - All selectors go through
frame.getByRole(),frame.getByText(), etc. - Never use
page.locator()directly — the app runs in an iframe
- Import helpers:
- Structure the test with:
test.describeblock for the featuretest.beforeEachfor navigation and setup- Individual
testblocks for each scenario (happy path, error cases, edge cases) - Assertions using
expectwith appropriate matchers
- For tests that need authenticated state:
- Use the auth setup from the test helpers (cookie-based or token-based)
- Handle the Shopify admin login flow if testing full E2E
- For tests that modify data:
- Clean up created data in
test.afterEachor use unique identifiers per run - Consider test isolation (each test should work independently)
- Clean up created data in
- Add the test to the appropriate CI config if it's a unit or mock-bridge test.
- Remind the user to:
- Run unit tests:
npm testornpx vitest - Run E2E tests locally:
npx playwright test(requiresshopify app devrunning) - E2E tests don't run in CI — they require a live Shopify dev store
- Run unit tests:
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.
- 1mo ago First seen · 40 lines · 0 tokens per session scan A b4d510fe9b48
add-e2e-test is a command published in the GitHub repository mentilead/shopify-app-skill (6 stars, last pushed 7mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 537 tokens. 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-31.
Other commands, from other repositories
expect
Diff-aware AI browser testing — reads the git diff, maps changes to affected pages via the route map, generates a targeted test plan, and executes it via agent-browser (Rust daemon + CDP, ARIA-tree-first) with pass/fail reporting. Use when testing UI changes, verifying PRs before merge, or running regression checks on…
record
Record a browser walkthrough of a URL using Antigravity (agy). Generates .webm video, screenshots, and a report. Auto-converts to MP4 if ffmpeg is available.
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
amazing-e2e-check
Run explicitly requested E2E, browser, device, or installed-deployment scenarios in an independent verification workflow.
verify-pr
Verify a PR's frontend changes through browser automation.
auto-verify
A command for checking a website's front-end user experience with Playwright, a tool that automates web browsers.