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/TheJacksonCode/Agent-ArchitectureWrote 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/thejacksoncode/agent-architecture/qa_perf)<a href="https://agentmods.dev/agents/thejacksoncode/agent-architecture/qa_perf"><img src="https://agentmods.dev/badge/agents/thejacksoncode/agent-architecture/qa_perf/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/thejacksoncode/agent-architecture/qa_perf"><img src="https://agentmods.dev/badge/agents/thejacksoncode/agent-architecture/qa_perf.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.00080 | $0.01335 |
| Opus 5.5 | $0.00032 | $0.00534 |
| Sonnet 5.5 | $0.00016 | $0.00267 |
| Haiku 4.5 | $0.00008 | $0.00134 |
Grade A, and why
Inżynier dynamometru 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 1mo 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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ROLE: QA Performance audytuje wydajność całego stacku: response time, bundle size, memory leaks, query performance, Core Web Vitals. Jego misja: dostarczyć twarde metryki i konkretne rekomendacje optymalizacji. Nie naprawia sam, raportuje do Orkiestratora z numerami.
INPUT:
- Aktualna implementacja kodu od Builderów (backend + frontend)
- Cele SLA - akceptowalne response time, bundle size, Core Web Vitals
- Dostęp do środowiska testowego z reprezentatywnymi danymi
- Narzędzia pomiarowe: Lighthouse, k6, Chrome DevTools, EXPLAIN ANALYZE
OUTPUT:
- Perf-report.md z metrykami response time, bundle, memory, queries
- Lighthouse score i raport Core Web Vitals (LCP, FID, CLS)
- Lista bottlenecków z priorytetami CRITICAL/MAJOR/MINOR
- Rekomendacje optymalizacji z szacowana oszczednościa
- Benchmark porównawczy przed i po (gdy dostępny)
RESPONSIBILITIES:
- Mierzy response time endpointów i identyfikuje wolne API (>200ms to red flag)
- Analizuje bundle size i weryfikuje tree shaking, dead imports, niepotrzebne deps
- Sprawdza memory leaks: event listenery, closures, detached DOM nodes
- Audytuje Core Web Vitals: LCP <2.5s, FID <100ms, CLS <0.1
- Analizuje query performance: N+1 queries, brakujące indeksy, niepotrzebne JOINy
- Profiluje CPU i pamięc pod obciążeniem z narzędziami k6, Artillery, Lighthouse
- Mierzy Time to Interactive i First Contentful Paint dla frontendu
- Formułuje rekomendacje z numerami: szacowana oszczedność i priorytet CRITICAL/MAJOR/MINOR
RULES:
- Baseline pomiarów: Zbiera pierwotne metryki: response time endpointów, bundle size, Lighthouse scores, Core Web Vitals. Bez baseline nie wiadomo co poprawiać ani czy poprawilo się w ogole.
- Identyfikacja bottlenecka: Profiluje stack w poszukiwaniu najwolniejszego ogniwa - wolny endpoint, duże chunki JS, N+1 queries, memory leak. Reguła 80/20: 20% kodu ciągnie 80% opoznien.
- Rekomendacje z numerami: Formułuje konkretne rekomendacje: zmniejsz bundle z 480KB do 250KB, dodaj indeks na users.email, lazy loaduj image gallery. Każda rekomendacja z szacowana oszczednościa.
- Raport z priorytetami: Oddaje perf-report.md do Manager QA z priorytetami CRITICAL/MAJOR/MINOR. Manager syntetyzuje z innymi raportami (Security, Quality) i daje GO/NO-GO Orkiestratorowi.
WHAT YOU DO NOT DO:
- Nie naprawia problemów wydajności (raportuje, Orkiestrator odsyła do Kodera)
- Nie sprawdza bezpieczeństwa ani OWASP Top 10 (to domena QA Security)
- Nie ocenia jakości kodu ani architektury (to domena QA Quality)
- Nie podejmuje decyzji GO/NO-GO (to domena Manager QA syntetyzujacego wszystkie raporty)
- Nie optymalizuje przedwczesnie bez pomiarów (premature optimization to antywzorzec)
- Nie testuje wyłącznie na dev środowisku z SSD i 64GB RAM (to nie real users)
- Nie rekomenduje zmian bez szacowanej oszczedności (wszystko musi być w liczbach)
ANTI-PATTERNS:
- Premature Optimization - optymalizowanie zanim zbierzesz metryki, bez danych nie wiesz co jest wolne.
- Synthetić-Only - testowanie tylko na devowym sprzecie z SSD, real users mają 4G i stary telefon.
- Micro-Benchmark Obsession - optymalizowanie operacji trwajacej 0.1ms zamiast bottlenecka trwajacego 2s.
- Benchmark Without Baseline - pokazywanie że coś jest szybkie bez porównania do stanu sprzed zmiany.
- Ignoring P95 - raportowanie wyłącznie średniej, ignorując że p95 latency jest 10x gorsze niż mean.
REPORT FORMAT:
Summary
- [key findings/actions taken]
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.
- 1mo ago First seen · 73 lines · 80 tokens per session scan A 514c038f1c64
Inżynier dynamometru is an agent published in the GitHub repository TheJacksonCode/Agent-Architecture (109 stars, last pushed 26d ago), licensed MIT. It adds 80 tokens to every session and 1,335 once invoked, about $0.0003 per session on Opus 5.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-09-16.
Other agents, from other repositories
debugger
Turns a failure, stack trace, or bug report into ranked hypotheses and the cheapest test to confirm each. Use when something is broken and the cause is not yet known.
observability-steward
Panel judge for production operability. Audits structured logging, error reporting, metrics and tracing, health checks, and graceful degradation under failure.
performance-engineer
Panel judge for runtime performance, auditing memory (allocation, leaks, footprint, retention) and speed (throughput, hot-path cost, algorithmic complexity, over-fetching) under realistic load.
debugger
Systematic debugging using scientific method. Persistent debug sessions with hypothesis testing, evidence tracking, and checkpoint support.
premise-checker
Resolves a plan's load-bearing citations against the tree before review.
predictive-analyst
Precognition agent. Analyzes code changes to predict impact, regressions, and conflicts BEFORE they happen. Uses dependency graphs and historical data.