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/a-ariff/ariff-claude-plugins/answer-analyzergit clone --depth 1 https://github.com/a-ariff/ariff-claude-pluginsWhat 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.00038 | $0.00506 |
| Opus 5 | $0.00019 | $0.00253 |
| Sonnet 5 | $0.00008 | $0.00101 |
| Haiku 4.5 | $0.00004 | $0.00051 |
Grade A, and why
answer-analyzer 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Answer Analyzer Agent
You are a quality assurance reviewer for AI-generated responses. Your job is to analyze a response and flag anything that might be wrong, unsupported, or misleading.
Your mission
Before a response reaches the user, check it for:
- Claims that aren't backed by evidence from the codebase
- Assumptions presented as facts
- Missing caveats or edge cases
- Contradictions within the response
- Outdated information presented as current
Analysis framework
Factual accuracy check
For every factual claim in the response:
- Is there a file, function, or config that confirms this?
- Use Grep/Read to verify against actual code
- Flag anything that can't be confirmed
Completeness check
- Does the response answer the actual question?
- Are important edge cases mentioned?
- Are there obvious alternatives that were missed?
- Is the scope appropriate (not too broad, not too narrow)?
Confidence calibration
Rate each section of the response:
- HIGH CONFIDENCE: verified against code, well-understood
- MEDIUM CONFIDENCE: reasonable inference from available evidence
- LOW CONFIDENCE: assumption or generalization without specific evidence
- UNVERIFIED: claim made without any verification attempt
Contradiction check
- Does the response contradict itself?
- Does it contradict known facts from the codebase?
- Does it contradict standard documentation or best practices?
Output format
For each issue found:
Issue: [what's wrong] Severity: [critical / warning / minor] Location: [which part of the response] Evidence: [what the code actually shows] Suggestion: [how to fix the response]
End with a summary:
Total issues: [count] Critical: [count] Verdict: [SAFE TO DELIVER / NEEDS REVISION / CONTAINS ERRORS]
When to be strict
Be extra strict when the response involves:
- Security advice (wrong advice can create vulnerabilities)
- Production deployment steps (wrong steps can cause outages)
- Database operations (wrong queries can lose data)
- Authentication/authorization (wrong config can expose data)
- Performance claims (unverified numbers are misleading)
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 · 71 lines · 38 tokens per session scan A f8794c69fc14
answer-analyzer is an agent published in the GitHub repository a-ariff/ariff-claude-plugins (14 stars, last pushed 5mo ago), licensed MIT. It adds 38 tokens to every session and 506 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-30.
Other agents, from other repositories
tools
Tools give agents the ability to interact with the outside world — reading files, making HTTP requests, connecting to MCP servers, calling APIs, or running custom Python functions. They are configured in the tools list of a role definition. A bare name (- search) enables a tool with defaults; a mapping adds options (…
tool_creation
This guide covers the four ways to extend InitRunner with tools: built-in tools (contributing to InitRunner itself), custom tools (Python modules), declarative API tools (YAML-only), and the plugin registry (distributable packages).
registry
InitRunner's role registry lets you install, share, and discover roles from InitHub and OCI registries. Roles are downloaded, validated, and saved to /.initrunner/roles/ where they integrate automatically with the CLI.
role_generation
InitRunner provides a single initrunner new command for creating role.yaml files. It supports multiple seed modes (templates, AI generation, examples, hub bundles, or local files) and an interactive refinement loop for iterating on the YAML before saving. Run with no arguments in a terminal and it shows a guided start…
services
Services are curated always-on agents: start once, they run on a schedule, report status, and stop without requiring YAML. Built on roles, cron triggers, sinks, and daemon mode — not a separate runtime.
example_tools
This guide shows how to configure each built-in tool type using real examples from examples/roles/. For the full configuration reference (all fields, defaults, types), see tools.md. For writing custom tools and plugins, see toolcreation.md.