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/adobecom/da-express-milo/performance-checkgit clone --depth 1 https://github.com/adobecom/da-express-miloWhat 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.00000 | $0.01095 |
| Opus 5 | $0.00000 | $0.00548 |
| Sonnet 5 | $0.00000 | $0.00219 |
| Haiku 4.5 | $0.00000 | $0.00110 |
Grade A, and why
performance-check 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 2d 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 — 132 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Check Subagent
This script is delegated from Phase 7 of the main SKILL.md. Run only after the visual comparison loop (Phase 5) and the accessibility audit (Phase 6) are complete.
Target thresholds
The project maintains Lighthouse scores above 90. The block must not cause regressions.
| Metric | Target | Why it matters |
|---|---|---|
| Overall score | ≥ 90 | Composite performance health |
| LCP (Largest Contentful Paint) | ≤ 2.5 s | Most important metric — measures perceived load speed |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | Layout stability |
| INP (Interaction to Next Paint) | ≤ 200 ms | Responsiveness |
| TBT (Total Blocking Time) | ≤ 200 ms | Main-thread availability |
Tool
Uses the lighthouse CLI (installed as a project dev dependency)
executed via Playwright MCP's shell/terminal access.
Procedure
- Run Lighthouse against the Playwright URL in headless Chrome:
npx lighthouse <playwright-url> \ --output=json \ --output-path=/tmp/lighthouse-report.json \ --chrome-flags="--headless --no-sandbox" \ --only-categories=performance - Parse the JSON output and extract:
categories.performance.score(multiply by 100 for the percentage)audits['largest-contentful-paint'].numericValue(LCP in ms)audits['cumulative-layout-shift'].numericValue(CLS)audits['total-blocking-time'].numericValue(TBT in ms)audits['interaction-to-next-paint'].numericValue(INP in ms, if available — this may require user interaction to measure)
- Assess each metric against the target thresholds.
LCP-specific assessment
Since LCP is the most critical metric, perform additional analysis:
- Identify the LCP element from the Lighthouse report:
audits['largest-contentful-paint'].details. - Check if the LCP element is inside the new block.
- If yes, the block directly impacts LCP. Assess whether the block's CSS or JS is delaying the LCP paint.
- If no, the block is not the LCP bottleneck — but still verify it doesn't add blocking resources.
- Common LCP pitfalls in blocks:
- JS that runs synchronously before the block's content is visible.
- CSS that hides content on initial load and reveals it after a
transition (e.g.
opacity: 0→opacity: 1with a delay). - Large unoptimised images loaded eagerly above the fold.
- Web fonts that block text rendering.
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.
- 2d ago First seen · 132 lines · 0 tokens per session scan A 9bb7af12a0fb
performance-check is an agent published in the GitHub repository adobecom/da-express-milo (6 stars, last pushed 2d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 1,095 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
cli-ui-designer
CLI interface design specialist. Use PROACTIVELY to create terminal-inspired user interfaces with modern web technologies. Expert in CLI aesthetics, terminal themes, and command-line UX patterns.
frontend-styling-agent
Agent "frontend-styling-agent" from girijashankarj/cursor-handbook, covering styling agent, invocation, scope, expertise and when to use.
html-first-frontend
HTML-first frontend specialist using HTMX, Alpine.js, and Bootstrap for progressive enhancement. Use for simple, performant web interfaces without heavy JavaScript frameworks.
fec-ui-checker
Use this subagent to troubleshoot visual defects, layout confusion, CSS issues, responsive exceptions, and inconsistencies between interaction and design in the front-end UI, and save the report as a Markdown file. Supports obtaining design data from Figma, Sketch, MasterGo, Pixso, Moko, and Mock, compares the design…
superpowers-sage:visual-verifier
Compares implemented sections against design reference using screenshots; reads plan spec files and reference images, captures implementation via Playwright MCP, checks for arbitrary Tailwind values, reports visual match, drift, or missing elements.
ux-designer
UI/UX designer agent. Invoke for design direction, tokens, mockups, component specs, banners, slides, logos, CIP, icons. Produces HTML/CSS + tokens + specs — never .tsx React code. Target stack — React + Vite + Tailwind with shadcn/ui.