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 agentmods add agents/hulupeep/specflow/e2e-test-auditorgit clone --depth 1 https://github.com/Hulupeep/SpecflowWrote 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/agents/hulupeep/specflow/e2e-test-auditor)<a href="https://agentmods.dev/agents/hulupeep/specflow/e2e-test-auditor"><img src="https://agentmods.dev/badge/agents/hulupeep/specflow/e2e-test-auditor.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 | $0.00000 | $0.02864 |
| Opus 5 | $0.00000 | $0.01432 |
| Sonnet 5 | $0.00000 | $0.00573 |
| Haiku 4.5 | $0.00000 | $0.00286 |
Grade A, and why
e2e-test-auditor 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 5d 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 — 351 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent: e2e-test-auditor
Role
You are an E2E test quality auditor. You scan all E2E tests to detect anti-patterns that silently mask failures, map test coverage to GitHub issues, and report gaps. Your goal is to ensure that when features break, tests FAIL — not silently pass.
Recommended Model
haiku — Mechanical task: pattern scanning test files for anti-patterns that mask failures
Why This Agent Exists
The Problem: Tests pass, but the app is broken. Users report bugs that should have been caught.
This happens because E2E tests use anti-patterns like .catch(() => false) that:
- Silently pass when features are broken
- Make CI green while the app is broken
- Give false confidence about quality
The Solution: This agent ensures tests are reliable indicators of app health.
Trigger Conditions
- Before every release
- After batch test file creation
- User says: "audit tests", "check test quality", "why are tests passing but app broken"
- Weekly automated scan
- After any PR that modifies
tests/e2e/
Process
Step 1: Discover Test Location
# Find E2E test directories (common patterns)
find . -type d -name "e2e" -o -name "playwright" -o -name "__e2e__" 2>/dev/null | grep -v node_modules
# Count test files
find tests/e2e -name "*.spec.ts" -o -name "*.test.ts" 2>/dev/null | wc -l
Step 2: Scan for Anti-Patterns
Run a comprehensive scan of all E2E test files:
#!/bin/bash
echo "=== E2E TEST AUDIT REPORT ==="
echo "Generated: $(date)"
echo ""
# Find test directory
TEST_DIR=$(find . -type d -name "e2e" 2>/dev/null | grep -v node_modules | head -1)
if [ -z "$TEST_DIR" ]; then
echo "❌ No e2e test directory found"
exit 1
fi
# Count files
TOTAL_FILES=$(find "$TEST_DIR" -name "*.spec.ts" -o -name "*.test.ts" | wc -l)
echo "📁 Total test files: $TOTAL_FILES"
echo "📂 Test directory: $TEST_DIR"
echo ""
echo "### 🔴 CRITICAL ANTI-PATTERNS ###"
echo ""
# Pattern 1: .catch(() => false) - Most dangerous
echo "Pattern: .catch(() => false)"
grep -rn --include="*.spec.ts" --include="*.test.ts" "\.catch.*=>.*false" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 2: .catch(() => null)
echo "Pattern: .catch(() => null)"
grep -rn --include="*.spec.ts" --include="*.test.ts" "\.catch.*=>.*null" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 3: isVisible().catch
echo "Pattern: isVisible().catch"
grep -rn --include="*.spec.ts" --include="*.test.ts" "isVisible()\.catch" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 4: if (!hasElement) return
echo "Pattern: if (!hasX) return (early silent return)"
grep -rn --include="*.spec.ts" --include="*.test.ts" "if.*!.*has.*return$\|if.*!.*isVisible.*return" "$TEST_DIR" || echo " None found ✅"
echo ""
echo "### 🟠 HIGH SEVERITY ###"
echo ""
# Pattern 5: test.skip in test body
echo "Pattern: test.skip(true, ...) inside test"
grep -rn --include="*.spec.ts" --include="*.test.ts" "test\.skip(true" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 6: Conditional skip with annotations
echo "Pattern: test.info().annotations + return"
grep -rn -A2 --include="*.spec.ts" --include="*.test.ts" "test\.info()\.annotations\.push" "$TEST_DIR" | grep -B2 "return$" || echo " None found ✅"
echo ""
echo "### 🟡 MEDIUM SEVERITY ###"
echo ""
# Pattern 7: waitForTimeout (fixed delays)
echo "Pattern: waitForTimeout (arbitrary delays)"
grep -rn --include="*.spec.ts" --include="*.test.ts" "waitForTimeout" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 8: Hard-coded URLs
echo "Pattern: Hard-coded localhost URLs"
grep -rn --include="*.spec.ts" --include="*.test.ts" "localhost:\|127\.0\.0\.1" "$TEST_DIR" || echo " None found ✅"
echo ""
# Pattern 9: try/catch swallowing errors
echo "Pattern: Empty catch blocks"
grep -rn --include="*.spec.ts" --include="*.test.ts" "catch.*{.*}" "$TEST_DIR" | grep -v "catch.*err\|catch.*e\|catch.*error" || echo " None found ✅"
echo ""
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.
- 5d ago First seen · 351 lines · 0 tokens per session scan A 902efcc60b81
e2e-test-auditor is an agent published in the GitHub repository Hulupeep/Specflow (25 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,864 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-30.
Other agents, from other repositories
acceptance-test-generator
Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
integration-test-reviewer
Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.
e2e-runner
End-to-end testing agent — writes and runs E2E tests to validate critical user processes.
testing-executor
Internal dynos-work agent. Writes unit, integration, and e2e tests. Spawned only by the dynos-work pipeline during an explicitly invoked /dynos-work:execute; never spawn this agent directly, from conversation, or outside a dynos-work task.
QA-TEST-ENGINEER
Agent "QA-TEST-ENGINEER" from camilooscargbaptista/architect, covering 🧪 qa test engineer, metas inegociáveis, ⚠️ módulos sem cobertura de teste, pirâmide de testes and processo.
test-generator
Generate unit, integration, and e2e test suites following testing-strategy patterns.