Frontend pack reference
Every skill in the Frontend pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.
For frontend engineers and the people who review their pages: read a Lighthouse report for what actually slows the page, find what makes a JavaScript bundle heavy, and choose how each route is rendered from what it needs.
| Install | npx skilldrop-cli install --pack frontend |
| Skills | 3 plus 5 from core |
| Loops | none |
| How-to | Use the Frontend pack |
Skills
bundle-size-review
Find what makes a JavaScript bundle heavy and what can safely come out, from the bundler's stats file (webpack stats.json, an esbuild metafile, or the rollup-plugin-visualizer raw-data JSON that Vite builds use) read together with the repo around it (package.json, .browserslistrc, the lockfile, the bundler config and the source files that import the heavy modules). Gives each entry's first-load JavaScript in the exact bytes the stats record, kept apart from lazy chunks; finds whole-library imports, CommonJS packages that can't be tree-shaken, packages bundled twice and polyfills the browser targets don't need; names the import chain that pulls each module in before suggesting a removal; and, given before and after stats, says what grew, why, whether it lands in the first load and which per-entry budget would have caught it.
Tier standard · v0.2.3 · SKILL.md · skill page
Use it when the user says "why is our bundle so big", "what can we cut from the bundle", "review this stats.json", "why is lodash or moment in our bundle", "the bundle grew in this PR", or "set a bundle size budget".
Needs: Python 3 for its scripts (standard library only).
A good result:
- The first line answers the question in the person's terms, with the exact byte figures from the stats.
- The repo was read: targets, versions and importing files are cited by file name; nothing is called absent without having been looked for.
- Each fix is an exact edit to a named file; files are changed only when the user asked for changes.
- The guard is real configuration for a tool that exists, with no invented flag, script or key.
- One unit system, bytes with kB = 1000, and the kind of size (module, emitted, post-bundle, compressed) is named once.
- Compressed figures are measured or absent, never estimated into the lead.
- Initial and lazy are kept apart, and a lazy chunk is never ranked above an initial-chunk fix.
- Every suggested removal names its import chain and is valid for the installed version; no downgrades, no APIs the installed major lacks.
- Duplicates name both paths, both versions and who asks for which range, and a major-version override is flagged as a change to test.
- A per-entry budget closes the reply, with a threshold that passes the good build and fails the bad one.
Hands off to: web-performance-review when the user's real question is why the page is slow for users, with a Lighthouse or PageSpeed report in hand.
Not for:
- Reading a Lighthouse report for what slows the page (LCP, INP, CLS, render-blocking requests): use
web-performance-review - Choosing SSR, static or client rendering per route to ship less JavaScript: use
rendering-strategy - Deciding whether a dependency bump PR is safe to merge: use
dependency-upgrade-review - Reviewing the application code in a PR for correctness: use
pre-merge-review - Server or API response time, database queries, or backend memory
rendering-strategy
Decide route by route how each page of a web app is rendered — static at build (SSG), static with revalidation (ISR, stale-while-revalidate), server-rendered per request (SSR, streaming), client-rendered (CSR, SPA), at the edge, or a mix with islands and server components — from how fresh each route's data must be, whether it is personalised, whether it must be indexed or shared, what it costs per request at the stated traffic and how much JavaScript it needs, with the cache keys, invalidation events and failure modes of each choice.
Tier standard · v0.1.0 · SKILL.md · skill page
Use it when the user asks "should this be SSR or static", "SSR vs SSG vs ISR", "how should each page be rendered", "do we need SSR for SEO", "which pages can we cache", or is choosing rendering modes in Next.js, Nuxt, Remix, React Router, SvelteKit or Astro.
Needs: Python 3 for its scripts (standard library only).
A good result:
- One row per route or route group, each with a mode and the deciding reason. One mode for the whole app fails.
- Every cached route names its invalidation event and the pages it touches; time alone is not an invalidation plan for data that changes on an event.
- Every personalised response is named as never shared-cached (
private, no-store, or kept off the cached page as a fragment). - Seconds-fresh data is a fragment with its own short-lived source, not the page's revalidation window.
- Every row has a failure mode: what the user sees when its data source is slow or down.
- Cost is a computed number when traffic is given, from the input's figures only.
- Framework settings appear only for the named framework, and version-dependent behaviour is flagged.
- Nothing invented: traffic, freshness and versions come from the input or carry
[assumption].
Hands off to: nfr-spec when the routes have no stated freshness, latency or availability targets to decide against; adr-generator when the route table is agreed and the team wants it on record.
Not for:
- Designing the whole system (services, data stores, rollout) —
design-doc - Writing the chosen strategy up as a numbered decision record —
adr-generator - Setting latency or availability targets for the app —
nfr-spec - Diagnosing why a page is slow from a Lighthouse report — that is a page-speed review, not a rendering decision
web-performance-review
Read a Lighthouse report or PageSpeed Insights result, with field data when there is any (CrUX, PSI loadingExperience or RUM p75), and say what makes the page slow for real users and what to fix first, ranked by how much each fix moves LCP, INP and CLS at the 75th percentile. Names the LCP element and which LCP phase dominates, the elements that shift and why, the long tasks and third parties by main-thread time, and treats estimated savings as lab estimates that overlap.
Tier standard · v0.1.3 · SKILL.md · skill page
Use it when the user shares a Lighthouse JSON or PSI result and asks "why is this page slow", "what should we fix first", "we score 92 but Search Console says LCP is poor", "did our change fix INP", "review this Lighthouse report", or "how do we pass Core Web Vitals".
Needs: Python 3 for its scripts (standard library only).
A good result:
- The first lines say whether real users have a problem, on which vital, from which data, with the p75 threshold.
- No verdict from the Performance score. The score is described as a lab weighting, not as Core Web Vitals.
- The LCP element is named by selector or snippet, with the phase breakdown when the report has it, and the fix matches the dominant phase.
- Every CLS fix names the shifting element and its cause; field CLS above lab CLS is called out as after-load shifts the run can't see.
- TBT is never reported as INP. Long tasks and third parties are named by script or entity with milliseconds.
- Fixes are ranked by the failing vital's per-metric saving, load-time-only savings are not ranked as vital fixes, and overlapping savings are not summed.
- The single-run caveat and the emulated device and network appear once, with medians of 3 to 5 runs or field data as the bar for "improved".
- No invented numbers, elements or URLs. Every figure and selector is in the input or computed from it.
Hands off to: observability-plan when there is no field data, or the review needs RUM with per-element attribution to find after-load shifts or slow interactions.
Not for:
- The accessibility findings in the same Lighthouse report: use
accessibility-audit - What is in a JavaScript bundle and why it is heavy (source maps, stats files): use
bundle-size-review - Choosing SSR, static, ISR or client rendering for routes: use
rendering-strategy - Setting up RUM, web-vitals collection, dashboards or alerts: use
observability-plan - Lighthouse SEO and Best Practices scores; this skill reads the Performance category only
Included from core
Installed with this pack. Details: Core pack reference.
brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.