mcpField
F
frontend-review-hygiene

frontend-review-hygiene

github.com/mizchiTesting & quality41651 installsUpdated 1w ago
Repository

About frontend-review-hygiene

A skill for reviewing baseline hygiene in frontend repositories, covering TypeScript, linting, unused code, and duplication. It produces KPI comparisons and grouped remediation suggestions without changing source files.

Key features

  1. 01Audit types, lint, and similarity
  2. 02Compare results with a KPI baseline
  3. 03Report hygiene metrics and changes
  4. 04Group remediation work by impact
  5. 05Check lint and formatting role boundaries

Use cases

  1. 01Establish a frontend quality baseline
  2. 02Track weekly hygiene regressions and improvements
  3. 03Prepare grouped cleanup work for pull requests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mizchi/skills --skill frontend-review-hygiene

After installing, type/frontend-review-hygienein Claude Code to confirm it loaded.

Bundled filesREADME.md

Details

From the project README

Frontend Review — Hygiene

You are assessing the baseline code quality hygiene of a frontend project: types, lint, dead code, and duplication. These are the KPIs that will be ratcheted each week.

Procedure

  1. In parallel, run:
    • scripts/audit-typescript.sh --repo <client-repo>
    • scripts/audit-lint.sh --repo <client-repo>
    • scripts/audit-similarity.sh --repo <client-repo>
  2. Read each raw/*.json.
  3. Compare with the previous run if <client-repo>/.frontend-review/kpi/baseline.json exists.

Output

Write <client-repo>/.frontend-review/report/latest/md/hygiene-summary.md with:

  • KPI table covering: any count, @ts-ignore count, lint errors/warnings, knip unused files/exports/deps, similarity duplicate pairs
  • Delta vs baseline (mark regressions in bold; improvements with ✅)
  • Remediation batches grouped by impact — which items make sense to fix in one PR
  • Do NOT include per-file findings (those stay in the raw JSON). The report is for decisions, not code review.

If the client has no baseline yet, create one: copy the current JSON to <client-repo>/.frontend-review/kpi/baseline.json and state this in the report.

Toolchain Role Separation

When assessing the linting / formatting stack, check for clear role boundaries:

ToolIntended role
TypeScriptType correctness only
ESLint / Biome / oxlintAST-level bug patterns, import rules
Prettier / Biome / oxfmtFormatting only — no overlap with linting
ast-grep / custom rulesProject-specific structural rules
vitest / jestBehaviour

Overlapping responsibilities (e.g., ESLint also handling formatting) cause conflicts and slower CI. Flag and recommend separation.

Auto-generated files (lock files, generated schemas, tool artefacts) must be excluded from formatting runs. Repeatedly formatting and reverting a generated file is a signal they are missing from .prettierignore / .biomeignore / equivalent.

Boundaries

  • Do NOT assess dependency freshness or CVEs — that's frontend-review-deps.
  • Do NOT propose code-level fixes. That's for the 5 perspective skills.
  • Do NOT touch source files in the client repo.
  • Do NOT run audit-security.sh — that's the security skill's job.

Reference

  • Checklist: 03-typescript.md, 04-lint-format.md, 05-deadcode-knip.md, 06-similarity.md, 13-kpi-tracking.md
  • Related: frontend-review-deps (dependency health), frontend-review-security (CVEs + auth + env)
  • Phase: week-1-ci-baseline.md, week-4-ai-review.md

Comments

Markdown supported