frontendchecklist

# Front-End Checklist CLI `frontendchecklist` checks frontend code against the Front-End Checklist rules. It works offline, prints JSON when its output is piped (which is how you will usually call it), and uses exit codes you can branch on. Run it with `npx -y @frontendchecklist/cli <command>` if `frontendchecklist` is not installed. ## When to use it - After writing or editing frontend files: `frontendchecklist review <paths>`. - Before committing: `git diff --cached | frontendchecklist review -`. - When the user asks to audit a deployed page: `frontendchecklist audit https://...`. - When you need the authoritative guidance for a topic: `frontendchecklist search <topic>`, then `frontendchecklist rule <slug>`. - For a structured pass (launch, accessibility, SEO, performance): `frontendchecklist checklists`, then `frontendchecklist checklist <slug>`. ## Commands | Command | Purpose | | --- | --- | | `review <paths...\|->` | Static review of files, directories (walked; vendor dirs skipped), or stdin | | `audit <https-url>` | Fetch a public page and review its HTML | | `search [query] [--focus a,b] [-n 10]` | Find rules by keyword, technology, or category | | `rule <slug>` | Why a rule matters, how to check it, how to fix it | | `checklists` / `checklist <slug>` | Curated checklists and their rules | | `categories` | Categories with rule counts | | `schema` | Full command reference as JSON | Useful flags: `--focus accessibility,seo`, `--min-priority high`, `--fail-on high`. ## Reading results - `review` and `audit` return `{ findings: [{ target, rule, title, priority, issue, fix? }], failing }`. - Exit code `0`: fine. `1`: findings at or above `--fail-on`. `2`: bad input or runtime error, with `{ "error": "..." }` on stdout. - Findings are conservative static heuristics. "No findings" means nothing provable was found, not that the code is clean: follow up with `search`/`rule` for areas the heuristics cannot see (rendered contrast, focus order, real performance). ## Workflow 1. `frontendchecklist review <changed files> --min-priority medium` 2. For each finding, run `frontendchecklist rule <rule>` and apply its fix guidance. 3. Re-run the review until no critical/high findings remain (`--fail-on high` exits 0). 4. Mention any remaining medium/low findings to the user instead of silently ignoring them.