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 skills/cboone/agent-harness-plugins/add-scrut-cli-testsnpx skills add cboone/agent-harness-plugins --skill add-scrut-cli-testsgit clone --depth 1 https://github.com/cboone/agent-harness-pluginsWrote 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/cboone/agent-harness-plugins/add-scrut-cli-tests)<a href="https://agentmods.dev/skills/cboone/agent-harness-plugins/add-scrut-cli-tests"><img src="https://agentmods.dev/badge/skills/cboone/agent-harness-plugins/add-scrut-cli-tests.svg" alt="Measured on agentmods" height="20"></a>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.00125 | $0.05392 |
| Opus 5 | $0.00063 | $0.02696 |
| Sonnet 5 | $0.00025 | $0.01078 |
| Haiku 4.5 | $0.00013 | $0.00539 |
Grade A, and why
add-scrut-cli-tests 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 5d 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 — 522 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Add Scrut CLI Tests
Set up scrut snapshot-based CLI integration testing for a CLI project with Makefile targets and CI workflow integration.
Prerequisites
- A CLI project that produces a binary or has an executable entry point
- A
.github/workflows/ci.ymlworkflow (or equivalent CI workflow file) is recommended for CI integration
Workflow
1. Detect the Project Type
Identify the project language by checking for manifest files:
| Marker(s) | Language |
|---|---|
go.mod |
Go |
Package.swift |
Swift |
Cargo.toml |
Rust |
build.zig |
Zig |
pyproject.toml, setup.py |
Python |
Gemfile, *.gemspec |
Ruby |
| Executable scripts (no manifest) | Shell |
If no manifest is found and executable shell scripts exist in the root, bin/, or scripts/, treat the project as a shell script CLI.
If the project type cannot be determined, ask the user what language the project uses and where the binary or executable is located.
Check for an existing tests/scrut/ directory; if present, warn and ask whether to add to it or abort.
2. Gather Project Information
Collect the following, inferring from existing files where possible:
- Binary name: determine by project type:
- Go: check the Makefile
buildtarget for the output binary name (look for-o bin/NAMEor-o NAME), or derive from the last segment of the module path ingo.mod - Swift: check
Package.swiftfor executable target names, or check the Makefilebuildtarget - Rust: check
Cargo.tomlfor[[bin]]entries or thenamefield under[package] - Zig: check
build.zigforb.addExecutable(.{ .name = "..." })and use the.namevalue, or use the directory name - Python: check
pyproject.tomlfor[project.scripts]entries - Ruby: check the gemspec for
executablesor look inbin/orexe/ - Shell: use the script filename as the binary name
- Go: check the Makefile
- Binary path: determine the full path used to run the binary:
- Compiled languages (Go, Swift, Rust, Zig): typically
bin/NAMEor a build output directory (e.g.,$(CURDIR)/bin/NAMEfor Go,$(CURDIR)/zig-out/bin/NAMEfor Zig) - Interpreted languages (Python, Ruby, Shell): the script path itself (e.g.,
bin/NAME,./NAME)
- Compiled languages (Go, Swift, Rust, Zig): typically
- Environment variable name: derive from the binary name, uppercased with hyphens replaced by underscores, suffixed with
_BIN(e.g.,bopcabecomesBOPCA_BIN,my-toolbecomesMY_TOOL_BIN) - Build required: whether a build step is needed before running tests (yes for compiled languages, no for interpreted languages)
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.
- 5d ago First seen · 522 lines · 125 tokens per session scan A 90768365597b
add-scrut-cli-tests is a skill published in the GitHub repository cboone/agent-harness-plugins (2 stars, last pushed 1mo ago), licensed MIT. It adds 125 tokens to every session and 5,392 once invoked, about $0.0006 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 skills, from other repositories
11-browser-qa
Run post-review browser QA and produce short named videos for a locked happy path and sourced browser edge cases. Use when the user wants concise reviewer evidence for a web journey. Not for API, CLI, automated tests, diff review, or application fixes.
aidd-dev:05:test
Write and iterate on tests until they pass, and validate user journeys end-to-end in the browser.
test
Creates or modifies tests in tests/ following the project's three-tier pyramid. Use when writing tests for a new or existing use-case, adapter, domain model, or CLI command; when reproducing a user-reported bug; or when auditing coverage. Do NOT use for implementing production code — use the layer skills (use-case…
06-test
Write and iterate tests until they pass, or validate a user journey end to end in the browser. Use when the user wants to add coverage, find what's untested, or walk a flow. Not for auditing test health or debugging a failure.
testing-patterns
Testing patterns for unit, integration, and end-to-end tests. Use when writing tests, setting up test fixtures, or validating RLS enforcement. Routes to existing test conventions.
nestjs-testing-expert
NestJS testing mechanics with Jest — building testing modules, mocking providers and repositories, writing service and controller specs, and driving HTTP end-to-end tests through the real application. Use for any test touching a NestJS service, controller, guard, module, or API endpoint, including test-module setup…