mcpField
F
frontend-review-ci

frontend-review-ci

github.com/mizchiCloud & DevOps41647 installsUpdated 1w ago
Repository

About frontend-review-ci

frontend-review-ci is a skill for analyzing and optimizing GitHub Actions CI in frontend projects. It examines run timings and workflow structure, then produces prioritized recommendations and a draft pull request description without changing workflows or opening a PR.

Key features

  1. 01Audit CI run and step timings
  2. 02Inspect workflow caching and concurrency
  3. 03Identify serial jobs and sharding opportunities
  4. 04Recommend targeted YAML changes
  5. 05Draft a pull request description

Use cases

  1. 01Find bottlenecks in slow frontend CI
  2. 02Review cache coverage across workflows
  3. 03Plan parallelization for lint and typecheck
  4. 04Prepare a focused CI optimization proposal

Install

Copy the command and run it in a terminal.

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

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

Bundled filesREADME.md

Details

From the project README

Frontend Review — CI Optimization

You are optimizing GitHub Actions CI for a frontend project. The target is median ≤ 10 minutes, max ≤ 15 minutes. Faster CI means developers trust it; trust is what makes the ratchet work.

Procedure

  1. Run scripts/audit-ci.sh --repo <client-repo>.
  2. Read <client-repo>/.frontend-review/report/latest/raw/ci.json.
  3. For the slowest runs, dig into step-level timing:
    gh run view <run-id> --log | grep -E '^\d{4}-' | head -200
    
  4. Inventory current workflows under .github/workflows/ and note:
    • Does every job (lint, build, test, coverage, etc.) use a pnpm/npm store cache? A common miss: test.yml has cache but lint.yml and pages.yml do not.
    • Does actions/setup-node use cache: pnpm, or is there a manual actions/cache block for the pnpm store? Either is fine; the key must include hashFiles('**/pnpm-lock.yaml').
    • Does actions/cache cache the Playwright browser store (~/.cache/ms-playwright)?
    • Is there a concurrency: block?
    • Are vitest / playwright sharded?
    • Are jobs serialized via needs: unnecessarily?
    • Are lint and typecheck in the same serial job? They have no dependency on each other and should be separate parallel jobs.

Output

Write <client-repo>/.frontend-review/report/latest/md/ci-analysis.md with:

  • Current median / max duration
  • Slowest 3 steps in a representative failing + passing run
  • Concrete recommendations, each mapped to a line in a YAML patch (not full rewrite)
  • Estimated wins per recommendation

Then produce a draft PR description that the user can copy into gh pr create, naming the branch ci/optimize.

Development Iteration Timing Targets

Use these as reference thresholds when diagnosing CI slowness. Any stage exceeding 2× its target warrants a dedicated bottleneck issue.

StageTargetHow to measure
HMR (edit → screen)< 500 msVite --debug output
Unit test — single file< 1 svitest / jest output
test:ci — full suite< 1 minCI step duration
typecheck< 30 sCI step duration
lint< 30 sCI step duration
E2E — one shard< 50 sCI step duration
PR CI total (parallel)< 5 minGitHub Actions wall-clock
install (cache hit)< 15 sCI step duration
build< 30 sCI step duration

The PR CI total target is the critical gate. CI slower than 5 minutes is routinely bypassed by developers.

Bottleneck Identification Procedure

  1. Pull step-level timing from the slowest recent run:
    gh run view <run-id> --log | grep -E '^\d{4}-' | head -200
    
  2. Identify the single slowest job in the DAG — only the longest path in a parallel graph determines wall-clock time.
  3. Within that job, identify the slowest step.
  4. Propose one change per PR — bundling multiple optimisations makes regression attribution impossible.
  5. Measure wall-clock before/after on the same branch to verify the win.

Typical Optimisation Patterns

AreaCommon fix
installpnpm / npm store cache key, --frozen-lockfile, narrow onlyBuiltDependencies. Audit every workflow file — partial cache (only some jobs cached) is the most common oversight; install without cache is ~20-25 s, with cache hit it drops to ~2-3 s
lint + typecheckSplit into two parallel jobs (no mutual dependency). On a project with ~170 TS files, this alone cuts the lint-job wall-clock in half
typecheckProject References split, skipLibCheck: true, resolve circular type imports
lintlint-staged for PR (changed files only), enable linter's own incremental cache
vitestisolate: false, tune --pool thread count, exclude test fixtures from coverage
PlaywrightTune shard count to test volume, page.route() to mock external APIs, move flaky tests to daily-only tag
Runner sizeLarger runner (4-core+) only as a last resort after exhausting the above

Boundaries

  • Do NOT actually create the PR or push the branch — just draft the description.
  • Do NOT modify workflow YAML in the client repo; the user does that after reviewing your proposal.

Reference

  • Checklist: checklist/09-ci-optimization.md
  • Phase: phase/week-1-ci-baseline.md
  • Templates: templates/github-actions/ci.yml, templates/github-actions/e2e.yml

Comments

Markdown supported