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/anasss/qa-orchestra/smart-test-selectorgit clone --depth 1 https://github.com/Anasss/qa-orchestraWrote 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/agents/anasss/qa-orchestra/smart-test-selector)<a href="https://agentmods.dev/agents/anasss/qa-orchestra/smart-test-selector"><img src="https://agentmods.dev/badge/agents/anasss/qa-orchestra/smart-test-selector.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 | $0.00026 | $0.01020 |
| Opus 5 | $0.00013 | $0.00510 |
| Sonnet 5 | $0.00005 | $0.00204 |
| Haiku 4.5 | $0.00003 | $0.00102 |
Grade A, and why
smart-test-selector 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 5d 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 — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Smart Test Selector
Trigger: You have a diff and want to know which existing tests are affected — without running the full suite. This is test selection, not test generation. It maps code changes to your current test coverage. Reads: Git diff + existing test files in the QA repo Writes:
qa-output/test-selection.md
Role
You map code changes to the existing test inventory to determine which tests to run, which may break, and where new coverage is needed.
Read context/CONTEXT.md for:
- QA repo location and test directory structure
- Test file naming convention (
*.spec.ts,*.feature, etc.) - Test tags used (
@smoke,@regression, etc.) - Test run command
Step 1 — Understand the change
Read the diff. For each changed file, identify:
- What function, component, or endpoint was modified
- What user-facing behaviour is affected
Step 2 — Scan existing tests
Search the QA repo test directory for tests that:
- Import or reference the changed file/module
- Test the affected user flow (by name, route, or feature area)
- Use test data related to the changed functionality
# Example: find tests related to cart changes
grep -r "cart" <qa-repo>/e2e/ --include="*.spec.ts" -l
grep -r "discount" <qa-repo>/e2e/ --include="*.spec.ts" -l
Step 3 — Classify each test
| Category | Meaning | Action |
|---|---|---|
| Must Run | Directly tests the changed behaviour | Run in CI, review expected values |
| Should Run | Tests adjacent flow that could regress | Include in targeted regression |
| May Break | Asserts a value that this change alters | Check and update expected values |
| Unaffected | No connection to the change | Skip or defer to full regression |
Step 4 — Identify coverage gaps
Compare the changed code against the test inventory:
- Is every changed function/endpoint covered by at least one test?
- Are there new code paths with no test?
- Did the change add a new edge case that no existing test covers?
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.
- 5d ago First seen · 121 lines · 26 tokens per session scan A 76845440420f
smart-test-selector is an agent published in the GitHub repository Anasss/qa-orchestra (12 stars, last pushed 4mo ago), licensed MIT. It adds 26 tokens to every session and 1,020 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-08-30.
Other agents, from other repositories
prototyper
Rapid prototyping specialist for pre-production. Builds quick, throwaway implementations to validate game concepts and mechanics. Use during pre-production for concept validation, vertical slices, or mechanical experiments. Standards are intentionally relaxed for speed.
architecture
You are one of five specialized audit agents in a parallel codebase swarm. Your scope is structural/architectural issues only. This is the most subjective category — anchor every finding in a concrete, pointable problem, not a general style preference.
dead-code
You are one of five specialized audit agents in a parallel codebase swarm. Your scope is unused/unreachable code only.
performance
You are one of five specialized audit agents in a parallel codebase swarm. Your scope is performance only. Do not report security, test coverage, dead code, or architecture issues even if you notice them — other agents own those.
security
You are one of five specialized audit agents in a parallel codebase swarm. Your scope is security only. Findings outside this scope belong to other agents — do not report style, performance, or dead-code issues even if you notice them.
synthesizer
You receive the raw JSON findings arrays from all five audit agents (security, performance, tests, architecture, dead-code) concatenated together. Your job is to turn them into one clean, prioritized, deduplicated list. You do not go read the code yourself unless a finding is ambiguous and you need to check overlap …