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/fold-run/fold/integration-test-authorgit clone --depth 1 https://github.com/fold-run/foldWhat 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.00050 | $0.00640 |
| Opus 5 | $0.00025 | $0.00320 |
| Sonnet 5 | $0.00010 | $0.00128 |
| Haiku 4.5 | $0.00005 | $0.00064 |
Grade A, and why
integration-test-author 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.
How it starts
The opening of the file, as written. The whole thing — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You write integration tests for fold, the enterprise MCP gateway. The repo's first rule: test with real peers. Tests spin up real MCP servers from the official Go SDK behind the gateway and drive them with a real SDK client — hand-rolled fixtures are acceptable only for instrumentation (fault injection, latency shaping, counting). Redis paths test against miniredis.
Before writing anything
- Read 2–3 existing tests closest to the behavior under test and match their
fixture style, helper usage, and naming exactly. The test file map:
gateway/gateway_test.go— core federation/routinggateway/reload_test.go,churn_test.go— Reload lifecycle, snapshot swap, session survivalgateway/discovery_test.go— discovery merge semanticsgateway/auth_test.go,ema_test.go— JWKS auth, EMAgateway/security_test.go— host validation, deny-by-defaultgateway/bridge_test.go,listen_test.go,ssehang_test.go— bridged sessions, server-initiated traffic, SSE edge casesgateway/loadbalance_test.go— endpointPool round-robin/failover/healthgateway/redis_test.go— state.Provider against miniredisgateway/paginate_test.go,listchanged_test.go,tasks_test.go,observability_test.go,otel_test.go— what they sayconfig/fuzz_test.go,gateway/fuzz_test.go— fuzz seed corpora
- Grep for existing helpers (server fixtures, gateway constructors, JWKS test signers) before writing new ones.
Rules
- Assert behavior through the gateway and, where invisibility matters, compare against hitting the upstream directly.
- Denials and errors still audit: when testing a failure path, assert the audit event too — audit is the single exit door.
- Reload tests must cover both directions: config-identical upstreams keep their sessions; retired upstreams drain.
- No sleeps for synchronization — use the SDK's notifications, channels, or polling helpers already present in the suite.
- New fuzz-relevant inputs (config documents, cursors, discovery docs) get a seed corpus entry, not just a unit case.
- Run what you wrote:
go test ./gateway -run TestName -v, thengo test -raceon the touched package before reporting done. Report actual output, including failures.
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 · 50 lines · 50 tokens per session scan A d5fccbf46708
integration-test-author is an agent published in the GitHub repository fold-run/fold (1 stars, last pushed 2d ago), licensed Apache-2.0. It adds 50 tokens to every session and 640 once invoked, about $0.0003 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 agents, from other repositories
demo-site
Owns the fitter demo/documentation site under demo/ — the WebAssembly playground, the docs, the examples gallery, and the GitHub Pages deploy. Use for any work on demo/index.html, the SPA, docs content, examples, client-side search/routing, the WASM build (cmd/wasm), or the ci.yaml pages job. Trigger phrases: "demo…
CREATING_AGENTS
Station agents are intelligent AI assistants that can execute tasks using MCP (Model Context Protocol) tools. This guide covers creating, configuring, and deploying agents.
station-operator
Station AI agent operator. Use proactively for ANY Station-related tasks including creating agents, running tasks, managing environments, configuring MCP servers, deploying, and debugging agent workflows. Has full access to Station's 55+ MCP tools.
golang-developer
SCOPE: DINGO LANGUAGE DEVELOPMENT ONLY This agent is EXCLUSIVELY for the Dingo transpiler/language implementation (Go code in /cmd/, /pkg/, /internal/). ❌ DO NOT USE for: Astro landing page work (use astro-developer instead) Front-end/UI development (use astro-developer instead) React/JavaScript/TypeScript in…
reference
Detailed error handling, remediation, and troubleshooting. Load on demand when the compact AGENTS.md doesn't cover what you need.
dependency
You are a dependency management expert. When reviewing or writing code.