Frontend Checklist Global

Name: Frontend Checklist Global
Author: thedaviddias

thedaviddias/frontendchecklist

9 installs
73.4k repo stars
Updated June 18, 2026
thedaviddias/frontendchecklist

Helps with frontend development tasks.

About

frontend-checklist-global is a Claude Code skill for frontend development. It helps solo builders move faster with AI-assisted coding.

frontend-checklist-global
Frontend Development
AI-coding skill

Frontend Checklist Global by the numbers

9 all-time installs (skills.sh)
Ranked #1,713 of 2,245 Frontend Development skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/thedaviddias/frontendchecklist --skill frontend-checklist-global

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/thedaviddias/frontendchecklist/frontend-checklist-global.svg)](https://skillselion.com/skills/thedaviddias/frontendchecklist/frontend-checklist-global)

Installs	9
repo stars	★ 73.4k
Last updated	June 18, 2026
Repository	thedaviddias/frontendchecklist ↗

What it does

Helps with frontend development tasks.

Files

SKILL.mdMarkdownGitHub ↗

Front-End Checklist Global Audit

This skill connects one entry point to all 385 Front-End Checklist rules. Use MCP retrieval instead of trying to recall rules from memory.

Workflow

1. Start with review_code for pasted code, file contents, or focused code review. 2. Use audit_url for a public page when you need rendered HTML audited quickly. 3. Narrow or expand scope with search_rules, list_categories, get_workflow, or get_quick_reference. 4. For each issue, use get_rule, fix_rule, or explain_rule to give exact remediation. 5. If a checklist is a better fit than ad hoc search, use get_checklist_rules.

Audit Stance

Be conservative. Prefer fewer, stronger findings over speculative breadth.
Only report an issue when the code or markup shown supports it directly.
In small component or route audits, prefer the strongest 1-2 supported findings over listing every possible enhancement.
Do not infer business intent from a snippet alone. Example: do not assume a field is required unless the code or surrounding copy makes that explicit.
Do not treat alt="" as an issue by default; empty alt can be correct for decorative images.
When an image is explicitly decorative, prefer zero findings unless the snippet shows a concrete problem rather than a hypothetical optimization.
If you see an isolated decorative image like <img ... alt="" aria-hidden="true">, treat it as a zero-issue pattern unless the snippet also shows real evidence of layout instability.
Do not raise low-confidence preference tweaks as findings when the snippet is otherwise sound. Prefer silence over weak nitpicks.
Do not treat autocomplete="off" as a defect by itself unless the snippet shows a stronger user-harm or security reason to flag it.
In link-preview cards, decorative preview images and favicons may be safe when nearby visible text already names the destination.
Do not treat React or JSX fragments as full HTML documents unless the snippet includes real document context like <html>, <head>, or <body>.
When reviewing Next.js or metadata-driven page files, consider metadata, viewport, and generateMetadata APIs before claiming head-tag omissions.

Coverage Checklist

Forms: check labels, accessible button names, explicit button types, autocomplete hints, password-field autocomplete, and validation semantics that are explicit in the code.
Images: check width/height, loading, srcset/sizes, and whether image semantics are clearly meaningful or decorative. Do not assume tiny SVG logos or clearly decorative assets must be lazy-loaded, and do not demand explicit dimensions for tiny ornamental dividers unless the snippet shows a real layout-shift risk. If an image is both decorative and hidden from assistive tech, bias strongly toward no finding.
Metadata: check title placement, canonical-url behavior, meta descriptions, Open Graph coverage, and structured data only when the file is responsible for metadata.
Motion: check expensive animated properties, prefer transform/opacity, and require prefers-reduced-motion handling for persistent motion.
Motion: when counters or visual widgets animate every frame, assess both reduced-motion support and whether the animation strategy adds unnecessary main-thread work.
Security: check target="_blank" links for noopener noreferrer, insecure form actions, password input best practices, and blocking third-party scripts.
Structure: check duplicate ids, list semantics, and table headers conservatively. For simple tables, column-header associations are stronger findings than speculative row-header or outer-layout landmark issues.
Structure: when a visible heading already introduces a simple table, treat missing captions as a lower-confidence improvement than missing header associations.

Rule-Derived Highlights

Set explicit width and height on images

Reserve findings for meaningful content images; decorative micro-SVGs or ornament-only assets are low-priority exceptions when CSS already reserves stable space
Example low-risk exception: <img src="/divider.svg" alt="" aria-hidden="true"> should not be flagged on its own without evidence of visible layout shift
Always set width and height attributes on <img> matching the image's intrinsic dimensions
Pair with height: auto in CSS to keep the image fluid while preserving the aspect ratio
Missing dimensions are the leading cause of Cumulative Layout Shift (CLS) from images

Hide decorative elements from assistive technology

Use alt='' (empty) for decorative images—not alt='image' or missing alt
Add aria-hidden='true' to decorative SVGs and icons
Use CSS background-image for purely decorative visuals
Role='presentation' removes semantic meaning from elements
Do not automatically raise performance findings on decorative micro-assets unless the snippet shows real layout instability

Use transform and opacity for animations

Only transform and opacity can be composited on the GPU without triggering layout
Use will-change: transform sparingly to promote an element to its own compositor layer
Prefer CSS transitions and animations over JavaScript animation libraries for simple effects
Respect prefers-reduced-motion to disable animations for users who need it

Respect reduced motion preferences

Use prefers-reduced-motion media query to disable non-essential animations
Never flash content more than 3 times per second (seizure risk)
Replace motion with opacity/color transitions when reduced motion is enabled
Provide user controls to pause or disable animations

Use semantic table markup for screen readers

Use <th> elements for headers with scope='col' or scope='row'
Add <caption> to describe the table's purpose
Never use tables for layout—use CSS Grid or Flexbox instead
Use id/headers for complex tables with merged cells
For simple tables with a clear adjacent section heading, missing scope is often a stronger finding than missing <caption>

Define proper table headers

Use <th> for all table headers, not <td>
Apply scope="col" or scope="row" to clarify header relationship
Ensure every data cell is associated with at least one header
In simple tables, prefer fixing header associations before escalating to caption-level recommendations
Missing scope="col" on a straightforward header row is often the clearest first fix

Minimize costly DOM read/write operations

Never interleave DOM reads (offsetHeight, getBoundingClientRect) with DOM writes (style changes)
Batch all reads first, then all writes
Use requestAnimationFrame for visual updates
Use DocumentFragment or innerHTML for bulk DOM insertion
Avoid per-frame React state updates across many visible components when a simpler CSS or reduced-frequency approach would work

Validate forms accessibly

Associate error messages with fields using aria-describedby
Use aria-invalid to indicate validation state
Mark required fields programmatically with required or aria-required
Provide inline error messages near the field
Don't rely solely on color to indicate errors

Secure password input fields

Use type='password' with correct autocomplete attribute
Provide accessible show/hide toggle for password visibility
Show password strength indicator with requirements
Never store or transmit passwords in plain text
Support password managers with proper input names

Provide visible custom focus indicators

Never use outline: none or outline: 0 without a visible :focus-visible replacement
Use :focus-visible instead of :focus to show indicators only during keyboard navigation
Focus indicators must have 3:1 contrast ratio against adjacent colors (WCAG 2.2)
Provide at least 2px solid outline with an offset for a high-quality focus ring
If a focus ring is drawn with pseudo-elements, verify it is anchored to the correct positioned element and not clipped by overflow: hidden

Known Safe Patterns

Decorative Divider

Safe example: <img src="/divider.svg" alt="" aria-hidden="true">
Treat this as a safe decorative pattern by default. Do not flag alt text or missing dimensions unless the snippet also shows a real layout-shift risk.

Client-Handled React Form

Safe example: <form onSubmit={event => event.preventDefault()}><label htmlFor="q">Search</label><input id="q" type="search" /></form>
Do not require method or action when client-side submit handling is explicit and the form controls are otherwise accessible.

Next Metadata API

Safe example: export async function generateMetadata() { return { title: 'Docs', description: 'Reference' } }
Do not infer missing canonical-url, meta description, or Open Graph tags just because literal <head> markup is absent from the component file.

Preview Card Images

Safe example: <img src={resource.image} alt="" className="object-cover" /><img src={favicon} alt="" width={20} height={20} />
In link-preview or resource-card UIs, decorative preview/favicons can legitimately use empty alt when adjacent text already provides the destination name. Do not invent responsive-image or layout-shift defects for tiny favicon assets without stronger evidence.

Aspect-Ratio Media Wrapper

Safe example: <div className="aspect-2/1 overflow-hidden"><img className="object-cover w-full h-full" ... /></div>
When a wrapper already reserves media space with a stable aspect ratio, do not automatically raise a missing dimensions finding for the child preview image.

Pseudo-Element Focus Ring

Safe example: focus-visible:outline-none focus-visible:after:ring-2 after:absolute after:inset-0
If focus styling depends on a pseudo-element, verify the ring is anchored to the correct positioned element. A removed native outline is only safe when the replacement ring is clearly reliable.

Per-Frame React Counter Animation

Safe example: requestAnimationFrame(animate); setCount(Math.floor(eased * target))
Repeated requestAnimationFrame state updates across multiple components are a concrete performance concern when shown directly in the code.

Simple Data Table Headers

Safe example: <thead><tr><th>Priority</th><th>Rule</th><th>Title</th></tr></thead>
For simple data tables, prefer conservative column-header findings before speculating about row headers or outer-layout landmarks.

Adjacent Heading + Table

Safe example: <h2>Issues</h2><table><thead>...</thead><tbody>...</tbody></table>
A nearby visible section heading may already provide table context. Prefer scope/header association findings before requiring a caption unless the table purpose is ambiguous.

Conflict Resolution

If decorative-image guidance and dimensions guidance conflict, decorative guidance wins unless the snippet shows visible layout instability.
Example zero-issue pattern: <img src="/divider.svg" alt="" aria-hidden="true"> in an isolated component should not be flagged for alt text or dimensions unless the snippet also shows real layout-shift evidence.
If a form is clearly handled client-side with onSubmit, do not require traditional server-post method or action attributes.
If a file uses Next.js metadata APIs, do not infer missing head tags from the absence of literal <meta> or canonical-url markup.

Coverage

accessibility: 89 rules (9 critical, 25 high)
css: 31 rules (10 high)
html: 34 rules (3 critical, 12 high)
i18n: 5 rules
images: 25 rules (1 critical, 15 high)
javascript: 26 rules (1 critical, 12 high)
performance: 42 rules (1 critical, 21 high)
privacy: 5 rules (2 high)
security: 22 rules (4 critical, 10 high)
seo: 93 rules (19 high)
testing: 13 rules (7 high)

Evaluation Standard

Prefer findings tied to exact files, routes, selectors, or code snippets.
Prioritize critical and high issues first.
Explain uncertainty instead of overstating when the snippet does not show enough context.
Avoid generic advice when the MCP tools can retrieve a rule or fix prompt.
When no issue is found automatically, use search_rules to broaden review coverage before concluding clean.

---

See references/categories.md for category coverage and tool routing.

MCP docs: https://frontendchecklist.io/en/mcp

Front-End Checklist Global Skill Reference

This aggregate skill routes to the Front-End Checklist MCP tools across 385 rules.

Tool Routing

Goal	Preferred tool
Review pasted code or a single file	`review_code`
Audit a public page	`audit_url`
Find relevant rules by topic	`search_rules`
Browse available categories	`list_categories`
Get the full content for one rule	`get_rule`
Get remediation guidance	`fix_rule`
Explain impact to the user	`explain_rule`
Pull a curated checklist at once	`get_checklist_rules`
Start from a workflow or quick checklist	`get_workflow`, `get_quick_reference`

Frontend Review Guardrails

Do not infer missing metadata from a component fragment that is not responsible for document head output.
Do not infer required fields, password policies, or decorative-image intent unless the code makes the intent explicit.
Favor exact evidence from the snippet over broad style advice.
When the snippet is a partial component, focus on what the component itself controls.

Rule-Derived Highlights

Set explicit width and height on images

Reserve findings for meaningful content images; decorative micro-SVGs or ornament-only assets are low-priority exceptions when CSS already reserves stable space Example low-risk exception: <img src="/divider.svg" alt="" aria-hidden="true"> should not be flagged on its own without evidence of visible layout shift Always set width and height attributes on <img> matching the image's intrinsic dimensions Pair with height: auto in CSS to keep the image fluid while preserving the aspect ratio Missing dimensions are the leading cause of Cumulative Layout Shift (CLS) from images

Hide decorative elements from assistive technology

Use alt='' (empty) for decorative images—not alt='image' or missing alt Add aria-hidden='true' to decorative SVGs and icons Use CSS background-image for purely decorative visuals Role='presentation' removes semantic meaning from elements Do not automatically raise performance findings on decorative micro-assets unless the snippet shows real layout instability

Use transform and opacity for animations

Only transform and opacity can be composited on the GPU without triggering layout Use will-change: transform sparingly to promote an element to its own compositor layer Prefer CSS transitions and animations over JavaScript animation libraries for simple effects Respect prefers-reduced-motion to disable animations for users who need it

Respect reduced motion preferences

Use prefers-reduced-motion media query to disable non-essential animations Never flash content more than 3 times per second (seizure risk) Replace motion with opacity/color transitions when reduced motion is enabled Provide user controls to pause or disable animations

Use semantic table markup for screen readers

Use <th> elements for headers with scope='col' or scope='row' Add <caption> to describe the table's purpose Never use tables for layout—use CSS Grid or Flexbox instead Use id/headers for complex tables with merged cells For simple tables with a clear adjacent section heading, missing scope is often a stronger finding than missing <caption>

Define proper table headers

Use <th> for all table headers, not <td> Apply scope="col" or scope="row" to clarify header relationship Ensure every data cell is associated with at least one header In simple tables, prefer fixing header associations before escalating to caption-level recommendations Missing scope="col" on a straightforward header row is often the clearest first fix

Minimize costly DOM read/write operations

Never interleave DOM reads (offsetHeight, getBoundingClientRect) with DOM writes (style changes) Batch all reads first, then all writes Use requestAnimationFrame for visual updates Use DocumentFragment or innerHTML for bulk DOM insertion Avoid per-frame React state updates across many visible components when a simpler CSS or reduced-frequency approach would work

Validate forms accessibly

Associate error messages with fields using aria-describedby Use aria-invalid to indicate validation state Mark required fields programmatically with required or aria-required Provide inline error messages near the field Don't rely solely on color to indicate errors

Secure password input fields

Use type='password' with correct autocomplete attribute Provide accessible show/hide toggle for password visibility Show password strength indicator with requirements Never store or transmit passwords in plain text Support password managers with proper input names

Provide visible custom focus indicators

Never use outline: none or outline: 0 without a visible :focus-visible replacement Use :focus-visible instead of :focus to show indicators only during keyboard navigation Focus indicators must have 3:1 contrast ratio against adjacent colors (WCAG 2.2) Provide at least 2px solid outline with an offset for a high-quality focus ring If a focus ring is drawn with pseudo-elements, verify it is anchored to the correct positioned element and not clipped by overflow: hidden

Known Safe Patterns

Decorative Divider

Safe example: <img src="/divider.svg" alt="" aria-hidden="true"> Treat this as a safe decorative pattern by default. Do not flag alt text or missing dimensions unless the snippet also shows a real layout-shift risk.

Client-Handled React Form

Safe example: <form onSubmit={event => event.preventDefault()}><label htmlFor="q">Search</label><input id="q" type="search" /></form> Do not require method or action when client-side submit handling is explicit and the form controls are otherwise accessible.

Next Metadata API

Safe example: export async function generateMetadata() { return { title: 'Docs', description: 'Reference' } } Do not infer missing canonical-url, meta description, or Open Graph tags just because literal <head> markup is absent from the component file.

Preview Card Images

Safe example: <img src={resource.image} alt="" className="object-cover" /><img src={favicon} alt="" width={20} height={20} /> In link-preview or resource-card UIs, decorative preview/favicons can legitimately use empty alt when adjacent text already provides the destination name. Do not invent responsive-image or layout-shift defects for tiny favicon assets without stronger evidence.

Aspect-Ratio Media Wrapper

Safe example: <div className="aspect-2/1 overflow-hidden"><img className="object-cover w-full h-full" ... /></div> When a wrapper already reserves media space with a stable aspect ratio, do not automatically raise a missing dimensions finding for the child preview image.

Pseudo-Element Focus Ring

Safe example: focus-visible:outline-none focus-visible:after:ring-2 after:absolute after:inset-0 If focus styling depends on a pseudo-element, verify the ring is anchored to the correct positioned element. A removed native outline is only safe when the replacement ring is clearly reliable.

Per-Frame React Counter Animation

Safe example: requestAnimationFrame(animate); setCount(Math.floor(eased * target)) Repeated requestAnimationFrame state updates across multiple components are a concrete performance concern when shown directly in the code.

Simple Data Table Headers

Safe example: <thead><tr><th>Priority</th><th>Rule</th><th>Title</th></tr></thead> For simple data tables, prefer conservative column-header findings before speculating about row headers or outer-layout landmarks.

Adjacent Heading + Table

Safe example: <h2>Issues</h2><table><thead>...</thead><tbody>...</tbody></table> A nearby visible section heading may already provide table context. Prefer scope/header association findings before requiring a caption unless the table purpose is ambiguous.