eq-frontend-quality-bar

Enforces frontend quality gates covering tests, coverage, observability, performance, accessibility, and security.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/everquint/frontend-skills --skill eq-frontend-quality-bar-everquint
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eq-frontend-quality-bar
Source: https://github.com/everquint/frontend-skills/tree/main/skills/engineering/eq-frontend-quality-bar
Command: npx skills add https://github.com/everquint/frontend-skills --skill eq-frontend-quality-bar-everquint

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Lint rules catch syntax-shaped defects, but the failures that reach production — untested code, swallowed errors, bloated bundles, inaccessible UI, and leaked secrets — are invisible to linters. This Skill defines the non-lintable half of frontend quality with an explicit enforcement mechanism for every rule. ## Core Features & Use Cases - Testing strategy and coverage gates: Defines the unit/integration/E2E pyramid with Vitest, Testing Library, MSW, and Playwright, and gates merges on diff coverage (diff-cover --fail-under=90) rather than a global percentage. - Observability, performance, and accessibility rules: Requires an error reporter with route-level error boundaries, CI bundle budgets via size-limit, and a reviewer-enforced accessibility checklist backed by 31 pinned jsx_a11y rules. - Client-side security and ADRs: Mandates a single sanitizer module for dangerouslySetInnerHTML, startup env validation, dependency scanning, and architecture decision records for non-obvious choices. - Use Case: When wiring a coverage gate for a new repo, the Skill tells you to run an unfiltered lcov report through diff-cover at 90% on added lines, pin project floors once at achieved-minus-one, and keep test-first as a reviewer-enforced practice. ## Quick Start Use the eq-frontend-quality-bar skill to set up a diff-coverage gate and Playwright smoke tests for this repository.

Frequently Asked Questions about eq-frontend-quality-bar

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce test coverage on new code in CI?

Use diff-cover against an lcov report with --fail-under=90 so only the lines a change adds are gated. The run must be unfiltered and coverage.include must span the codebase, since a filtered run marks unimported modules uncovered and fails innocent branches.

What is the right ratio of unit, integration, and E2E tests?

Order them as more unit tests than integration tests, and more integration tests than E2E tests — never invert the pyramid. Integration tests with Testing Library and MSW carry most frontend value; E2E is reserved for journeys that lose money or trust when broken.

Should I mock modules or intercept HTTP in frontend tests?

Intercept HTTP at the network boundary with MSW rather than stubbing your own modules. Module mocks encode the implementation into the test, so the test keeps passing after a refactor that actually broke the app.

Does a clean axe or lint audit prove a page is accessible?

No. Automated audits only check what is decidable from static markup; keyboard reachability, focus movement into modals, live-region announcements, and contrast in both themes remain reviewer-enforced via a checklist.

When should I use mutation testing with Stryker?

Use it to detect assertion-free tests that satisfy coverage gates, especially when tests are agent-generated. Run it incrementally per PR as non-blocking and fully on a weekly schedule, pointed at pure logic like utils, reducers, and parsers rather than the whole codebase.

Why is a global coverage percentage a bad gate?

A global floor either demands near-100% of a large diff or waves hundreds of uncovered lines through a big repo, loosening as the repo grows. Diff coverage on added lines is the gate; global floors are only a backstop against wholesale coverage collapse.