running-e2e-verification
Skill0 starsChanged 13 days agoMITView on GitHub
Use when asked to "run the e2e", "smoke test", "verify the full flow" in an environment, to triage an anomaly seen in e2e output, or to run any project-specific e2e skill, in the main thread or as a subagent.
In this repository2 other files it gives its agents.
- implementing-with-gatesSkill
- verifying-changesSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Production: Read-only flows only; leave no test data.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Running E2E Verification
Browser end-to-end runs (Playwright or similar). Short orders are enough: infer env, flow and skill; never interrogate the operator.
Procedure
- Short order. Infer env and flow from the caller's prompt and the runner itself (config, spec names). If the caller names a project e2e skill, use only that one (it owns the harness). Don't depend on CLAUDE.md or workspace docs. Ask only if truly ambiguous; otherwise take the safe default and note it in the report.
- Preflight. Install missing runner deps and browsers before running. A missing dependency is never a product defect.
- Environment. Use the env the caller names, else the runner config's default (e.g. playwright.config
baseURL). A reachable localhost is NOT a reason to use local; local only when explicitly asked. Headless by default. Headed only on explicit request, and never for flows that open native OS dialogs (downloads, Save As): drop headed silently and say why. - Production. Read-only flows only; leave no test data. Ask before changing data in staging or production-like environments.
- Credentials come from gitignored env files. Never print them, commit them, or put them in messages.
- Known intentional behaviors. Before flagging any anomaly, check the known-intended-behaviors list the caller provides (a file path or inline list), if any. When a finding is confirmed intended and the caller gave a file, add a row there; otherwise list it in the report as "confirmed intended".
- Goldens. Expected fixtures are written from the source document plus the schema. Never adjust them to match system output.
- Report. First word
PASSorFAIL; then env, steps passed/failed, evidence paths (screenshots, traces, outputs). State whether each failure is product or harness/infra.
Rationalizations
| Excuse | Reality |
| "Localhost is up, use it" | Reachability is not a request. Use the declared default. |
| "Browser missing, so the test can't run" | Install it and run. Not a finding. |
| "Headed so they can watch" | Only if asked; never with downloads/Save As. |
| "Golden fails, update it to match" | Goldens come from source + schema, never from output. |
"That ~ looks like a bug" | Check the known-intended list first. |
| "I need env/flow details first" | Infer; note defaults in the report. |
Red Flags
- Running local because a port answered
- Reporting an install or auth failure as a product bug
- Editing a golden or spec to get green
- Secrets in output or commits
- Report not opening with PASS/FAIL
- Writing to staging/prod without asking
- Skipping the known-intended check, or not recording a confirmed one
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.