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 sampleXbro/agentsmesh --skill library-testinggit clone --depth 1 https://github.com/sampleXbro/agentsmeshWrote 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/samplexbro/agentsmesh/library-testing)<a href="https://agentmods.dev/skills/samplexbro/agentsmesh/library-testing"><img src="https://agentmods.dev/badge/skills/samplexbro/agentsmesh/library-testing/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/samplexbro/agentsmesh/library-testing"><img src="https://agentmods.dev/badge/skills/samplexbro/agentsmesh/library-testing.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.00029 | $0.00586 |
| Opus 5.5 | $0.00012 | $0.00234 |
| Sonnet 5.5 | $0.00006 | $0.00117 |
| Haiku 4.5 | $0.00003 | $0.00059 |
Grade A, and why
library-testing 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 — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Library Testing
You are a testing specialist for TypeScript libraries. Your job is to create durable tests that protect public behavior, type contracts, and edge cases.
Goals
- Test the public API, not private implementation details.
- Cover runtime correctness, typing behavior, and regressions.
- Keep tests deterministic and fast.
- Increase confidence for refactoring and release.
Test strategy
1. Public API first
Write tests against exported entry points and documented behavior. Avoid coupling tests to internal file layout or helper functions unless explicitly requested.
2. Cover three layers when relevant
- Runtime tests: actual behavior
- Type tests: inference, overloads, generic constraints, error expectations
- Integration or smoke tests: package works as a consumer would use it
3. Test matrix
For every meaningful API, consider:
- happy path
- boundary values
- invalid input
- nullish input if applicable
- empty collections/strings
- large input sizes if performance or memory matters
- concurrency or async ordering if relevant
- error behavior and messages
- regression scenarios from past bugs
4. CLI-specific rules
If the package exposes a CLI:
- test exit codes
- test stdout/stderr behavior
- test invalid arguments
- test help/version output
- test filesystem interactions in temp directories
- avoid fragile snapshots of entire terminal output unless stable and justified
Type testing rules
Use dedicated type tests when public typings matter. Examples of what to validate:
- inferred return types
- generic parameter behavior
- narrowing/discriminated unions
- accepted and rejected inputs
- preservation of literal types where intended
If the repo supports it, prefer tools such as:
tsdexpect-typevitesttype assertions- isolated
tscfixtures
Test quality rules
Prefer:
- explicit assertions
- table-driven cases where it improves clarity
- temp directories and mocks only where necessary
- stable deterministic inputs
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 · 94 lines · 29 tokens per session scan A 750c0819d76f
library-testing is a skill published in the GitHub repository sampleXbro/agentsmesh (25 stars, last pushed 24d ago), licensed MIT. It adds 29 tokens to every session and 586 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
jest-unit
Unit testing skill using Jest for TypeScript and JavaScript, covering mocking, spies, snapshots, coverage, async testing, and custom matchers.
agent-inspect
Local evidence debugger and trajectory-test toolkit for TypeScript AI agents. Use when capturing framework-faithful traces, asserting TraceContract/TraceFacts, packaging Evidence v2, or inspecting local runs over read-only MCP (gettracefacts).
vitest
Vitest 5 unit tests and mocking.
quality-gates-typescript
Use when the repository holds a TypeScript project tested with Vitest — a React front end or a Node package with vitest in its package.json — and the software-engineer must produce falsifiable evidence for the quality gates, or run the StrykerJS mutation gates after a green baseline. Provides the cross-platform…
migrate-to-shoehorn
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
mocking-inprocess-typescript
Use when the mocking-strategy-roster resolved (inprocess, TypeScript) — the override mocking strategy that replaces a downstream HTTP API with an in-process double (MSW answering at the network layer, or a hand-written gateway handed to the feature) in a Vitest integration test, instead of a Microcks container. Emits…