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/cosmix/loom/loom-testingnpx skills add cosmix/loom --skill loom-testinggit clone --depth 1 https://github.com/cosmix/loomWrote 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/cosmix/loom/loom-testing)<a href="https://agentmods.dev/skills/cosmix/loom/loom-testing"><img src="https://agentmods.dev/badge/skills/cosmix/loom/loom-testing.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.00025 | $0.02747 |
| Opus 5 | $0.00013 | $0.01373 |
| Sonnet 5 | $0.00005 | $0.00549 |
| Haiku 4.5 | $0.00003 | $0.00275 |
Grade A, and why
loom-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 yesterday.
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 — 236 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing
Overview
Writing tests: unit/integration/e2e plus data-pipeline, ML, and infrastructure domains. This file owns test-double taxonomy, AAA, and framework patterns. For pyramid ratios, coverage targets, risk prioritization, and flaky-test diagnosis, see loom-test-strategy; for browser/Playwright/Cypress, see loom-e2e-testing.
Workflow
- Map the unit — public interface, dependencies/side effects, invariants, error paths, boundary values.
- Pick the altitude — unit for logic/branches; integration for real collaborators (DB, HTTP) at a boundary; e2e for user journeys. Push detail down the pyramid (
loom-test-strategy). - Write failing test first when practical (TDD red→green→refactor): a red test proves the test actually exercises the code; a test that never failed asserts nothing.
- Arrange-Act-Assert, one logical assertion per test, deterministic inputs.
AAA and naming
- Arrange state/doubles → Act (one call to the unit) → Assert outcome. Blank-line separate the three; more than one Act means split the test.
- Name
test_<unit>_<scenario>_<expected>— e.g.test_cart_add_duplicate_increases_quantity. The name is the spec; a failing name should tell you what broke without reading the body. - One logical assert per test. Multiple physical asserts on one behavior are fine (
status, thenbody); asserting two unrelated behaviors is "assertion roulette" — the first failure masks the rest. Prefer one composite assert (assert_eq!(got, expected_struct)) over many field asserts.
Test Doubles — taxonomy and misuse
Precision matters: "mock" is colloquially any double, but the kind you choose decides whether the test is brittle.
| Double | Does | Verifies | Reach for when |
|---|---|---|---|
| Dummy | Fills a parameter, never used | nothing | Satisfy a signature |
| Stub | Returns canned values for indirect inputs | state (result) | Drive a branch from a dependency's return |
| Spy | Stub that records how it was called | state + calls, after | Assert an effect happened, loosely |
| Mock | Pre-set call expectations, self-verifying | interaction, strict | The interaction is the contract (e.g. "charge called once with amount") |
| Fake | Lightweight working impl (in-memory DB, fake clock) | state | Collaborator too slow/awkward for real, but behavior matters |
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.
- yesterday First seen · 236 lines · 25 tokens per session scan A 84efd8785021
loom-testing is a skill published in the GitHub repository cosmix/loom (54 stars, last pushed yesterday), licensed MIT. It adds 25 tokens to every session and 2,747 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-09-03.
Other skills, from other repositories
continuous-testing
Continuous test-driven development loop — after every code change, builds the project, starts the server, and runs Unit Tests, Integration Tests, and System Tests. Applies on top of microprofile-server skill. Use during development when you want full verification after each change. Triggers on "continuous testing"…
testing-setup
Analyze and create a testing strategy for native Android apps - install testing libraries, set up test infrastructure, create harnesses for unit tests, UI tests, screenshot tests, and end-to-end tests.
moai-ref-testing-pyramid
Test pyramid strategy, coverage targets, test patterns, and quality metrics reference. Agent-extending skill that amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns. NOT for: production code implementation, architecture design, DevOps, security audits.
testing-strategies
Comprehensive testing strategy covering unit, integration, e2e, property-based, and mutation testing with practical patterns.
frontend-testing
Comprehensive frontend testing strategy covering unit, integration, E2E, visual regression, and accessibility testing.
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.