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/lebek/modmixer/tester-buildgit clone --depth 1 https://github.com/lebek/modmixerWrote 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/commands/lebek/modmixer/tester-build)<a href="https://agentmods.dev/commands/lebek/modmixer/tester-build"><img src="https://agentmods.dev/badge/commands/lebek/modmixer/tester-build.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 | $0.00020 | $0.00656 |
| Opus 5 | $0.00010 | $0.00328 |
| Sonnet 5 | $0.00004 | $0.00131 |
| Haiku 4.5 | $0.00002 | $0.00066 |
Grade A, and why
tester-build 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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/tester-build
You are running the /tester-build command. Walk through these steps in order. Be concise — one sentence per step at most. Do not narrate plans; just do the work.
1. Check working tree
Run git status --porcelain. If it has any output, tell the user the tree is dirty (show what's changed) and stop. The build runs from the committed branch state — uncommitted changes wouldn't be tested.
2. Confirm target
Default is win-x64 (covers most testers). Ask:
Build for which target? (win-x64 / win-arm64 / all) [default: win-x64]
Accept these answers:
- empty /
yes/default→win-x64 win-x64,win-arm64,all→ use as-is- anything else → ask again
all builds every matrix entry but takes the same wall-clock time (parallel runners) and downloads both Windows installers.
3. Run the script
Run:
node scripts/tester-build.mjs --target <target>
Stream output so the user sees progress. The script will:
- Verify
ghis authed. - Push the current branch if it has unpushed commits.
gh workflow run release.yml --ref <branch>to dispatch.- Poll for the new run, then
gh run watchit (~10–15 min). - Download the artifact to
out/tester-build/<run-id>/<target>/. - Print the path to the Setup.exe and the run URL.
4. Report
When the script finishes:
- Success: print the absolute path(s) to the Setup.exe and the run URL. Remind the user that Discord's 25 MB free / 50 MB Nitro upload cap means they'll need a file host (Drive, WeTransfer) for the ~150-200 MB installer, or share the GitHub artifact link if the tester has repo read access.
- Failure: print the run URL the script logged. Don't try to fix it automatically — the user decides whether to retry, edit code and re-dispatch, or check signing config.
Notes on edge cases
- If
ghcomplains about auth: tell the user to rungh auth login(interactive — they need to do it themselves). - If the user is on
mainand wants to test an unmerged change, they should switch to a feature branch first./tester-buildalways dispatches against the current branch. - The signed installer is a real Squirrel
.exe— testers won't see SmartScreen warnings (Trusted Signing certs are recognized). It installs to%LOCALAPPDATA%\modmixer\and self-updates from GitHub Releases, same as a tagged release. - If the user has Trusted Signing quota concerns, mention that each tester build burns a small amount of quota (sign operations per day are limited).
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 · 56 lines · 20 tokens per session scan A 43339795394c
tester-build is a command published in the GitHub repository lebek/modmixer (19 stars, last pushed 23d ago), licensed MIT. It adds 20 tokens to every session and 656 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-30.
Other commands, from other repositories
security-test
Fast, continuous DevSecOps pipeline for Pull Requests and active branches. Runs SAST, SCA, and secrets detection to catch vulnerabilities before they merge.
release
You are a release agent for the Gigacode project (sandbox-agent). Your job is to cut a new release by running the release script, monitoring the GitHub Actions workflow, and fixing any failures until the release succeeds.
ci
Re-install all skills and MCP servers from lockfile (CI mode).
ship
Mechanical pre-deploy gate — tests, build, tree state.
ci
Push branch and trigger CI workflow.
release
Verify, sweep docs, cut a version — then hand the release sequence back.