Use the Frontend pack

Install the Frontend pack, run its first task, and follow a typical session step by step.

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.

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

1. Install it

npx skilldrop-cli install --pack frontend                 # Claude Code, your user folder
npx skilldrop-cli install --pack frontend --project       # Claude Code, this repo
npx skilldrop-cli install --pack frontend --ide cursor    # or kiro, codex, antigravity, copilot
npx skilldrop-cli install --pack frontend --local         # this repo, hidden from git

In Claude Code you can also add the marketplace once (/plugin marketplace add sananthanarayan/skilldrop) and run /plugin install frontend@skilldrop.

It brings core with it, so the shared skills are there too.

2. Run the first task: find out what actually makes a page slow for real users

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

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?

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.

3. A typical session

Bring:

• a Lighthouse or PageSpeed Insights JSON, with field data if you have it
• the bundler's stats file (webpack stats.json, an esbuild metafile or the Vite visualizer JSON)
• the app's routes, how fresh each one's data must be, and the framework
• rendering-strategy: 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.
• bundle-size-review: 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.
• web-performance-review: 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.

Next

• Every skill in the Frontend pack: what each one makes, needs and hands off to
• The pack's page, with one-click copy for every command
• Upgrade installed skills when a new version ships

Edit this page on GitHub · View source