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.
npx skills add 3awny/qship --skill qe2etestgit clone --depth 1 https://github.com/3awny/qshipWrote 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/3awny/qship/qe2etest)<a href="https://agentmods.dev/skills/3awny/qship/qe2etest"><img src="https://agentmods.dev/badge/skills/3awny/qship/qe2etest/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/skills/3awny/qship/qe2etest"><img src="https://agentmods.dev/badge/skills/3awny/qship/qe2etest.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.00036 | $0.10281 |
| Opus 5 | $0.00018 | $0.05140 |
| Sonnet 5 | $0.00007 | $0.02056 |
| Haiku 4.5 | $0.00004 | $0.01028 |
Grade A, and why
qe2etest scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
**An E2E pass requires invoking the same entrypoint production uses.** A unit test, a Python REPL call into the changed function, or "the migration applied cleanly" is NOT an E2E pass — it's a partial check. If the chang How it starts
The opening of the file, as written. The whole thing — 529 lines — stays where its author put it; the contents beside it link to each section on GitHub.
End-to-End Test of the Current Change
Run a full end-to-end test of whatever was implemented in this conversation. The goal is a comprehensive scenario matrix that leaves nothing questionable — exercise every layer the change touched, prove the change works through real (not mocked) interfaces, and surface anything that doesn't.
Scope: This drives the change against your primary service (started by
/qspinuplocal). If your change spans multiple services, start the others yourself and add their triggers to the scenario matrix —/qspinuplocalis single-service by design.
Companion skills
/qspinuplocalowns the local stack lifecycle for your primary service (against a local DB). This skill always calls/qspinuplocalfor spin-up — it handles.envoverrides, theload_dotenv(override=True)footgun, port collisions, and worktree resolution./qmanualtowns the UI E2E flow (Playwright + Claude in Chrome). For any UI change, hand control to/qmanualtafter the API/worker layer is verified — see "UI testing — delegate to /qmanualt" below.
This skill (/qe2etest) is the orchestrator: it audits the diff, traces every changed code path forward to its production trigger (HTTP endpoint, worker queue, cron, scheduled job), drives those triggers itself against the real stack, delegates UI to /qmanualt, and verifies in the DB. It runs /qspinuplocal to start the stack.
The cardinal rule
An E2E pass requires invoking the same entrypoint production uses. A unit test, a Python REPL call into the changed function, or "the migration applied cleanly" is NOT an E2E pass — it's a partial check. If the change is reachable from a worker, the worker MUST be the thing that fires the code path. If the change is reachable from an HTTP route, curl MUST be the thing that fires it. Always. No exceptions, no shortcuts to "save time."
The single most common failure mode of this skill is the agent verifying a code change at the wrong altitude — proving the function works in isolation while never demonstrating the production trigger reaches it. Section "Step 1.5" below exists to prevent exactly that.
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 · 529 lines · 36 tokens per session scan A 38c6990847c0
qe2etest is a skill published in the GitHub repository 3awny/qship (2 stars, last pushed 2mo ago), licensed MIT. It adds 36 tokens to every session and 10,281 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
browser-check
Drive a real browser and come back with a MEASUREMENT rather than an impression - console errors and >=400 responses as counts, computed styles as JSON when appearance is disputed. Use when work touches UI, when a review must verify one, or when fidelity-gate asks for its measurement.
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.
testing-strategy
Test pyramid, coverage targets, and test patterns (unit/integration/E2E). TRIGGER when: planning tests, writing test code, or reviewing coverage. SKIP: quality-gate scoring of plans (use quality-validation); security testing (use security-review-checklists). (Examples use common runners such as pytest and vitest.).
journey-simulation
Use when caller wants to observe how a stranger encounters a flow, artifact, or sandbox — triggers like "simulate a user journey", "test our onboarding / checkout / signup", "will my ICP convert", "how does a cold reader experience this README", "first-time user test", "cognitive walkthrough", or any request to…
visual-verification
Use for any UI/web project — make the verify gate cover more than unit tests by composing a pipeline (types → unit → design-scan → flow-smoke) and running the built-in yoke flow-smoke gate (landmark + zero console errors + screenshot proof to .yoke/proof/ /, video kept on failure). Catches the unwired-page /…
playwright-setup
Scan project docs/source, interview user, create Playwright E2E test specs + config from scratch for any app.