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 oliver-kriska/claude-elixir-phoenix --skill testinggit clone --depth 1 https://github.com/oliver-kriska/claude-elixir-phoenixWrote 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/oliver-kriska/claude-elixir-phoenix/testing)<a href="https://agentmods.dev/skills/oliver-kriska/claude-elixir-phoenix/testing"><img src="https://agentmods.dev/badge/skills/oliver-kriska/claude-elixir-phoenix/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/oliver-kriska/claude-elixir-phoenix/testing"><img src="https://agentmods.dev/badge/skills/oliver-kriska/claude-elixir-phoenix/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.00055 | $0.00852 |
| Opus 5.5 | $0.00022 | $0.00341 |
| Sonnet 5.5 | $0.00011 | $0.00170 |
| Haiku 4.5 | $0.00006 | $0.00085 |
Grade A, and why
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- elixir-phoenix-testing — 86% identical, 22 lines differ
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.
Elixir Testing Reference
Ash projects: Use
DataCasewithAsh.Testhelpers; test actions via domain code interfaces, not directRepocalls. Seeash-frameworkskill.
Quick reference for Elixir testing patterns.
Iron Laws — Never Violate These
- ASYNC BY DEFAULT — Use
async: trueunless tests modify global state - SANDBOX ISOLATION — All database tests use Ecto.Adapters.SQL.Sandbox
- MOCK ONLY AT BOUNDARIES — Never mock database, internal modules, or stdlib
- BEHAVIOURS AS CONTRACTS — All mocks must implement a defined
@callbackbehaviour - BUILD BY DEFAULT — Use
build/2in factories;insert/2only when DB needed - NO PROCESS.SLEEP — Use
assert_receivewith timeout for async operations - VERIFY_ON_EXIT! — Always call in Mox tests setup
- FACTORIES MATCH SCHEMA REQUIRED FIELDS — Factory definitions must include all fields that have
validate_requiredin the schema changeset. Missing fields cause cascading test failures
Quick Decisions
Which Test Case?
| Testing | Use |
|---|---|
| Controller/API | use MyAppWeb.ConnCase |
| Context/Schema | use MyApp.DataCase |
| LiveView | use MyAppWeb.ConnCase + import Phoenix.LiveViewTest |
| Pure logic | use ExUnit.Case, async: true |
When to use async: true?
- ✅ Pure functions, no shared state
- ✅ Database tests with Sandbox (PostgreSQL)
- ❌ Tests modifying
Application.put_env - ❌ Tests using Mox global mode
Mock or not?
- ✅ Mock: External APIs, email services, file storage
- ❌ Don't mock: Database, internal modules, stdlib
build() or insert()?
- Use
build()by default for speed - Use
insert()only when you need DB ID, constraints, or persisted associations
Quick Patterns
# Setup chain
setup [:create_user, :authenticate]
# Pattern matching assertion
assert {:ok, %User{name: name}} = create_user(attrs)
# Async message assertion
assert_receive {:user_created, _}, 5000
# Mox setup
setup :verify_on_exit!
expect(MockAPI, :call, fn _ -> {:ok, "data"} end)
# LiveView async
html = render_async(view) # MUST call for assign_async
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 55 tokens per session scan A 787a70641699
testing is a skill published in the GitHub repository oliver-kriska/claude-elixir-phoenix (569 stars, last pushed 2d ago), licensed MIT. It adds 55 tokens to every session and 852 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
craft-pest
Testing Craft CMS 5 plugins and modules with Pest — test isolation, database safety, and the markhuot/craft-pest-core harness. ALWAYS load when writing, running, fixing, or reviewing tests for a Craft plugin or module, and whenever a suite touches a real Craft install. Covers why rollback is opt-in, tests/Pest.php +…
feature-dev
Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an…
test-driven-development
Strict red-green-refactor TDD workflow for implementing features, fixing bugs, or changing behavior in Rails applications. Enforces the discipline of writing a failing test before any production code. Use whenever you want to implement with TDD — whether a new feature, a bugfix, a refactor, or any behavior change.
solution-validation-testing
When the user wants to verify optimization code: independent feasibility checkers, objective recomputation separate from the solver, unit tests for constraint builders and operators, known-optimum regression tests, and exact-vs-heuristic cross-validation on small instances. Also use when the user mentions "validate…
test-engineer
QA and testing agent that writes unit tests, integration tests, and edge case coverage for the codebase. Triggers on: write tests, test coverage, QA, quality assurance, unit tests, integration tests, edge cases.
odoo-test-runner
Skill "odoo-test-runner" from omas-odoo/odoo-superpowers, covering odoo test runner, running — make the run credible, fresh db, or don't trust the green, prove the ticket, not the checkbox and the new behavior earns a new test.