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 commands/wangke19/gemini-ai-helpers/new-e2e-testgit clone --depth 1 https://github.com/wangke19/gemini-ai-helpersWrote 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/commands/wangke19/gemini-ai-helpers/new-e2e-test)<a href="https://agentmods.dev/commands/wangke19/gemini-ai-helpers/new-e2e-test"><img src="https://agentmods.dev/badge/commands/wangke19/gemini-ai-helpers/new-e2e-test.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.00014 | $0.00760 |
| Opus 5 | $0.00007 | $0.00380 |
| Sonnet 5 | $0.00003 | $0.00152 |
| Haiku 4.5 | $0.00001 | $0.00076 |
Grade A, and why
new-e2e-test 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 — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Name
openshift:new-e2e-test
Synopsis
/new-e2e-test [test-specification]
Description
The new-e2e-test command assists in writing and validating
new tests for the OpenShift test suite. It follows best practices for
Ginkgo-based testing and ensures test reliability through automated
validation.
This command handles the complete lifecycle of test development:
- Writes tests following Ginkgo patterns and OpenShift conventions
- Validates tests for reliability through multiple test runs
- Ensures proper test naming and structure
- Handles both origin repository and extension tests appropriately
Test Framework Guidelines
Ginkgo Framework
- OpenShift-tests uses Ginkgo as its testing framework
- Tests are organized in a BDD (Behavior-Driven Development) style with Describe/Context/It blocks
- All tests should follow Ginkgo patterns and conventions except
- You MUST NOT use BeforeAll, AfterAll hooks
- MUST NOT use ginkgo.Serial, instead use the [Serial] annotation in the test name if non-parallel execution is required
Repository-Specific Guidelines
Origin Repository Tests
If working in the "origin" code repository:
- All tests should go into the
test/extendeddirectory - If creating a new package, import it into
test/extended/include.go - After writing your test, MUST rebuild the openshift-tests binary using
make openshift-tests
Other repositories
Other repositories have have different conventions for locations of tests and how they get imported. Examine the code base and follow the conventions defined.
Critical Test Requirements
Test Names
CRITICAL: Test names must be stable and deterministic.
❌ NEVER Include Dynamic Information:
- Pod names (e.g., "test-pod-abc123")
- Timestamps
- Random UUIDs or generated identifiers
- Node names
- Namespace names with random suffixes
- Limits that may change later
✅ ALWAYS Use Descriptive, Static Names:
- Good example: "should create a pod with custom security context"
- Bad example: "should create pod test-pod-xyz123 with custom security context"
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 · 105 lines · 14 tokens per session scan A a105989084b3
new-e2e-test is a command published in the GitHub repository wangke19/gemini-ai-helpers (2 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 14 tokens to every session and 760 once invoked, about $0.0001 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-09-03.
Other commands, from other repositories
test-ephemeral
Deploy and test a merge request in ephemeral environment.
bmad-qa-generate-e2e-tests
Generate automated API and end-to-end tests for implemented features. Use when the user says "create qa automated tests for [feature]".
test
Write tests before implementation using Red-Green-Refactor.
sync-validate
Validate Claude MCP schema and target capability compatibility before syncing.
a
Quick alias for /analyze.
bmad-agent-pm
Product manager for PRD creation and requirements discovery. Use when the user asks to talk to John or requests the product manager.