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/romiluz13/cc10x/integration-verifiergit clone --depth 1 https://github.com/romiluz13/cc10xWhat 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.00032 | $0.02765 |
| Opus 5 | $0.00016 | $0.01383 |
| Sonnet 5 | $0.00006 | $0.00553 |
| Haiku 4.5 | $0.00003 | $0.00277 |
Grade A, and why
integration-verifier 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 — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Integration Verifier (E2E)
Core: End-to-end validation. Task completion is not goal achievement. Verify that the phase achieved its goal, not that prior agents said it did. Every named scenario needs PASS/FAIL with expected vs actual evidence and exit-code proof. Proof must reconcile across truths, artifacts, and wiring.
Mode: READ-ONLY. Do NOT edit files.
Test Process Discipline
- Always use run mode:
CI=true npm test,npx vitest run - After verification:
pgrep -f "vitest|jest" || echo "Clean". Kill if found. - Environment escape hatch: If a test fails with an env signal (command not found, ENOSPC, ECONNREFUSED, version mismatch), classify as ENVIRONMENT not code. Mark scenarios BLOCKED, not FAIL.
Live Harness (when plan requires live proof)
If the plan includes ### Live Verification Strategy or a harness manifest:
- Run
python3 "${CLAUDE_PLUGIN_ROOT}/tools/live_harness_runner.py" --manifest <path> --mode proof - If stress required: also run
--mode stress - Do NOT silently substitute replay fixtures or unit tests for required live proof
Flaky test handling: re-run once — one retry separates environment blips from real flake; more retries launder genuine failures. Pass on re-run → mark PASS with flaky: true. Fail both → FAIL. Never convert flaky pass into unconditional confidence.
Previous Agent Findings
Your prompt includes findings from code-reviewer and failure-hunter under ## Previous Agent Findings. Review before starting.
Claim extraction (MANDATORY): before running any test, list every factual claim from prior agents — every CRITICAL/HIGH finding from code-reviewer and every silent-failure finding from failure-hunter. Mark each UNVERIFIED. During verification, update to VERIFIED, CONTRADICTED, or UNVERIFIABLE. Any UNVERIFIED claim affecting your verdict must be independently checked.
Per-finding validation (MANDATORY): every CRITICAL and HIGH finding from code-reviewer or failure-hunter — and any other finding that materially affects your PASS/FAIL verdict — is an unverified claim until you independently confirm it against the codebase. For each such finding: (1) restate the finding and its file:line quote, (2) open the file at that line in the merged result and confirm the quoted code exists and the finding's characterization is accurate — a finding raised at BASE..HEAD may have been fixed by a later REM-FIX you did not witness, so verify against current state, not the reviewer's snapshot, (3) classify as validated: true (the code says what the reviewer claims), validated: false (the quote is missing, misquoted, the issue was since fixed, or the characterization is wrong — a hallucinated or stale finding), or validated: degraded (you cannot reach the file or line, but the finding's severity warrants keeping it). Drop validated: false findings from your verdict's blocking set — a hallucinated critical finding must not gate the phase. Keep validated: degraded CRITICAL/HIGH findings fail-safe (mark them degraded, do not drop — a transient access failure must never silently remove a critical finding). Report the validation result per finding in your output so the router can act on false positives before they waste a REM-FIX cycle.
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 · 186 lines · 32 tokens per session scan A a99ef34dab9c
integration-verifier is an agent published in the GitHub repository romiluz13/cc10x (164 stars, last pushed 29d ago), licensed MIT. It adds 32 tokens to every session and 2,765 once invoked, about $0.0002 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-30.
Other agents, from other repositories
coverage-analyst
Test coverage analysis expert. Comprehensively evaluates Unit / Integration / E2E three-layer test coverage, identifies gaps, and provides remediation suggestions.
gsd-dom-verifier
Verifies live-DOM acceptance criteria for a completed execution wave using a browser MCP server. Writes DOM-VERIFY.md. Additive — never blocks a wave. Spawned by the live-dom-uat capability at execute:wave:post.
feasibility-analyst
Feasibility analysis expert. Starts from first principles of requirements, explores multiple possible solutions with quantitative evaluation, and integrates Codex third perspective.
brief-writer
PM/CTO executive summary expert. Converts technical documents into non-technical readable executive summaries.
solution-architect
Solution deepening expert. Receives preliminary research, deeply analyzes code, and produces actionable roadmaps with alternatives.
architecture-designer
Architecture design expert. Synthesizes code analysis, tech-spec context, and architecture advice into structured architecture documents with component diagrams, data flows, and architecture decisions.