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
npx -y skills add krkrkrr/skills --skill frontend-review-ciAssembled 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
- Run
scripts/audit-ci.sh --repo <client-repo>. - Read
<client-repo>/.frontend-review/report/latest/raw/ci.json. - For the slowest runs, dig into step-level timing:
gh run view <run-id> --log | grep -E '^\d{4}-' | head -200 - 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.ymlhas cache butlint.ymlandpages.ymldo not. - Does
actions/setup-nodeusecache: pnpm, or is there a manualactions/cacheblock for the pnpm store? Either is fine; the key must includehashFiles('**/pnpm-lock.yaml'). - Does
actions/cachecache the Playwright browser store (~/.cache/ms-playwright)? - Is there a
concurrency:block? - Are vitest / playwright sharded?
- Are jobs serialized via
needs:unnecessarily? - Are
lintandtypecheckin the same serial job? They have no dependency on each other and should be separate parallel jobs.
- Does every job (lint, build, test, coverage, etc.) use a pnpm/npm store cache? A common miss:
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.
| Stage | Target | How to measure |
|---|---|---|
| HMR (edit → screen) | < 500 ms | Vite --debug output |
| Unit test — single file | < 1 s | vitest / jest output |
test:ci — full suite | < 1 min | CI step duration |
typecheck | < 30 s | CI step duration |
lint | < 30 s | CI step duration |
| E2E — one shard | < 50 s | CI step duration |
| PR CI total (parallel) | < 5 min | GitHub Actions wall-clock |
install (cache hit) | < 15 s | CI step duration |
build | < 30 s | CI step duration |
The PR CI total target is the critical gate. CI slower than 5 minutes is routinely bypassed by developers.
Bottleneck Identification Procedure
- Pull step-level timing from the slowest recent run:
gh run view <run-id> --log | grep -E '^\d{4}-' | head -200 - Identify the single slowest job in the DAG — only the longest path in a parallel graph determines wall-clock time.
- Within that job, identify the slowest step.
- Propose one change per PR — bundling multiple optimisations makes regression attribution impossible.
- Measure wall-clock before/after on the same branch to verify the win.
Typical Optimisation Patterns
| Area | Common fix |
|---|---|
install | pnpm / 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 + typecheck | Split into two parallel jobs (no mutual dependency). On a project with ~170 TS files, this alone cuts the lint-job wall-clock in half |
typecheck | Project References split, skipLibCheck: true, resolve circular type imports |
lint | lint-staged for PR (changed files only), enable linter's own incremental cache |
vitest | isolate: false, tune --pool thread count, exclude test fixtures from coverage |
| Playwright | Tune shard count to test volume, page.route() to mock external APIs, move flaky tests to daily-only tag |
| Runner size | Larger 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