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 livekit/agent-skills --skill testing-livekit-agentsgit clone --depth 1 https://github.com/livekit/agent-skillsWrote 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/livekit/agent-skills/testing-livekit-agents)<a href="https://agentmods.dev/skills/livekit/agent-skills/testing-livekit-agents"><img src="https://agentmods.dev/badge/skills/livekit/agent-skills/testing-livekit-agents/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/livekit/agent-skills/testing-livekit-agents"><img src="https://agentmods.dev/badge/skills/livekit/agent-skills/testing-livekit-agents.svg" alt="Reviewed on agentmods" width="80" 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.00155 | $0.01665 |
| Opus 5.5 | $0.00062 | $0.00666 |
| Sonnet 5.5 | $0.00031 | $0.00333 |
| Haiku 4.5 | $0.00015 | $0.00167 |
Grade A, and why
testing-livekit-agents 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 22d 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.
This is a copy
100% identical to testing-livekit-agents — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 133 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing LiveKit agents
Turn-level tests are the cheapest lasting verification an agent can have. They run in the user's
existing suite, in text mode, and they're fast enough for every commit. The framework's helper
names and signatures change, so look them up with reading-livekit-docs before writing, and use
the testing docs page for every API detail this skill leaves out.
Every test has the same shape: start a test session with the agent under test, run one user turn, and assert on the events that turn produced.
What a test asserts on
A turn produces a sequence of events. A simple turn is one message. A more typical one is a tool call, its output, maybe a handoff, and then a message. You write the test by walking that sequence in order, asserting on each event, and then asserting the turn has nothing more.
There are three kinds of assertion, and most of this skill is knowing which one to use.
Structural assertions check message roles, that a tool was called, its arguments, what it returned, and that a handoff to a specific agent happened. They're deterministic and fail for exactly one reason, so prefer them.
Judged assertions use an LLM-judge helper that gives one message and an intent string to a model and asks whether they match. Use them for the content of a reply, which you can't assert exactly. Describe the intent by outcome ("tells the user the booking is confirmed and gives the time"), not by wording.
Whole-conversation assertions use a judge-group helper that runs several built-in judges concurrently over the whole chat history and aggregates their verdicts. The built-in judges cover dimensions like grounding, relevance, safety, task completion, and tool use; the docs list the current set. Use this when the question spans several turns.
Rules of thumb:
- Assert structure first and judge only what's left. A judged assertion that could have been structural is slower and flakier.
- Close the turn. Assert there are no further events. Otherwise a test can pass while the agent also does something you didn't intend.
- One behavior per test. When a test that asserts six things fails, it tells you very little.
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.
- 22d ago First seen · 133 lines · 155 tokens per session scan A 18dddabe4f14
testing-livekit-agents is a skill published in the GitHub repository livekit/agent-skills (71 stars, last pushed 7d ago), licensed MIT. It adds 155 tokens to every session and 1,665 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to testing-livekit-agents, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
test-gen
Generate and verify tests — happy path, edge cases, error paths — using the project's own framework and patterns.
r-testthat
Best practices for writing R package tests with testthat version 3+. Use this skill when writing or organizing tests for an R package or when improving existing tests that use testthat. It covers test structure and expectations, self-sufficient test design, proper cleanup with withr, fixtures, mocking external…
brooks-test
Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…
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-review
Test coverage review via Codex exec. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
precommit
Pre-commit checks — lint:fix -> build -> test.