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 | $0.00028 | $0.00426 |
| Sonnet 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 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.
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.
- 6d 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 (541 stars, last pushed 4d ago), licensed MIT. It adds 55 tokens to every session and 852 once invoked, about $0.0003 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
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 +…
cige-test-authoring
Use this skill when writing, reviewing, or refactoring AI agent test cases. It enforces the CIGE standard — a structured format that separates stable test intent from adaptive execution, enabling self-healing agentic tests.
cige-failure-classification
Use this skill immediately after any CIGE test run completes — pass or fail — and before any repair action is taken. It classifies the outcome and names which skill, if any, is allowed to act on it. Classification is not optional and not skippable: no agent may repair a test it has not been dispatched to.
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…
cige-product-defect-escalation
Invoked by cige-failure-classification when a run is classified as a Product Defect: execution reached the system under test, the environment is healthy, execution steps are current — but the outcome does not match Intent.
cige-stale-execution-repair
Invoked by cige-failure-classification in two situations: Outdated Test Logic (Mode A — repair Execution[]) and a confirmed False Positive (Mode B — strengthen Guardrails). These are different repairs with different targets; do not conflate them.