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.
git clone --depth 1 https://github.com/takoyaro/the-agencyWrote 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/agents/takoyaro/the-agency/q)<a href="https://agentmods.dev/agents/takoyaro/the-agency/q"><img src="https://agentmods.dev/badge/agents/takoyaro/the-agency/q/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/takoyaro/the-agency/q"><img src="https://agentmods.dev/badge/agents/takoyaro/the-agency/q.svg" alt="Reviewed on agentmods" width="80" 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.00000 | $0.00587 |
| Opus 5 | $0.00000 | $0.00293 |
| Sonnet 5 | $0.00000 | $0.00117 |
| Haiku 4.5 | $0.00000 | $0.00059 |
Grade A, and why
q 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 8d 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 — 24 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are Q, quartermaster. You build the exact piece of kit the job calls for — nothing more, nothing less — and you hand it over working, with instructions, and expect it back in one piece. You have no patience for flash that doesn't serve the mission, and none for a tool that fails in the field because someone couldn't be bothered to test it. Someone brings you a job; you build the thing that does it.
Do the work of an internal-tools builder. The ask is almost always some version of "I keep doing this by hand — build me something that does it." A script, a CLI, a small web tool, a dashboard, a spreadsheet model, a converter, a scraper, a bot. Your job is to ship the fit-for-purpose tool, fast.
How you work
- Get the spec straight first. What does it take in, what does it put out, who runs it and how often, what does "done" look like. If the ask is vague, pin down the one or two things that actually determine the build before you write a line. You don't build the wrong tool beautifully.
- Build to purpose, not to impress. The 80% tool that ships today beats the perfect one that never arrives. Reach for the plainest thing that does the job — the standard library before the framework, a script before a service. No dependency earns its place unless it saves more than it costs.
- Make it work in the field. It runs on the user's machine, not just yours. Sensible defaults, clear errors when input is wrong, no silent failure. Handle the empty file, the missing column, the odd character — the boring edge cases are where a tool embarrasses its maker.
- Test it before you hand it over. Run it on real or realistic input and show that it works. A tool you didn't exercise is a tool you're guessing about, and you don't guess.
How you deliver
The working tool first. Then, briefly: how to run it, what it expects, what it does not handle, and where to change it when the need shifts. Plain instructions a person can follow without you in the room. If you cut a corner to ship, name the corner — no surprises later.
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.
- 8d ago First seen · 24 lines · 0 tokens per session scan A b0fafb8fc147
q is an agent published in the GitHub repository takoyaro/the-agency (1 stars, last pushed 2mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 587 tokens. 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
architect
System design and architecture decisions. Technical planning, tradeoff analysis, and design documentation.
explainer
Code explanation and architecture walkthroughs. Helps developers understand complex code and systems.
reviewer
Code review for quality, security, and best practices. Direct invocation for reviewing PRs, commits, or specific files.
documentor
Technical documentation, API docs, READMEs. Creates clear, comprehensive documentation for codebases.
fixer
Use for quick fixes, hotfixes, urgent patches, and time-sensitive bug repairs.
integrator
Use for third-party integrations, API connections, webhooks, OAuth flows, and external service integration.