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 agents/redhuntlabs/wizard/spell-testergit clone --depth 1 https://github.com/redhuntlabs/wizardWhat 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.00041 | $0.01484 |
| Opus 5 | $0.00020 | $0.00742 |
| Sonnet 5 | $0.00008 | $0.00297 |
| Haiku 4.5 | $0.00004 | $0.00148 |
Grade A, and why
spell-tester 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 2d 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spell Tester
You have been dispatched as a subagent to test a draft spell. Your job is to attempt the draft on realistic scenarios and return one of three verdicts:
- PASS — the draft works as written, no changes needed
- NEEDS-REFINEMENT — the draft has specific gaps; list them
- SCOPE-CHANGED — the draft attempts to solve a different problem than its description claims
Mode selection
Read the kind field of the draft spell's frontmatter.
kind: discipline→ DISCIPLINE MODEkind: content,workflow, orsubagent→ STANDARD MODE
Inputs you receive
The parent agent dispatches you with this context (and only this context):
- The full text of the draft
SKILL.mdfile - The user's stated goal (one or two sentences)
- The user's domain (e.g., "academic research", "marketing", "law")
- Up to 2 examples of past inputs the user has handled in this domain
You receive NO other context. You are stateless.
STANDARD MODE (content / workflow / subagent)
Step 1: Propose 2 or 3 example scenarios
Read the draft's description, When to use, and What you bring (Inputs). Generate 2 or 3 scenarios that match those triggers and inputs. They should be:
- Realistic for the user's domain. No invented edge cases unless the draft claims to handle edge cases.
- Distinct. Don't test the same shape twice.
- Concrete. Specific names, numbers, dates — not "a meeting" but "a 30-minute hiring sync with three engineers."
Step 2: Execute the draft on each scenario
Follow the How it works (Steps) section literally. Do not adapt, summarize, or skip steps. If a step is ambiguous, that is a finding — note it and try a reasonable interpretation.
For each scenario, produce the output the draft promises in What you get (Output).
Step 3: Score against the Quality bar
Compare each output against the draft's Quality bar criteria. For each criterion, mark met, partially met, or not met.
Step 4: Return verdict
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.
- 2d ago First seen · 160 lines · 41 tokens per session scan A 0b10b98c2504
spell-tester is an agent published in the GitHub repository redhuntlabs/wizard (9 stars, last pushed 4mo ago), licensed MIT. It adds 41 tokens to every session and 1,484 once invoked, about $0.0002 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-08-31.
Other agents, from other repositories
pr-reviewer
Reads the git diff after a feature is pushed, tags every finding as Blocker or Nit, and produces ONE rollup task containing all findings. Does NOT read CI, does NOT merge. Use after the SWE has pushed the feature branch and before the orchestrator hands the PR back to the human for squash-merge.
software-engineer
Implements a single groomed task assigned by the orchestrator. Writes code and tests locally. Does NOT commit until the Tester has reviewed and approved. Use when a task is groomed and ready for implementation, or when the Tester has returned feedback that needs to be addressed.
oncall-engineer
Monitors CI/CD after git push. If the pipeline fails, identifies the related task from commit messages, reopens it, diagnoses the root cause, and hands a concrete fix task to the SWE — then re-verifies the pipeline turns green once the fix lands. Owns pipeline health; does not change application code itself. Use after…
_index
Festival is files and two CLIs the agent loop actually touches: fest and camp, installed and kept current by a third tool, festival. It works with any agent that can run shell commands and read files, which is nearly all of them. There is no plugin to install for the core loop: the agent runs fest next, reads the task…
codex
Codex runs Festival through a plugin that carries the skills and a session-start hook. The loop is the same fest next loop it is everywhere else. The plugin's job is narrow: make sure the fest and camp CLIs exist, and make sure the agent knows the vocabulary.
gemini
Gemini CLI installs Festival as an extension straight from GitHub, in one command. The extension carries a context file that imports every Festival skill, and a session-start hook that installs the fest and camp CLIs.