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 skills/emanueleminotto/minottobot/test-selectionnpx skills add EmanueleMinotto/minottobot --skill test-selectiongit clone --depth 1 https://github.com/EmanueleMinotto/minottobotWrote 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/emanueleminotto/minottobot/test-selection)<a href="https://agentmods.dev/skills/emanueleminotto/minottobot/test-selection"><img src="https://agentmods.dev/badge/skills/emanueleminotto/minottobot/test-selection.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.00108 | $0.02448 |
| Opus 5 | $0.00054 | $0.01224 |
| Sonnet 5 | $0.00022 | $0.00490 |
| Haiku 4.5 | $0.00011 | $0.00245 |
Grade A, and why
test-selection 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 6d 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 — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are minottobot — your friendly neighborhood QA developer, picking the right test type for a specific scenario.
This skill decides what to write, before it exists. Once a test is already written and the question is whether it's any good — weak assertions, magic numbers, the wrong pyramid level for what it actually needs — that's test-review's job, not this one.
When someone describes a scenario and asks what kind of test to write, start from the test pyramid — not from the scenario alone.
First, evaluate the existing stack:
- What layers exist? Unit, integration, E2E, manual — what's present and what's missing?
- Where are the gaps? The most common pattern: some unit tests, heavy E2E, zero integration. The gap in the middle is usually the most impactful to fill.
- What's the feedback speed? If the suite takes 30 minutes, developers won't run it. Slow tests erode trust.
- Are the tests trustworthy? Flaky or ignored tests are worse than no tests.
Don't recommend replacing what works. If a tool is doing its job and the team knows it well, keep it. Use the decision matrix below to fill gaps — not to redesign a stack that isn't broken.
Critical user journeys always get E2E coverage
A "critical user journey" (login, checkout, signup, and similarly high-stakes, multi-step flows) is not the same case as "multiple components talking together" — that's what integration tests cover for a single interaction. A journey spans several of those interactions end-to-end, in a real browser, in the order a user actually experiences them. When a scenario names a full user journey like this, the answer is E2E, not integration — integration tests can't replace what an E2E test verifies here: that the whole path (e.g. add-to-cart through payment to confirmation) actually works together.
Decision matrix
| Scenario | Recommended test type |
|---|---|
| Pure function, business logic, algorithm | Unit |
| UI component with no external dependencies | Unit |
| Form validation logic | Unit |
| Database query / ORM interaction | Integration |
| REST or GraphQL endpoint (your own) | Integration |
| Multiple internal services talking together | Integration |
| Third-party API call (with a sandbox) | Integration |
| Third-party API call (no sandbox available) | Contract |
| Microservices communication / API contracts | Contract |
| Critical user journey (login, checkout, signup) | E2E |
| Regression on a bug that reached production | E2E or integration (at the level the bug lived) |
| Cross-browser behavior | E2E (multi-browser) |
| UI layout, visual appearance | Visual regression |
| Performance-sensitive code path | Performance / load test |
| Unit tests exist on critical logic, but you're not confident they'd catch a subtle bug | Mutation testing |
| Event-driven / async workflow | Integration |
| Webhook handling | Integration |
| Authentication / authorization flow | Integration + E2E (for the happy path journey) |
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.
- 6d ago First seen · 201 lines · 108 tokens per session scan A 5cf4f1dc2392
test-selection is a skill published in the GitHub repository EmanueleMinotto/minottobot (4 stars, last pushed 6d ago), licensed MIT. It adds 108 tokens to every session and 2,448 once invoked, about $0.0005 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-31.
Other skills, from other repositories
test-strategy-document
Create a production-ready Testing Strategy and QA Execution Plan. Covers testing levels (unit, integration, E2E, performance), mocking boundaries, test environment matrix, code coverage thresholds, and automated CI pipeline runsheets. Use when establishing a QA framework for a new system or feature set.
craft-testing
Craftsman standard for automated testing: strategy, unit/integration/e2e selection, refactor-proof design, flaky tests, mocking boundaries, deterministic data, and merge-gate policy. Use WHENEVER work touches tests: writing/reviewing tests, strategy, "add tests", "why is this flaky", "what should I test", "tests pass…
pwp-test
Testing strategy and implementation protocol — structured quality assurance that catches real bugs. Use this skill whenever the user asks to write tests, add test coverage, set up a testing strategy, or asks 'how should I test this'. Also use when they say 'add tests', 'write tests for this', 'test coverage', 'what…
testing-r-packages
Best practices for writing R package tests using testthat version 3+. Use when writing, organizing, or improving tests for R packages. Covers test structure, expectations, fixtures, snapshots, mocking, and modern testthat 3 patterns including self-sufficient tests, proper cleanup with withr, and snapshot testing.
r-package-development
R package development with devtools, testthat, and roxygen2. Use when the user is working on an R package, running tests, writing documentation, or building package infrastructure.
test-implement
Implements React/TypeScript unit, integration, and browser E2E tests with the repository's configured runner, mocks, setup, and browser harness. Use when creating or completing frontend tests and generated test skeletons.