agentsclimarketplace

Frontend review ci

Skill krkrkrr/skills/skills/frontend/frontend-review-ci

Use when CI is slow (>10 min), flaky, or the user asks to optimize GitHub Actions for a frontend project. Analyzes `gh run list` history, identifies bottleneck steps, proposes sharding / cache / concurrency improvements. Runs `scripts/audit-ci.sh`.From its SKILL.md

Install
npx -y skills add krkrkrr/skills --skill frontend-review-ci

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.6 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

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

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.