Skip to content

Packs

Frontend

When to use it
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.
Covers
Build and review software (3)
Where you decide
No gated loop of its own; the skills run one at a time.
Size
8 skills · 0 loops
npx skilldrop-cli install --pack frontend

Installs 8 skills, including core.

Other ways to install

The pack's loops too, each as an invokable skill:

npx skilldrop-cli install --loop --pack frontend

In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):

/plugin install frontend@skilldrop

Into Cursor, Kiro or another IDE:

npx skilldrop-cli install --pack frontend --ide cursor

Start here: Find out what actually makes a page slow for real users

Paste this into your agent:

Here's report.json from Lighthouse for our product page. We score 92 in the lab, but Search Console says LCP is poor on mobile. What's making it slow for real users, and what should we fix first?
Before you start
  • A Lighthouse JSON report for a slow page (npx lighthouse <url> --output=json --output-path=report.json), and its field data from PageSpeed Insights or Search Console if you have it
How to tell it worked
web-performance-review leads with the field verdict (which vital fails at p75), names the LCP element and the phase that dominates it, and ranks fixes by how much each moves that vital, not by Lighthouse's estimated savings.
If nothing happens
If the reply leads with the lab score or a generic checklist, ask for it by name ("use web-performance-review") and include the PageSpeed Insights JSON, which carries the field data.

A typical session

When: A page is slow, a bundle grew, or you're deciding how a new app's routes should be rendered.

You bring:

  1. rendering-strategy
    You
    Describe the routes, their data and traffic, and the framework.
    You get
    A route table: how each page is rendered and cached, what invalidates it, and what it shows when its data source is slow.
    You decide
    Which routes change rendering mode first.
  2. bundle-size-review
    You
    Hand over the stats file, and the one before the change if a PR made it grow.
    You get
    The compressed JavaScript each entry loads before first render, what pulls in each heavy module, duplicates, and what can safely come out.
  3. web-performance-review
    You
    Hand over the Lighthouse or PageSpeed Insights JSON, with field data.
    You get
    Which vital fails for real users, why, and the fixes ranked by how much each moves it.
    You decide
    Which fix ships first, and how you'll measure it in the field.

You end with: Pages rendered the way their data needs, a bundle with nothing heavy in the first load that doesn't need to be, and fixes chosen by what real users feel.

Compare Frontend with another pack

Skills in this pack (3)

Included from core (5)