Front-End Checklist: 385 Rules, an MCP Server, and a README You Can Actually Read

What Front-End Checklist actually is now

Most people who know this project remember a long markdown file with checkboxes. That file still exists, but the README describes something broader: an open-source front-end quality system that turns best practices into a review workflow available in three places. You can browse it on the web at frontendchecklist.io, drive it through MCP-compatible tools, or read it directly in the README.

The README states the corpus contains 385 English rules across 11 active categories, and that the hosted server exposes 11 MCP tools. Rule pages carry explanations, remediation guidance, and verification steps. That is a different product shape from a static list. A static list tells you what to check. A rule page with remediation and verification steps tells you what to check, what good looks like, and how to confirm you got there.

The intended audience is stated plainly: humans and AI agents. The README also points at a companion project, UX Patterns for Devs, for choosing which interface to build before you use this checklist to verify how well it was built. That split is worth taking seriously. This project reviews implementation quality; it does not help you decide whether a modal or a drawer is the right control.

Where the 385 rules are distributed, and why that matters

The category navigator in the README gives counts per category. Accessibility has 95 rules and SEO has 94. Performance has 43, CSS 32, JavaScript 26, HTML 25, Images 25, Security 22, Testing 13, Privacy 5, and Internationalization 5.

Read those numbers as a statement of priorities. Accessibility and SEO together account for roughly half the corpus. If your team's actual risk sits in security or i18n, this checklist will not carry you: 22 security rules and 5 internationalization rules are a starting point, not coverage. The README does not explain why the distribution is skewed, and it does not claim the counts are balanced. They are what they are.

Each rule also carries a priority level. Critical means site-breaking, compliance-sensitive, or security-sensitive issues that should be fixed first. High means major impact on user experience, accessibility, performance, or discoverability. Medium is described as strong best practices for normal frontend quality review, and Low as useful but situational. The priority legend is the most practical part of the whole system, because it gives you a defensible order of operations when you cannot fix everything in one pass.

Installing the skills and running a first review

There are two entry paths, and they serve different situations. The skills path installs reusable audit workflows into tools that support them. The README gives the install command directly:

npx skills add frontendchecklist/skills
npx skills add frontendchecklist/skills --skill https

The first command adds the skill set. The second adds one focused skill, in this case `https`, for security review on a single concern. The README points at two entry points in the repository: a global audit skill at `skills/frontend-checklist-global/SKILL.md`, and the focused example at `skills/https/SKILL.md`. If you want to inspect what you are installing before you install it, those files are where to look.

The MCP path is for agent workflows. The public endpoint is mcp.frontendchecklist.io, and the README also documents a local stdio server at `packages/mcp/src/cli.ts` for editor integration. The README's own tip for a first run is specific: point an MCP-capable agent at a real component, page, or public URL, and name the Front-End Checklist MCP explicitly in the prompt, because some clients discover installed MCP tools lazily. A first prompt in that shape looks like this:

Use the Front-End Checklist MCP to review this React component and report the highest-confidence findings first.

The README lists `review_code` as the tool to reach for first with pasted HTML, CSS, JavaScript, React, or Next.js code, and `search_rules` before making accessibility, performance, SEO, security, or image recommendations. For a live page, `audit_url` handles public `https://` URLs. What you should see is a set of findings tied to specific rules, not a pass or fail verdict.

The MCP tool surface, and the gap it leaves

Eleven tools is a small, legible surface. The README names `review_code`, `search_rules`, `get_workflow`, `get_checklist_rules`, `audit_url`, and a tool for fetching a specific rule with its remediation guidance. There is also something for searching by keyword, category, or priority. The README's agent guidance maps tools to intent: code review first, rule search before recommendations, workflow or checklist retrieval for launch, accessibility, SEO, security, and performance audits, and URL auditing for public pages.

That mapping is the useful part, because it tells an agent when not to guess. An agent asked to improve a page's accessibility without calling `search_rules` will produce plausible advice from its training data rather than from this corpus. The README is explicit that `search_rules` should come before recommendations.

The gap is enforcement. Nothing in the README describes a CI integration, a failing exit code, or a way to block a merge on a Critical rule. The tools return findings for a human or agent to act on. If your quality gate lives in a pipeline, this checklist feeds it conversationally rather than mechanically. That is a real limitation, not a packaging detail, and teams used to ESLint-style blocking will feel the difference immediately.

Working on the corpus itself

The repository is a pnpm and Turbo monorepo with `apps/*`, `packages/*`, and `configs/*` workspaces. The README's contribution section gives the local commands:

pnpm install
pnpm dev
pnpm validate:rule-structure
pnpm score:rules
pnpm generate:skills
pnpm generate:readme

`pnpm validate:rule-structure` checks that rules conform to the expected shape, and `pnpm score:rules` scores the corpus. The two generate commands rebuild derived artifacts: the skills and the README. The README notes that the checklist block is generated from 385 English rules and maintained by `pnpm generate:readme`, which means hand edits to that block will be overwritten.

There are more scripts in `package.json` than the README mentions, including `pnpm generate:exceptions-hints`, `pnpm generate:support-notes`, `pnpm generate:verification-split`, and `pnpm backfill:sources`. The README does not document what those produce. If you intend to contribute rules, budget time to read the scripts, because the README's contribution section is a starting point rather than a complete guide to the pipeline. The repository also carries `SPEC.md`, `AGENTS.md`, and `CLAUDE.md` at the top level, and those are the likely places to look for the conventions the README omits.

How it compares to automated auditing tools

The obvious alternative is an automated auditor such as Lighthouse, which runs against a URL and returns numeric scores for performance, accessibility, SEO, and best practices. The difference in approach is the unit of output. Lighthouse produces a score and a list of failing audits derived from what a headless browser can measure. Front-End Checklist produces rules with explanations, remediation guidance, and verification steps, and its `audit_url` tool is one of eleven, not the whole product.

That distinction decides which one you want. Lighthouse can tell you that a contrast ratio fails. It cannot tell you that a canonical URL rule exists, why it matters, and what the fix looks like with code examples, which is the kind of question the README's example prompts are built around. Conversely, Front-End Checklist will not run on every commit and hand you a number to track over time; the README does not describe that capability.

There is also a difference in scope. Lighthouse measures what a browser can observe. A large share of this corpus, including the 13 testing rules and much of the HTML and JavaScript categories, concerns things that never surface in a rendered page audit. The two tools answer different questions, and the README positions this project alongside a pattern-selection resource rather than as a replacement for measurement tooling.

Maintenance, licensing, and what to check before you commit

The repository is not archived. The last push was on 2026-05-30, which is also the date of the v2.0 release. The previous release, v1.0, dates to 2018-07-17, so the gap between major versions is measured in years rather than months. Treat the corpus as something that moves in large, infrequent steps rather than continuously.

That cadence has a practical consequence for the rule content. Web platform guidance shifts between releases, and a corpus that shipped in May 2026 reflects what was current then. The README does not state a review schedule for individual rules, so there is no documented way to tell how recently a given rule was checked against current browser behaviour.

The repository does not state a licence, and the README does not name one. The project has an Open Collective page linked at the top of the README, which indicates a funding model, but funding is not licensing. Before you copy rule text into internal documentation or redistribute the corpus, find the licence file in the repository or ask the maintainers. That is a factual gap, not a legal opinion, and it is the kind of gap that is cheap to close and expensive to discover later.

Editorial conclusion

Adopt Front-End Checklist if you want a shared vocabulary for front-end review and you already have an MCP-capable agent or a willingness to work through rule pages by hand. Skip it if you expect automated CI enforcement: the MCP tools return findings, not exit codes, and the repository does not document a pipeline gate. Before committing, verify three things: that the hosted endpoint at mcp.frontendchecklist.io is acceptable for the code you would paste into it, that the rule counts in the category navigator match what you need (accessibility and SEO carry 95 and 94 rules, security only 22), and that you have a way to record which rules your team has deliberately waived. The corpus is the deliverable; the enforcement is yours to build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes