Three delivery formats share the same 385 rules
Front-End Checklist is one rule corpus presented as a generated README, an interactive website, and an MCP service. The current README counts 385 English rules across 11 active categories, plus 11 tools on the hosted MCP server. That shared source is useful: a person browsing accessibility guidance and an agent reviewing a component can refer to the same rule, priority, explanation, remediation advice, and verification steps.
The categories cover HTML, CSS, JavaScript, performance, accessibility, SEO, security, images, testing, privacy, and internationalization. Priorities range from critical to low. The catalog is broad enough to support launch reviews and focused audits, but breadth is not project policy. A marketing page, authenticated dashboard, video player, and offline editor need different subsets. Teams should turn relevant rules into an owned checklist rather than require every item indiscriminately.
The checklist starts conversations that tools cannot finish
Many entries are mechanically testable: duplicate IDs, missing labels, invalid ARIA attributes, insecure external scripts, or absent metadata. Others require human observation and product context. The accessibility section explicitly calls for tests with NVDA, JAWS, VoiceOver, or TalkBack because automated tools cannot verify announcements, focus order, and widget behavior completely. Passing a scan can reduce obvious defects without proving that a task is usable.
The same limit applies to performance and security. A rule can tell reviewers to virtualize long lists or audit dependencies, but it cannot decide the list size at which virtualization pays for its complexity or whether a reported advisory is reachable. Use each finding as a question tied to evidence. Record the affected page, user task, reproduction, and verification method before converting an agent response into backlog work.
What happened when we ran it
Our sandbox cloned commit 30756a7 and installed 1,362 pnpm packages in 68 seconds. The dependency tree occupied 1,421 MB, far larger than the 11.5 MB checkout. The build succeeded in 105 seconds. This is a substantial contributor environment for a checklist, likely because the repository includes the website, content generation, MCP package, skills, and shared tooling in one workspace.
Tests completed in 29 seconds. Jest reported 20 passed and 0 failed out of 20. The repository had 4 CI workflow files and monorepo workspaces, though our scan found no tests directory. That does not contradict the passing command; tests can live elsewhere or follow another naming scheme. It does mean contributors should use the documented workspace commands instead of inferring project health from root folders.
Our run measured repository installation, build, and tests. It did not ask the hosted MCP to audit a public page or grade the factual quality of all 385 rules. Nor did it compare findings with Lighthouse, axe-core, browser accessibility trees, or a screen reader session. Those are separate evaluations. The 20 passing tests support the software path, while individual guidance still needs source review and browser proof.
MCP makes the catalog queryable and sends work to a server
The MCP interface can review pasted code, audit a public HTTPS URL, fetch one rule, search by keyword or priority, and return a workflow. The README recommends naming the Front-End Checklist server in prompts because some clients discover tools lazily. There is also a local stdio implementation in packages/mcp, giving teams a path to inspect or host the integration themselves.
A hosted audit changes the data boundary. Code pasted into a tool call or a public URL sent for review reaches the MCP service, so teams should decide what is allowed before connecting it to an agent with repository access. Public pages are lower risk than private component source. For sensitive work, use the README, install the focused skills, or inspect and run the local server under your own logging and network rules.
License packaging needs correction before reuse
The repository describes itself as open source, and the README footer links LICENSE with the label MIT. GitHub's repository response returned no detected license, and the root contents we fetched did not include a LICENSE file. That mismatch may be an accidental packaging omission, but a README label is a weak substitute for an actual license text attached to the source. Organizations redistributing code or generated skills should resolve it with the maintainer first.
Release v2.0 was published on May 30, 2026. GitHub showed 73,892 stars, 7 combined issues and pull requests, and a last push on August 14, 2026. The small open count includes a report that website sign-in redirects to a GitHub 404. Account access is not required to read the README, so this affects the web workflow rather than the core catalog.
Use a focused slice as a release gate
The best adoption path is one category or one risky feature. A team shipping a modal can select dialog naming, focus trapping, keyboard dismissal, background inertness, reduced motion, and mobile layout, then add automated checks where possible and a short manual script for the rest. An agent can retrieve the rules, but a named reviewer should own the evidence and any exception.
Front-End Checklist is valuable because it turns forgotten details into visible questions. Our 105-second build and 20 passing tests show the monorepo is functioning, while its 1,421 MB install argues against cloning it merely to read the rules. Browse first. Connect MCP when searchable agent access earns its data and operational cost, and keep actual browser, assistive-technology, performance, and security evidence as the release decision.