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 commands/xsovad06/sova/testgit clone --depth 1 https://github.com/xsovad06/sovaWhat 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.00017 | $0.00373 |
| Opus 5 | $0.00009 | $0.00187 |
| Sonnet 5 | $0.00003 | $0.00075 |
| Haiku 4.5 | $0.00002 | $0.00037 |
Grade A, and why
test 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.
What it actually says
Test Runner
Run tests and linter, fixing issues iteratively until everything passes.
Instructions
Step 1: Identify the Scope
Determine what to test from $ARGUMENTS or the current directory.
If unclear, check git diff --name-only to see which modules have changes.
Step 2: Run Linter
Run the project's lint command: {{ lint_cmd }}
If linter fails:
- Analyze the errors
- Fix the code issues
- Re-run until it passes
Step 3: Run Tests
Run the project's test command: {{ test_cmd }}
If tests fail:
- Analyze the test failures
- Fix the code or tests as needed
- Re-run until they pass
Step 4: Scout Check
While fixing test or lint failures, scan each touched file for pre-existing issues: flaky test patterns, stale imports, dead code. Fix them alongside the failures. Keep scout fixes small and low-risk.
Step 5: Iterate
Repeat Steps 2-4 until both linter and tests pass completely.
Cross-References
- After tests pass: Run
/reviewto self-review before pushing - Full workflow: Use
/develop-fullfor the complete develop-test-review-pr cycle
Rules
- Always fix linter issues before running tests
- After fixing issues, re-run to verify the fix
- Continue iterating until both pass
- Report final status when everything is green
- NEVER use emojis in any output
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 · 64 lines · 17 tokens per session scan A d9d3fe94e7ab
test is a command published in the GitHub repository xsovad06/sova (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 17 tokens to every session and 373 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-08-31.
Other commands, from other repositories
align
Unified alignment command (--project, --docs, --retrofit, --content).
dashboard
Phase 3 monitoring — System health, execution insights, and velocity analytics.
doctor
Check the health of a KARIMO installation, identify issues, and provide actionable recommendations.
greptile-review
Execute the full Greptile review cycle on a PR, looping until score meets threshold or circuit breaker triggers.
update
Check for and apply KARIMO updates from GitHub releases.
implement-fix
Minimal pipeline for test-fixing tasks.