Borrowing it
Nothing to install: this file belongs to RedHatInsights/nxtcm-components. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/RedHatInsights/nxtcm-components/main/.agents/skills/verify-test-infrastructure/SKILL.mdgit clone --depth 1 https://github.com/RedHatInsights/nxtcm-componentsWrote 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/skills/redhatinsights/nxtcm-components/verify-test-infrastructure)<a href="https://agentmods.dev/skills/redhatinsights/nxtcm-components/verify-test-infrastructure"><img src="https://agentmods.dev/badge/skills/redhatinsights/nxtcm-components/verify-test-infrastructure.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.1 | $0.00015 | $0.02358 |
| Opus 5 | $0.00008 | $0.01179 |
| Sonnet 5 | $0.00003 | $0.00472 |
| Haiku 4.5 | $0.00002 | $0.00236 |
Grade C, and why
verify-test-infrastructure scanned grade C with 1 finding 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 7d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf playwright/.cache && \ How it starts
The opening of the file, as written. The whole thing — 304 lines — stays where its author put it; the contents beside it link to each section on GitHub.
verify-test-infrastructure
Quickly verify all test suites and coverage collection infrastructure are working correctly. Use this after:
- Dependency upgrades (Vite, Playwright, Istanbul, etc.)
- Rebases that change test structure or configuration
- Modifications to test configs (playwright-ct.config.ts, playwright.config.ts, jest.config.js)
- Cache issues or build problems
- Adding/removing test infrastructure
This skill verifies the test pipeline infrastructure, not test content. For verifying individual test results, use /verify-tests.
What This Skill Checks
-
CT Infrastructure (Component Tests)
- CT tests run without coverage
- Istanbul plugin loads and instruments code
- Coverage data is collected to
.nyc_output - Playwright cache (
playwright/.cache) works correctly
-
E2E Infrastructure
- E2E tests run with coverage
- Coverage collection works for E2E
-
Coverage Reporting
- NYC can generate reports from collected data
- Coverage metrics are reasonable (not 0% or 100%)
-
Common Issues Detection
- Stale cache preventing instrumentation
- Missing dependencies (nyc, istanbul-lib-instrument, test-exclude)
- Plugin not loading or transform hook not firing
- Coverage env var not propagating
Verification Steps
1. Quick CT Baseline Check
Run a small subset of CT tests without coverage to verify basic test infrastructure:
rm -rf playwright/.cache && \
npx playwright test -c playwright-ct.config.ts --grep "CVECard.*should render the card with default title"
Expected: Test passes in 1-3 seconds, no errors.
Red flags:
- Test fails or times out
- Module resolution errors
- Playwright can't find tests
2. CT Coverage Instrumentation Check
Run the same test with coverage and verify Istanbul instruments code:
rm -rf playwright/.cache .nyc_output && \
COVERAGE=true npx playwright test -c playwright-ct.config.ts --grep "CVECard.*should render the card with default title"
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.
- 7d ago First seen · 304 lines · 15 tokens per session scan C 3c993afe0d0a
verify-test-infrastructure is a skill published in the GitHub repository RedHatInsights/nxtcm-components (3 stars, last pushed yesterday), licensed Apache-2.0. It adds 15 tokens to every session and 2,358 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
Verification & Quality Assurance
Comprehensive truth scoring, code quality verification, and automatic rollback system with 0.95 accuracy threshold for ensuring high-quality agent outputs and codebase reliability.
verification-strategy
Thorough verification of completed work before declaring done.
workflow-setup
Configures GitHub Actions CI/CD workflows for testing, linting, and deployment. Use when setting up automation for a Python, Rust, or TypeScript project.
paired-probe
Refuse a verdict a probe did not earn. Runs a check where the fault IS present and where it is NOT, and blocks the answer when both arms print the same thing, because a check that cannot disagree with you has measured nothing. Also catches the zero-sample sweep that reads as "clean" and the swallowed error that reads…
precommit-setup
Configures pre-commit hooks for linting, type checking, formatting, and testing. Use when setting up a new project or adding quality gates to an existing one.
wio
Testing workflow skill for finding high-value test candidates, writing focused tests, generating realistic workloads, reviewing test value, and diagnosing test-suite health. Use for prompts about what to test next, adding or improving tests, reviewing whether a test is worth keeping, low-signal or flaky tests…