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/zircote-plugins/sdlc-quality/run-testsgit clone --depth 1 https://github.com/zircote-plugins/sdlc-qualityWhat 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.00024 | $0.00730 |
| Opus 5 | $0.00012 | $0.00365 |
| Sonnet 5 | $0.00005 | $0.00146 |
| Haiku 4.5 | $0.00002 | $0.00073 |
Grade A, and why
run-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 3d 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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/run-tests
Execute the automated functional test suite to validate all project components.
Usage
/run-tests [options]
Options
--category <name>- Run only tests in specified category--tag <tag>- Run only tests with specified tag--verbose- Show detailed output for each test--dry-run- Show tests that would run without executing
Execution Strategy
- Read test definitions from
tests/functional/tests.yaml - Initialize test state in
.claude/test-state.json - Execute tests sequentially, tracking results
- Validate each test response against expected patterns
- Generate summary report
State Management:
- State file tracks: current test, results, saved variables
- Each test can save output values for dependent tests
- Tests with
depends_onwait for dependencies to pass
Workflow
Phase 1: Initialization
-
Load Test Suite
- Read
tests/functional/tests.yaml - Parse test definitions
- Filter by category/tag if specified
- Read
-
Initialize State Run:
./tests/functional/runner.sh reset && ./tests/functional/runner.sh init -
Show Test Plan Display total tests and categories to run
Phase 2: Test Execution Loop
For each test, execute automatically without waiting for user input:
-
Get Next Test Run:
./tests/functional/runner.sh next -
Execute Test Action Parse the action from test output and execute it:
- If action starts with "Run:" - execute the bash command
- If action starts with "Check:" - cat/ls the target file
- Otherwise - execute as described
-
Validate Response Run:
./tests/functional/runner.sh validate "$response" -
Record and Continue Display pass/fail result and proceed to next test
Phase 3: Report Generation
After all tests complete:
Run: ./tests/functional/runner.sh report --format md
Display final summary with pass/fail counts.
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.
- 3d ago First seen · 131 lines · 24 tokens per session scan A 0b14d5ca30f8
run-tests is a command published in the GitHub repository zircote-plugins/sdlc-quality (10 stars, last pushed 1mo ago), licensed MIT. It adds 24 tokens to every session and 730 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
merge
Finish a PR properly: every check green, every review addressed — human and bot — then merge and clean up.
pr
Prepare and open a pull request the senior way: gate, template, scrubbed, everything visible.
spec
Spec-first design: a gap-closing interview that produces a complete spec, with a quality controller that blocks until every section is answered and every question resolved.
copilot-leak
Copilot's auto-review escapes: find them since the last look, sanitise them, and turn each one into a lesson.
docs
The documentation report: references, diagrams, drift, API docs, badges, README structure, links, Pages.
plan
Turn an approved spec into an implementation plan an engineer with zero context could execute — with a quality controller that blocks placeholders and hollow tasks.