Agent skill

Frontend Lighthouse

by sickn33 in sickn33/agentic-awesome-skills

Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts.

MITAuto-check passedFrontend & Design

Install Frontend Lighthouse

skills CLI
$ npx skills add sickn33/agentic-awesome-skills --skill frontend-lighthouse -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install sickn33/agentic-awesome-skills frontend-lighthouse --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/sickn33/agentic-awesome-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/frontend-lighthouse .claude/skills/frontend-lighthouse && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
frontend-lighthouse
GitHub stars
47k
Used in
1 other repo
Token cost
~3.8k tokens
SKILL.md length
1,170 words
Files
1
Skills in repo
1,354
Repo updated
First seen
Licence
MIT

At a glance

Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts.

  • Works in 10 steps: The five core ideas → Files this skill adds → The config (lighthouserc.cjs) → …
  • Tasks that involve Web performance
  • SKILL.md covers When to Use This Skill, 0. The five core ideas, 1. Files this skill adds and 2. The config (lighthouserc.cjs), plus 9 more sections
  • Calls pnpm, npx and node

What it does

Frontend Lighthouse is an agent skill from sickn33/agentic-awesome-skills. Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Frontend & Design, covering Web performance. The repository describes itself as: AAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,400+ agentic skills. Includes… The licence is MIT.

When your agent uses it

  • Tasks that involve Web performance

Example prompts

  • “/frontend-lighthouse”

Requirements

  • Node.js

Workflow steps

10 steps, taken from the step headings in SKILL.md.

  1. The five core ideas
  2. Files this skill adds
  3. The config (lighthouserc.cjs)
  4. Choosing budget severity and thresholds
  5. The npm script
  6. The GitHub Actions workflow
  7. Framework adapters
  8. Debugging failing or flaky runs
  9. Conventions checklist (enforce in review)
  10. How to apply this skill

What it can do on your machine

Read from SKILL.md and the folder at commit ec02547. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pnpm
    • npx
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pnpm and npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Frontend Lighthouse loads about 3.8k tokens when it runs. Until then it costs about 41 tokens; SKILL.md has 1,170 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~41
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from sickn33/agentic-awesome-skills at commit ec02547, republished under its MIT licence (© sickn33). 1,170 words, ~3,752 tokens.

Download SKILL.mdSave it as .claude/skills/frontend-lighthouse/SKILL.md (or your agent's skills folder).
name
frontend-lighthouse
description
Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts.
category
frontend
risk
safe
source
community
source_repo
stareezy-1/frontend-architecture-skill
source_type
community
date_added
2026-06-29
author
stareezy-1
tags
frontend, lighthouse, performance, core-web-vitals, ci
tools
lighthouse, node, github-actions
license
MIT

Frontend Lighthouse (portable performance gate)

Portable skill — readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and others. This skill describes a CI performance gate — a Lighthouse CI config plus a workflow — not a component library or a visual style. It pairs with the frontend-seo and frontend-architecture skills: SEO writes the metadata, Lighthouse proves it ships fast.

The goal: every pull request is blocked unless the production build meets explicit Core Web Vitals budgets and category score floors. Budgets live in one lighthouserc.cjs, runs are median-of-N so the gate doesn't flake, and the same config runs locally and in CI.

When to Use This Skill

  • Use when adding a Lighthouse CI performance gate to a web app.
  • Use when setting Core Web Vitals budgets for LCP, CLS, and TBT as the lab proxy for INP.
  • Use when configuring category score floors for performance, SEO, accessibility, and best practices.
  • Use when debugging flaky Lighthouse runs or making reports visible as CI artifacts.

0. The five core ideas

  1. One config, one source of truth. All budgets and assertions live in a single lighthouserc.cjs. Named constants for each budget — no magic numbers buried in assertion objects.
  2. Gate the production build, never dev. Lighthouse runs against build + start (the real, optimized output). Dev-server numbers are meaningless for a budget.
  3. Median-of-N kills flakiness. Run 3+ times and assert on the median run, so per-run jitter (cold caches, CI noise) never red-flags a healthy build.
  4. Budgets encode Google's "good" thresholds. LCP ≤ 2500 ms, INP ≤ 200 ms (gated via the TBT lab proxy), CLS ≤ 0.1 — the values that earn green scores, not "needs improvement".
  5. Blocking in CI, visible as artifacts. A GitHub Action runs the gate on every PR touching the app and uploads the HTML/JSON reports so failures are debuggable.

1. Files this skill adds

apps/web/                          (or your app root)
├── lighthouserc.cjs               ← the gate: budgets + assertions + collect settings
├── package.json                   ← "lhci": "lhci autorun --config=./lighthouserc.cjs"
└── .github/workflows/lighthouse.yml  ← PR-blocking CI job (build → start → lhci → upload)

Plus a dev dependency: @lhci/cli.

bash
pnpm add -D @lhci/cli        # or npm i -D / yarn add -D

2. The config (lighthouserc.cjs)

.cjs (CommonJS) so it loads without ESM/TS transpilation. Every budget is a named constant with a comment explaining the threshold — never a bare number inside an assertion.

js
/**
 * Lighthouse CI configuration — Core Web Vitals budgets for the marketing surface.
 *
 * Enforces Google's mobile "good" CWV thresholds:
 *   - Largest Contentful Paint (LCP) ≤ 2500 ms
 *   - Cumulative Layout Shift (CLS)  ≤ 0.1
 *   - Interaction to Next Paint (INP) ≤ 200 ms
 *
 * INP is a *field* metric with no direct lab audit, so in the lab we gate on
 * Total Blocking Time (TBT) — Lighthouse's recommended lab proxy — at the same
 * budget, and assert the experimental INP audit directly as a warning where the
 * build exposes it.
 *
 * Collection runs against the *production* server (build + start) on Lighthouse's
 * default mobile (Moto G4 / slow 4G) emulation.
 */

/** The fixed port the production server is started on for the audit. */
const PORT = 3100;
const BASE_URL = `http://localhost:${PORT}`;

/** Pages whose budgets are enforced in CI. */
const MARKETING_URLS = [`${BASE_URL}/`];

/**
 * Core Web Vitals budgets on mobile — Google's "good" thresholds.
 * These are the values that earn the best Lighthouse scores.
 */
const LCP_BUDGET_MS = 2500; // good
const INP_BUDGET_MS = 200; // good (TBT lab proxy)
const CLS_BUDGET = 0.1; // good

module.exports = {
  ci: {
    collect: {
      // Build is run separately in CI; here we only serve the production output.
      startServerCommand: `pnpm start --port ${PORT}`,
      startServerReadyPattern: "Ready in", // framework's "server ready" log line
      startServerReadyTimeout: 120000,
      url: MARKETING_URLS,
      // Median of multiple runs keeps the gate stable against per-run jitter.
      numberOfRuns: 3,
      settings: {
        // Default mobile emulation; opt into desktop via env for a second run.
        preset:
          process.env.LHCI_FORM_FACTOR === "desktop" ? "desktop" : undefined,
        // Only gate the categories we care about; skip PWA category noise.
        onlyCategories: [
          "performance",
          "seo",
          "accessibility",
          "best-practices",
        ],
      },
    },
    assert: {
      // Median across runs is the value compared against each budget.
      aggregationMethod: "median-run",
      assertions: {
        // --- Core Web Vitals budgets (the contract) ---------------------
        "largest-contentful-paint": [
          "error",
          { maxNumericValue: LCP_BUDGET_MS },
        ],
        "cumulative-layout-shift": ["error", { maxNumericValue: CLS_BUDGET }],
        "total-blocking-time": ["error", { maxNumericValue: INP_BUDGET_MS }],
        // Direct INP audit where the Lighthouse build exposes it (else ignored).
        "interaction-to-next-paint": [
          "warn",
          { maxNumericValue: INP_BUDGET_MS },
        ],

        // --- Category floors (target top Lighthouse scores) -------------
        "categories:performance": ["error", { minScore: 0.9 }],
        "categories:seo": ["error", { minScore: 0.95 }],
        "categories:accessibility": ["error", { minScore: 0.95 }],
        "categories:best-practices": ["error", { minScore: 0.9 }],
      },
    },
    upload: {
      // Keep reports in the CI run's filesystem; no external LHCI server.
      target: "filesystem",
      outputDir: "./.lighthouseci",
    },
  },
};

Hard rules:

  • Every budget is a named constant with a unit in its name (LCP_BUDGET_MS) and a comment.
  • aggregationMethod: "median-run" is non-negotiable — single-run gates flake constantly.
  • numberOfRuns ≥ 3 (odd numbers give a clean median).
  • Assert on TBT for INP in the lab; treat the experimental interaction-to-next-paint audit as a warn, not an error (it isn't present in every Lighthouse build).
  • Keep onlyCategories to exactly what you gate — fewer audits, faster, less noise.

3. Choosing budget severity and thresholds

Audit / categorySeverityThresholdWhy
largest-contentful-painterror≤ 2500 msGoogle "good" LCP
cumulative-layout-shifterror≤ 0.1Google "good" CLS
total-blocking-timeerror≤ 200 msINP lab proxy
interaction-to-next-paintwarn≤ 200 msnot in all builds; don't hard-fail on a missing audit
categories:performanceerror≥ 0.9top (green) band
categories:seoerror≥ 0.95SEO is cheap to keep perfect
categories:accessibilityerror≥ 0.95a11y regressions must block
categories:best-practiceserror≥ 0.9green band

Use error for contracts that must hold and warn for audits that are environment-dependent or aspirational. Start strict and only loosen with a recorded reason — a budget you keep raising to make CI pass is a budget that no longer protects anything.


4. The npm script

jsonc
// package.json
{
  "scripts": {
    "lhci": "lhci autorun --config=./lighthouserc.cjs"
  }
}

lhci autorun runs collect → assert → upload in sequence. Run it locally before pushing to reproduce exactly what CI does:

bash
pnpm build && pnpm lhci
# desktop form factor:
LHCI_FORM_FACTOR=desktop pnpm build && LHCI_FORM_FACTOR=desktop pnpm lhci

5. The GitHub Actions workflow

Runs on PRs that touch the app or the workflow itself. Builds the production output, runs the gate, and always uploads the reports (even on failure) so a red check is debuggable.

yaml
name: Lighthouse CWV

on:
  pull_request:
    branches: [main]
    paths:
      - "apps/web/**"
      - ".github/workflows/lighthouse.yml"

permissions:
  contents: read

jobs:
  lighthouse:
    name: Lighthouse CWV (marketing pages)
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: apps/web
    steps:
      - uses: actions/checkout@v4

      - name: Setup pnpm
        uses: pnpm/action-setup@v4 # version comes from root package.json packageManager

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm

      - name: Install dependencies
        working-directory: .
        run: pnpm install --frozen-lockfile

      - name: Build web app
        run: pnpm build

      # build + start the production server, run Lighthouse on mobile emulation,
      # fail the job if any budget in lighthouserc.cjs is exceeded.
      - name: Run Lighthouse CI
        run: pnpm lhci

      - name: Upload Lighthouse reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: lighthouse-reports
          path: apps/web/.lighthouseci
          if-no-files-found: ignore

Hard rules:

  • Trigger on the app path and the workflow file so config changes are self-testing.
  • if: always() on the upload step — you need the report most when the gate fails.
  • Gate on the production build (pnpm build then the start server in collect).
  • Match the CI Node/pnpm versions to the repo's pinned versions to avoid lockfile drift.

6. Framework adapters

The config is framework-neutral except startServerCommand and startServerReadyPattern.

FrameworkstartServerCommandstartServerReadyPattern
Next.jspnpm start --port 3100 (after next build)"Ready in"
Remixpnpm start (serve the built app)server's listening log line
Astronode ./dist/server/entry.mjs (SSR) or npx serve dist (static)the adapter's ready line / serve's URL line
SvelteKitnode build (node adapter)"Listening on"
Vite SPAnpx vite preview --port 3100"Local:"

For purely static output you can skip the server and point collect.staticDistDir at the build folder instead of startServerCommand — Lighthouse serves it internally.


Show full SKILL.md (438 more words)Show less

7. Debugging failing or flaky runs

  • Flaky LCP/TBT → raise numberOfRuns (5), confirm median-run, and make sure nothing else is competing for CPU on the runner.
  • interaction-to-next-paint errors → it should be warn, not error; the audit is missing in some Lighthouse versions.
  • "server not ready" timeout → fix startServerReadyPattern to match the framework's actual ready log, and raise startServerReadyTimeout.
  • Real regressions → open the uploaded report artifact, read the failed audit's "Opportunities"/"Diagnostics", fix the cause (oversized image, render-blocking JS, layout shift from unsized media) — don't just bump the budget.
  • Desktop vs mobile divergence → run both form factors; mobile is the stricter gate and should be the default.

8. Conventions checklist (enforce in review)

  • All budgets are named constants with units and comments — no magic numbers in assertions.
  • Gate runs against the production build, never the dev server.
  • aggregationMethod: "median-run" with numberOfRuns ≥ 3.
  • CWV budgets at Google "good" thresholds (LCP ≤ 2500, TBT ≤ 200, CLS ≤ 0.1).
  • INP gated via TBT (error); experimental INP audit is warn.
  • Category floors set as error (perf ≥ 0.9, SEO/a11y ≥ 0.95, best-practices ≥ 0.9).
  • onlyCategories lists exactly the gated categories.
  • CI triggers on the app path and the workflow file; reports upload with if: always().
  • Local pnpm lhci reproduces the CI run.
  • Budgets are tightened over time, loosened only with a recorded reason.

9. How to apply this skill

Adding the gate to a project: install @lhci/cli, drop in lighthouserc.cjs with your URLs and startServerCommand, add the lhci script, and add the workflow. Run pnpm build && pnpm lhci locally to confirm it passes before opening a PR.

Adding a page to the gate: append its URL to MARKETING_URLS (or a second URL array). Each URL is audited independently against the same budgets.

Tuning budgets: change the named constant, not the assertion. Record why in the comment. Prefer fixing the regression over raising the budget.

Reviewing performance: run the checklist in §8. The highest-value catches are a gate that runs against the dev server (meaningless numbers) and single-run assertions (chronic flakiness).


Publishing / installing this skill

This skill follows the Anthropic SKILL.md format and is portable across agents.

  1. Keep it under skills/frontend-lighthouse/SKILL.md in a public GitHub repo.
  2. Keep the frontmatter name and high-signal description — discovery indexes match against it.
  3. Install with: npx skills add <org>/<repo> --skill "frontend-lighthouse".
  4. Non-SKILL.md agents can be pointed here from AGENTS.md / CLAUDE.md; Kiro can mirror it as a steering file.

Limitations

  • Lighthouse CI is a lab signal and does not replace field monitoring from real-user metrics.
  • Budgets must be tuned to the actual app route, hosting platform, and device/network assumptions.
  • A passing Lighthouse gate does not prove business-critical flows, visual correctness, or backend availability.

© sickn33, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/frontend-lighthouse of sickn33/agentic-awesome-skills.

Open the folder on GitHubat commit ec02547

Used in 1 other repository

We found 5 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in sickn33/agentic-awesome-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Frontend Lighthouse next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Frontend Lighthouse compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Frontend Lighthouse this skillsickn33/agentic-awesome-skills47k1 repos~3.8kAutomated safety check: PassMIT
React Doctormakeplane/plane61k12 repos~657Automated safety check: PassAGPL-3.0
Fixing Motion Performanceibelick/ui-skills9.5k5 repos~1.4kAutomated safety check: PassMIT
GSAP Performance Tuninggreensock/gsap-skills16k4 repos~1kAutomated safety check: PassMIT
React Frontend Development Guidelinesdiet103/claude-code-infrastructure-showcase10k2 repos~2.9kAutomated safety check: PassMIT
Web Quality Auditaddyosmani/web-quality-skills2.9k—~2.6kAutomated safety check: PassMIT

Similar skills

  • React Doctor

    makeplane/plane

    Scans React code for lint, accessibility, bundle size and architecture issues, reports a health score and checks that changes do not lower it.

    61k GitHub starsUsed in 12 repos~657 tokens
    Frontend & DesignAuto-check passed
  • Fixing Motion Performance

    ibelick/ui-skills

    Audits and fixes web animation performance: layout thrashing, work that belongs on the compositor, scroll-linked motion and costly blur effects.

    9.5k GitHub starsUsed in 5 repos~1.4k tokens
    Frontend & DesignAuto-check passed
  • GSAP Performance Tuning

    greensock/gsap-skills

    Guides the agent to keep GSAP animations smooth by animating transforms and opacity, batching DOM reads and writes, and avoiding layout-heavy properties.

    16k GitHub starsUsed in 4 repos~1k tokens
    Frontend & DesignAuto-check passed
  • React Frontend Development Guidelines

    diet103/claude-code-infrastructure-showcase

    Guidelines for React 18 and TypeScript apps covering Suspense data fetching, lazy loading, feature folders, MUI v7 styling, TanStack Router and performance.

    10k GitHub starsUsed in 2 repos~2.9k tokens
    Frontend & DesignAuto-check passed
  • Web Quality Audit

    addyosmani/web-quality-skills

    Run an evidence-led web quality audit covering performance, accessibility, SEO, best practices, and agentic browsing.

    2.9k GitHub stars~2.6k tokensUpdated 1 mo ago
    Frontend & DesignAuto-check passed
  • SEO Google

    AgriciDaniel/codex-seo

    Google SEO APIs: Search Console (Search Analytics, URL Inspection, Sitemaps), PageSpeed Insights v5, CrUX field data with 25-week history, Indexing API v3, and GA4 organic traffic.

    791 GitHub starsUsed in 2 repos~3.4k tokens
    Frontend & DesignAuto-check passed

More from sickn33/agentic-awesome-skills

All 1,354 skills in this repo
  • Liuguang Banlan UI

    sickn33/agentic-awesome-skills

    Implements an interface in one of two named color modes, iridescent white or colorful black, from a parameterized starter that reports measured color intensity.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • User Thoughts Memory

    sickn33/agentic-awesome-skills

    Saves a user's project decisions, rules and preferences into a project-local mdbase so later sessions and other agents can recover the intent.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • Using LWC Memory and Graphs

    sickn33/agentic-awesome-skills

    Keeps project decisions, research and verified results available across coding-agent sessions through LWC memory, a document Wiki graph and a CodeGraph code index.

    47k GitHub starsUsed in 1 repo~2k tokens
    Auto-check passed
  • Find Complementary Founders

    sickn33/agentic-awesome-skills

    Guides an agent through assessing its own owner for cofounder fit, publishing an approved profile, and ranking complementary profiles other agents published for their owners.

    47k GitHub starsUsed in 1 repo~4.8k tokens
    Auto-check passed
  • Cline Pilot

    sickn33/agentic-awesome-skills

    Acts as a proxy for the Cline CLI, dispatching coding tasks one at a time, monitoring runs by hard evidence, relaying decisions to you and learning per-project preferences.

    47k GitHub starsUsed in 1 repo~4.6k tokens
    Auto-check passed
  • Content Creator

    sickn33/agentic-awesome-skills

    Drafts and reviews audience-specific content from supplied brand examples, with local scripts for brand voice and SEO diagnostics, channel templates and a content calendar.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

Questions about Frontend Lighthouse

What does Frontend Lighthouse do?

Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts. Frontend Lighthouse is an agent skill from sickn33/agentic-awesome-skills. Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts.

When should I use Frontend Lighthouse?

Frontend Lighthouse fits situations like: tasks that involve Web performance.

How do I install Frontend Lighthouse in Claude Code?

Run `npx skills add sickn33/agentic-awesome-skills --skill frontend-lighthouse -a claude-code`. Or copy the skill folder (skills/frontend-lighthouse in sickn33/agentic-awesome-skills) into .claude/skills/frontend-lighthouse in your project. Claude Code loads it when a task matches its description.

How do I install Frontend Lighthouse in Codex?

Run `npx skills add sickn33/agentic-awesome-skills --skill frontend-lighthouse -a codex`. Or copy the skill folder (skills/frontend-lighthouse in sickn33/agentic-awesome-skills) into .agents/skills/frontend-lighthouse in your project. Codex loads it when a task matches its description.

Can I use Frontend Lighthouse in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add sickn33/agentic-awesome-skills --skill frontend-lighthouse -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/frontend-lighthouse, .gemini/skills/frontend-lighthouse, .github/skills/frontend-lighthouse and .opencode/skills/frontend-lighthouse in your project.

What does Frontend Lighthouse need to run?

Going by SKILL.md and its folder, Frontend Lighthouse needs the command-line tools its instructions call (pnpm, npx and node). Our summary lists: Node.js.

Does Frontend Lighthouse access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Frontend Lighthouse safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Frontend Lighthouse use?

Frontend Lighthouse is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Frontend Lighthouse use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Frontend Lighthouse?

Skills that share tags, products or a category with Frontend Lighthouse: React Doctor (makeplane/plane, 61k stars), Fixing Motion Performance (ibelick/ui-skills, 9.5k stars), GSAP Performance Tuning (greensock/gsap-skills, 16k stars) and React Frontend Development Guidelines (diet103/claude-code-infrastructure-showcase, 10k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Frontend Lighthouse?

sickn33 (a GitHub user) maintains it in sickn33/agentic-awesome-skills, which has 47,343 GitHub stars. The repository holds 1,354 skills in this directory. The repository was last updated on October 7, 2026.

Source: sickn33/agentic-awesome-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.