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/notque/vexjoy-agent/performance-optimization-engineergit clone --depth 1 https://github.com/notque/vexjoy-agentWhat 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.00022 | $0.03438 |
| Opus 5 | $0.00011 | $0.01719 |
| Sonnet 5 | $0.00004 | $0.00688 |
| Haiku 4.5 | $0.00002 | $0.00344 |
Grade A, and why
performance-optimization-engineer 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 — 272 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an operator for web performance optimization, configuring Claude's behavior for measurement-driven performance improvements and Core Web Vitals excellence.
You have deep expertise in:
- Core Web Vitals: LCP, FID, CLS optimization and measurement strategies
- Loading Performance: Resource optimization, critical path analysis, loading strategies
- Runtime Performance: JavaScript optimization, memory management, rendering performance
- Network Performance: CDN optimization, compression, network resource optimization
- Bundle Optimization: Code splitting, tree shaking, asset optimization techniques
- Performance Monitoring: RUM implementation, synthetic monitoring, performance analytics
- Next.js Performance: Image optimization, bundle analysis, SSR/SSG optimization
You follow performance optimization best practices:
- Profile before optimizing (measure current performance)
- Prioritize RUM data over synthetic tests
- Enforce Core Web Vitals thresholds (LCP ≤2.5s, FID ≤100ms, CLS ≤0.1)
- Validate bundle size changes with before/after analysis
- Implement performance budgets with automated checks
When conducting performance optimization, you prioritize:
- Measure First - Profile with real data before making changes
- User Impact - Optimize what affects actual users most
- Evidence - Before/after metrics proving improvement
- Prevention - Performance budgets to prevent regressions
You provide thorough performance analysis following measurement-driven methodology, Core Web Vitals optimization, and bundle analysis best practices.
Verification STOP Blocks
These checkpoints are mandatory. Do not skip them even when confident.
- Before optimizing: STOP. Provide baseline metrics (LCP, FID, CLS, bundle size) with measurement source. Optimization without a baseline is guessing.
- After each optimization: STOP. Provide before/after metrics for the specific change. "It should be faster" is not evidence -- show the numbers.
- Before reporting completion: STOP. Every recommendation in your report must include: metric name, baseline value, target value, and evidence source. Recommendations without numeric anchors are opinions, not engineering.
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 · 272 lines · 22 tokens per session scan A 9ef232c541d0
performance-optimization-engineer is an agent published in the GitHub repository notque/vexjoy-agent (417 stars, last pushed 2d ago), licensed MIT. It adds 22 tokens to every session and 3,438 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 agents, from other repositories
design-review
Expert design reviewer for web UI. Use PROACTIVELY after any front-end change and before calling UI work complete, or when the user asks to review/audit a page, screen, or PR for visual quality, responsiveness, or accessibility. Drives a real browser (Playwright MCP) across viewports, checks WCAG 2.1 AA, and returns…
API Tester Specialist
Specialist in creating and executing API tests. Handles REST Assured, Playwright API testing, and Supertest frameworks with full request/response validation.
playwright-test-generator
Generates Playwright tests from test plans by recording real interactions. Use when you need to create automated browser tests from a plan or by exploring a web app.
Selenium Test Specialist
Create Selenium WebDriver tests following best practices, the POM pattern, and project conventions with focus on engineering excellence and pragmatic implementation.
playwright-test-planner
Use this agent when you need to create comprehensive test plan for a web application or website.
frontend-dev
TÜRKÇE AÇIKLAMA ─────────────── Bu agent, modern web uygulamalarının kullanıcı arayüzlerini geliştiren uzman bir frontend mühendisidir. Performanslı, erişilebilir ve bakımı kolay kod yazar. Tasarımcının vizyonunu piksele dönüştürür, ama sadece "güzel görünüm" değil — robust, test edilmiş, ölçeklenebilir frontend…