e2e-flow-verifier
Skill515 starsChanged 22 days agoMITView on GitHub
Use when verifying complete user flows end-to-end with the qe-browser skill (Vibium), recording session evidence, and asserting state at each step. For product verification with real browser automation.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 60
After each flow verification, vibium record produces a ZIP containing:
- Very specific: line 67
Use vibium har-export for a separate HAR 1.2 network log if needed.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
E2E Flow Verifier
Product verification skill that drives user flows with the qe-browser fleet skill (Vibium engine), asserts state at each step, and records evidence as a ZIP of screenshots + DOM snapshots.
Activation
/e2e-flow-verifier [flow-name]Dependency
This skill uses .claude/skills/qe-browser/ for all browser automation. The vibium binary is installed automatically by aqe init. See qe-browser/SKILL.md for the full command reference.
Flow Verification Pattern (qe-browser + batch + assert)
Define the flow as a JSON batch plan and drive it with the qe-browser batch runner:
# flows/{{flow-name}}.json
cat > /tmp/{{flow-name}}.json <<'EOF'
[
{"action": "go", "url": "{{base_url}}"},
{"action": "wait_load"},
{"action": "fill", "selector": "[data-testid=email]", "text": "{{test_user}}"},
{"action": "fill", "selector": "[data-testid=password]", "text": "{{test_password}}"},
{"action": "click", "selector": "[data-testid=login-btn]"},
{"action": "wait_url","pattern": "/dashboard"},
{"action": "assert", "checks": [
{"kind": "url_contains", "text": "/dashboard"},
{"kind": "selector_visible","selector": "[data-testid=dashboard]"},
{"kind": "no_console_errors"},
{"kind": "no_failed_requests"}
]},
{"action": "click", "selector": "[data-testid={{action_element}}]"},
{"action": "assert", "checks": [
{"kind": "text_visible", "text": "{{expected_text}}"}
]}
]
EOF
# Record evidence AND drive the flow
vibium record start --screenshots --snapshots --name "{{flow-name}}"
node .claude/skills/qe-browser/scripts/batch.js --steps "@/tmp/{{flow-name}}.json"
FLOW_EXIT=$?
vibium record stop -o "test-results/{{flow-name}}/evidence.zip"
exit $FLOW_EXITThe batch runner exits non-zero if any step fails, so CI gates work with a plain $? check.
Evidence Collection
After each flow verification, vibium record produces a ZIP containing:
- Screenshots — one per action + annotated failure shots
- DOM snapshots — before/after each interaction
- Timeline — ordered event log with URLs and timings
- Console/network logs — captured inline
Use vibium har-export for a separate HAR 1.2 network log if needed.
Asserting backend state alongside UI
The qe-browser assert.js check kinds include network assertions that capture backend calls made from the page:
node .claude/skills/qe-browser/scripts/assert.js --checks '[
{"kind": "response_status", "url": "/api/{{resource}}", "status": 200},
{"kind": "request_url_seen", "url": "/api/{{resource}}"}
]'For API calls that don't originate from the page, run the API check in a separate step (curl + jq, or a dedicated API test skill).
Common Flows to Verify
| Flow | Steps | Critical Assertions |
| Sign-up | Register → Verify email → Login | url_contains /dashboard, no_failed_requests |
| Purchase | Browse → Add to cart → Checkout → Pay | response_status /api/orders 201, text_visible "Thank you" |
| Profile | Login → Edit profile → Save | value_equals on the reloaded form, no_console_errors |
| Search | Enter query → Filter → Select result | element_count .result >= 1, text_visible <query> |
Reusing auth state across runs
# Once: log in and save state
vibium go "{{base_url}}/login"
vibium fill "[data-testid=email]" "$USERNAME"
vibium fill "[data-testid=password]" "$PASSWORD"
vibium click "[data-testid=login-btn]"
vibium wait url "/dashboard"
vibium storage -o test-results/auth/state.json
# Every subsequent run
vibium storage restore test-results/auth/state.json
vibium go "{{base_url}}/dashboard"Gotchas
- Re-map after DOM changes — Vibium
@e1refs are invalidated by navigation; usevibium diff mapto see what changed and re-map if needed. - Selectors break on deployment — prefer
data-testidover CSS classes. - Auth tokens expire — use fresh login per run, or rotate
storagesnapshots. - Evidence ZIPs grow — keep failure runs only in CI, gc after N days.
- No raw Playwright — this skill used to use
@playwright/test. If you need Playwright's network interception (page.route), use it in a separate skill and call it as a step; don't reintroduce the dependency here.
In this repository129 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/commands/monitoring/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- aqe-plan-qualitySkill
- aqe-plan-workSkill
- aqe-researchSkill
- aqe-review-qualitySkill
- aqe-rufloSkill
- aqe-test-changeSkill
- rufloSkill
- a11y-allySkill
- accessibility-testingSkill
- AgentDB Advanced FeaturesSkill
- AgentDB Learning PluginsSkill
- AgentDB Memory PatternsSkill
- AgentDB Performance OptimizationSkill
- AgentDB Vector SearchSkill
- agentic-quality-engineeringSkill
- api-testing-patternsSkill
- browserSkill
- brutal-honesty-reviewSkill
- bug-reporting-excellenceSkill
- chaos-engineering-resilienceSkill
- cicd-pipeline-qe-orchestratorSkill
- code-review-qualitySkill
- compatibility-testingSkill
- compliance-testingSkill
- consultancy-practicesSkill
- context-driven-testingSkill
- contract-testingSkill
- coverage-drop-investigatorSkill
- coverage-guardSkill
- database-testingSkill
- debug-loopSkill
- enterprise-integration-testingSkill
- exploratory-testing-advancedSkill
- flow-nexus-neuralSkill
- flow-nexus-platformSkill
- flow-nexus-swarmSkill
- freeze-testsSkill
- github-code-reviewSkill
- github-multi-repoSkill
- github-project-managementSkill
- github-release-managementSkill
- github-workflow-automationSkill
- holistic-testing-pactSkill
- Hooks AutomationSkill
- iterative-loopSkill
- localization-testingSkill
- middleware-testing-patternsSkill
- mobile-testingSkill
- mutation-testingSkill
- n8n-expression-testingSkill
- n8n-integration-testing-patternsSkill
- n8n-security-testingSkill
- n8n-trigger-testing-strategiesSkill
- n8n-workflow-testing-fundamentalsSkill
- no-skipSkill
- observability-testing-patternsSkill
- The first 60 shown.
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.

