flaky-test-hunter
Finds and diagnoses flaky tests in a test suite. Use when tests pass locally but fail in CI, when a suite fails intermittently, or when the user asks to stabilise or de-flake their tests.
963 instalaciones · v1.1.0
Audits a web application for Core Web Vitals regressions. Use when the user asks to check LCP, INP or CLS, investigate a Lighthouse score drop, or review front-end performance before a release.
npx skillsify add core-web-vitals-auditUna auditoría de rendimiento solo sirve si nombra la causa, no el síntoma. Esta skill guía al agente para medir LCP, INP y CLS, localizar el elemento o la tarea concreta responsable de cada regresión y proponer una corrección anclada a un archivo y una línea. Se niega a recomendar cambios cuyo efecto sobre una métrica concreta no pueda predecirse, y eso es lo que mantiene su salida accionable en lugar de una lista de consejos genéricos.
---
name: core-web-vitals-audit
description: Audits a web application for Core Web Vitals regressions. Use when the user asks to check LCP, INP or CLS, investigate a Lighthouse score drop, or review front-end performance before a release.
---
# Core Web Vitals audit
## When to use this
The user reports slow loading, a Lighthouse score drop, visible layout shift, or
wants a performance check before shipping.
## Procedure
1. Identify the entry route and whether it is server-rendered, static or client-rendered.
2. Measure first, guess never. Collect LCP, INP and CLS for the route.
3. Compare each metric against the thresholds in [references/thresholds.md](references/thresholds.md).
4. For every metric outside "good", find the specific cause before proposing a fix:
- **LCP** — locate the LCP element. Check whether it is discoverable in the initial HTML, whether it is preloaded, and whether a render-blocking resource precedes it.
- **CLS** — find elements without reserved dimensions, late-loading fonts, and content injected above existing content.
- **INP** — find long tasks on the main thread and event handlers doing layout-triggering work.
5. Report each finding as: metric, measured value, cause, file and line, concrete fix.
## Rules
- Never report a fix without the measurement that motivated it.
- Never recommend a change whose effect you cannot predict on a named metric.
- Prefer removing work over deferring it.# Core Web Vitals thresholds
| Metric | Good | Needs improvement | Poor |
| --- | --- | --- | --- |
| LCP | <= 2.5 s | 2.5 s - 4.0 s | > 4.0 s |
| INP | <= 200 ms | 200 ms - 500 ms | > 500 ms |
| CLS | <= 0.1 | 0.1 - 0.25 | > 0.25 |
Thresholds are evaluated at the 75th percentile of page loads, segmented by
device class. A desktop-only measurement is not a pass.
Finds and diagnoses flaky tests in a test suite. Use when tests pass locally but fail in CI, when a suite fails intermittently, or when the user asks to stabilise or de-flake their tests.
963 instalaciones · v1.1.0
Reviews third-party dependencies for supply-chain and licence risk. Use when the user asks to audit dependencies, evaluate whether to add a package, review a lockfile diff, or check licence compatibility.
741 instalaciones · v1.0.3
Audits a web interface for right-to-left layout correctness in Arabic, Hebrew, Persian or Urdu. Use when adding an RTL locale, when the user reports mirrored or broken Arabic layout, or before shipping a bilingual interface.
688 instalaciones · v1.1.1