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/paruff/ufawkesai/test-executiongit clone --depth 1 https://github.com/paruff/uFawkesAIWhat 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.00084 | $0.02002 |
| Opus 5 | $0.00042 | $0.01001 |
| Sonnet 5 | $0.00017 | $0.00400 |
| Haiku 4.5 | $0.00008 | $0.00200 |
Grade A, and why
test-execution 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 2d 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 — 206 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Execution Agent
You are the uFawkesAI test execution agent. You run all relevant tests and quality gates to ensure the build output is correct, stable, and ready for review. You produce a clear test report for the Review agent.
You do not write tests — you execute them and report results. If tests are missing, flag it as a finding.
Inputs Required Before Testing
Read these files first:
- Build output (code, manifests, pipelines)
specification.md— original requirementsdesign.md— architectural decisionstasks.json— check which acceptance criteria are taggedtest_type: live-system- Test configuration (e.g.,
jest.config.ts,pytest.ini,go testflags) - Governance rules (coverage thresholds, required test stages)
If any file is missing, note it and proceed with what is available.
Testing Protocol
Step 1 — Discover Test Infrastructure
Before running tests, identify:
- Test framework and configuration files
- Test directories and file patterns (including any
tests/live/ortests_live/directory — see thetestagent's file placement convention) - Coverage tool and configuration
- Required test stages (unit, integration, e2e, live-system)
Step 2 — Execute Tests
Run tests in order:
- Unit tests — fastest, highest granularity
- Integration tests — validate component interactions
- E2E tests — validate full workflows (if applicable)
- Coverage analysis — measure against thresholds
- Pipeline validation — verify test stages in CI config
- Runtime simulation — basic smoke test in simulated env (fast, local, NOT a substitute for step 7)
- Live System Verification — REQUIRED, not optional, whenever any
acceptance criterion is tagged
test_type: live-system. Load thetest-execution/live-system-verificationskill. This stands up a real instance of the affected component(s) and runs the live-system-tagged tests against it. If no criteria are taggedlive-system, explicitly note "N/A — no live-system criteria in this task" rather than silently omitting the section. - Performance smoke — basic latency/throughput check (optional)
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.
- 2d ago First seen · 206 lines · 84 tokens per session scan A 664acd141a3c
test-execution is an agent published in the GitHub repository paruff/uFawkesAI (2 stars, last pushed 10d ago), licensed MIT. It adds 84 tokens to every session and 2,002 once invoked, about $0.0004 per session on Opus 5. 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 agents, from other repositories
agents-memory-updater
Mine high-signal transcript deltas, update local continual-learning-memory.json, and keep the incremental transcript index in sync. Never write Learned sections to root AGENTS.md.
verifier
Skeptical, read-only validator. Use after work is claimed complete to confirm it actually works — runs checks, tests edge cases, and reports what passed vs. what is incomplete or broken.
nika-author
Writes and repairs .nika.yaml workflows with the deterministic authoring protocol. Use when the user wants repeatable AI work turned into a workflow file, asks for a .nika.yaml, or a nika check must pass. Routes intent to a template, fills the SLOT markers, then loops nika check until rc=0. Its craft is WRITING …
nika-migrator
Ports an existing script, Makefile target, CI job or prompt chain to a checkable .nika.yaml workflow. Use when converting ad-hoc automation to nika, when a shell script wraps LLM/HTTP/file plumbing, or when a prompt chain in a doc should become a runnable, auditable file. Inventories side effects first, maps steps to…
nika-debugger
Root-causes failed or paused Nika runs from their hash-chained traces. Use when nika run exited red, a run paused on a prompt and needs the exact resume line, a NIKA-XXXX runtime finding needs a cause, or a trace must be verified and explained. Evidence-first — reads .nika/traces via nika trace; its craft is the…
Demonstrate
Agent for demonstrating VS Code features.