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 skills add panbanda/omen --skill target-testsgit clone --depth 1 https://github.com/panbanda/omenWrote 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/panbanda/omen/target-tests)<a href="https://agentmods.dev/skills/panbanda/omen/target-tests"><img src="https://agentmods.dev/badge/skills/panbanda/omen/target-tests/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/panbanda/omen/target-tests"><img src="https://agentmods.dev/badge/skills/panbanda/omen/target-tests.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00031 | $0.00940 |
| Opus 5.5 | $0.00012 | $0.00376 |
| Sonnet 5.5 | $0.00006 | $0.00188 |
| Haiku 4.5 | $0.00003 | $0.00094 |
Grade A, and why
target-tests 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 1mo 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 — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Target Tests
Identify the highest-value targets for additional test coverage by combining risk, complexity, and behavioral signals.
Prerequisites
Omen CLI must be installed and available in PATH.
Workflow
Step 1: Identify High-Risk Files
Run the defect prediction analysis:
omen -f json defect
Files with high defect probability are statistically likely to contain bugs.
Step 2: Find Hotspots
Run the hotspot analysis:
omen -f json hotspot
High-churn + high-complexity code needs regression protection.
Step 3: Analyze Complexity
Run the complexity analysis:
omen -f json complexity
Complex functions have many code paths that need coverage.
Step 4: Check Ownership
Run the ownership analysis:
omen -f json ownership
Single-owner code needs tests as documentation for when others maintain it.
Test Priority Matrix
Prioritize based on combined signals:
| Priority | Signals | Why Test |
|---|---|---|
| Critical | High risk + High complexity + High churn | Bugs likely, changes often, hard to verify |
| High | High complexity + Single owner | Many paths, tests = documentation |
| Medium | High churn + Moderate complexity | Changes often, needs regression protection |
| Lower | Low complexity + Low churn | Stable, simple code |
Test Case Estimation
Use cyclomatic complexity to estimate test cases needed:
| Cyclomatic Complexity | Minimum Test Cases |
|---|---|
| 1-5 | 2-5 tests |
| 6-10 | 6-15 tests |
| 11-20 | 16-40 tests |
| 21+ | Consider refactoring first |
Output Format
Generate a test targeting report:
# Test Targeting Report
## Critical Coverage Gaps
### `src/payment/processor.go:processPayment`
- **Defect probability**: 0.82
- **Cyclomatic complexity**: 18
- **Current coverage**: Unknown/Low
- **Estimated tests needed**: 25-35 test cases
- **Why**: High-risk financial logic, frequently modified
### `src/auth/validator.go:validateToken`
- **Defect probability**: 0.75
- **Cyclomatic complexity**: 12
- **Bus factor**: 1 (alice)
- **Estimated tests needed**: 15-20 test cases
- **Why**: Security-critical, single owner, needs documentation
## High-Churn Files (Regression Priority)
| File | Churn (30d) | Complexity | Priority |
|------|-------------|------------|----------|
| api/handlers.go | 45 changes | 24 | High |
| core/engine.go | 32 changes | 31 | High |
| utils/helpers.go | 28 changes | 8 | Medium |
## Knowledge Silo Files
Files where tests serve as critical documentation:
1. `legacy/importer.go` - Only bob has touched this
- Add characterization tests before bob leaves
- Focus on capturing current behavior
2. `integration/sync.go` - Single contributor, complex
- Tests document the sync protocol
- Critical for future maintainers
## Testing Strategy by Area
### Unit Tests Needed
- `processor.go` - All code paths in processPayment
- `validator.go` - All validation rules
- Edge cases in complex conditionals
### Integration Tests Needed
- `api/handlers.go` - Request/response flows
- `storage/repository.go` - Database interactions
### Characterization Tests Needed
- `legacy/` - Capture current behavior before refactoring
## Suggested Order
1. **Week 1**: Critical coverage gaps (highest risk reduction)
2. **Week 2**: High-churn regression tests
3. **Week 3**: Knowledge silo characterization tests
4. **Ongoing**: Maintain coverage on new code
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.
- 1mo ago First seen · 151 lines · 31 tokens per session scan A ad0fc858f0ca
target-tests is a skill published in the GitHub repository panbanda/omen (20 stars, last pushed today), licensed Apache-2.0. It adds 31 tokens to every session and 940 once invoked, about $0.0001 per session on Opus 5.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 skills, from other repositories
live-preview
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.
vibe-verify
Exercise a running product against acceptance criteria and report evidence. Build success alone does not verify behavior.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
flutter-mcp-toolkit-control
Drive a running Flutter app — tap, scroll, type, fill forms, hot-reload, navigate. Use when you need to interact with the UI.
memstack-development-webapp-testing
Use when the user says 'write browser tests', 'test this page', 'playwright test', 'e2e test', 'end to end test', 'browser test', 'test the UI', or needs Playwright-based browser testing for a web application. Do NOT use for unit tests, API tests, or non-browser testing.
flutter-mcp-e2e-harness
Use this skill when writing or running repeatable E2E scenarios for Flutter apps as checked-in Dart with the fluttermcpharness package (packages/harness) — build/launch the app, attach to its VM service, drive widgets (snapshot/tap/enter text) and assert without MCP; also covers the repo showcase launcher (make…