frontend-quality

name	frontend-quality
description	Frontend quality checks: TypeScript type check, linting, and the JS test suite (Vitest/Jest). Activate after editing JS/TS files. Triggers: eslint, typescript, tsc, type check, lint, vitest, jest, test:js, frontend tests, frontend checks.
metadata	{"boost-tags":"frontend"}

Frontend Code Quality

Run all frontend quality checks after making changes to JavaScript or TypeScript files. The static checks (type-check, lint) and the test suite must all pass before work is complete; eye-verify is advisory for UI changes that need the app running.

When to Use This Skill

Activate this skill when:

• JS or TS files have been created or modified
• Finalizing a feature, bug fix, or refactor that touched frontend code
• The user asks to run frontend checks, ESLint, or TypeScript checks
• Before creating a PR with JS/TS changes
• Applying review feedback or rework with JS/TS changes
• A change renders UI that should be seen running, not just type-checked

Checks (Run in Order)

1. Type Checking

If the project uses TypeScript, run its type-check script with the project's package manager — it is defined in package.json (commonly a type-check script; the underlying command is usually tsc --noEmit):

npm run type-check        # or: yarn / pnpm / bun — match the project's lockfile

Must show 0 errors. Fix any type issues found. Skip this check for a plain-JavaScript project with no type-checker.

2. Linting

Run the project's lint script — it runs whatever linter the project uses (ESLint, Biome, oxlint, …):

npm run lint        # or: yarn / pnpm / bun

If the project uses ESLint, you can scope it to the changed files for speed instead of linting everything. Run the project-local ESLint via its package manager (npm exec / pnpm exec / yarn / bunx):

eslint --cache --cache-location ".cache/eslint/" <file1> <file2> ...

Must show 0 errors. Fix any linting issues found.

3. Tests

Run the project's JS/TS test suite — its script is in package.json (commonly test, or a dedicated script such as test:js; the underlying runner is Vitest, Jest, etc.):

npm test        # or: yarn / pnpm / bun — match the project's lockfile

Must show 0 failures. Fix any failing tests. When the change added or altered testable logic, add or update a test for it before the work is done — the test-writing skill covers what to write and where. During development you can scope to the changed area (e.g. vitest run <path> for Vitest, jest <path> for Jest) and run the full suite at completion. Skip only when the project has no JS test setup.

4. Eye-verify — see UI changes run in a browser (suggested)

If the change renders UI (not pure logic), type-check and lint aren't enough — runtime/visual bugs (stale state, dead toggles, broken scroll / sticky behaviour, z-index show-through, async races, untranslated keys) only show in a browser. Suggested, not blocking — it needs the app running with realistic data.

• Drive the change in a real browser. This skill ships a framework-agnostic harness — scripts/screenshot.mjs (capture + crop-to-selector with ≥15px padding), scripts/console.mjs (console/page errors + optional leak-pattern scan), and scripts/auth-capture.mjs (save a login session the other two reuse via --storage-state). See scripts/README.md; it needs Playwright in the project (npm i -D playwright && npx playwright install chromium) and points at the already running app. Use it, the project's own harness if it has one, or a Playwright MCP server. In an ephemeral clone or git worktree the app may be served on a different host/port — point the harness at this checkout and confirm it serves a real page (a hard 404 means the wrong host).
• Make the fixture sufficient first (enough data to exercise the behaviour — e.g. enough rows and columns to overflow a scrollable table), then probe DOM/console first and screenshot to back up visual claims (redact sensitive data before attaching to a PR). Verify behaviour, not just geometry.
• Put the app into the state that reveals the change before capturing. A feature that ships off by default — behind a flag, a new column, or per-record opt-in — renders nothing until enabled, so you'd verify an empty surface: run its migration, set the flag/field on a seeded record, and rebuild the frontend bundle if JS/CSS changed, first. Revert seeded test data after.
• When the change has an approved design, verify it per element, not by glancing at the whole image — keep ~15px around any single-element crop so edge misalignment stays visible. The full attribute rubric and the per-element scoring table are in this skill's references/design-verification.md.

See the javascript guideline ("Eye-verify frontend changes" and "Verify against the design, per element") for the why.

Quick Reference

Check	Command	Pass criteria
Type checking	npm run type-check (TypeScript projects)	0 errors
Linting	npm run lint (the project's lint script)	0 errors
Tests	npm test (the project's JS test script)	0 failures
Eye-verify (UI changes, suggested)	Drive it in a real browser (project harness / Playwright MCP)	renders + behaves; no console errors or untranslated keys

Important

• Type-checking is project-wide — a change in one file can surface type errors in another, so a clean run matters beyond the files you edited.
• Know what your project's type-checker covers. Some setups leave certain component file formats (e.g. framework single-file components) out of the static check — those surface errors only at build or runtime.
• Type-check and lint prove the code is well-formed, not that it behaves — run the test suite too, and cover changed logic with a test (see the test-writing skill).
• Run every applicable check before the work is considered done — all must pass.