Six Frontend Skills for Claude — A Portable Production Suite on skills.sh

What started as a single Claude skill has grown into a small suite. It began with the one thing I'd refined across every React and React Native project I've shipped — a consistent way to answer "where does this code live?" — and it kept growing as I realized the same approach could capture the other production concerns I reach for on every project.

The repo now ships six free, MIT-licensed skills. You can find them on skills.sh, and the source lives on GitHub at stareezy-1/frontend-architecture-skill.

What a Skill Actually Is

If you haven't run into them yet: a skill is a portable instruction file (SKILL.md) that an AI coding tool loads into context when the work matches its description. Claude reads it, but so do OpenCode, Codex, Cursor, Windsurf, and Copilot — anything that understands the Anthropic SKILL.md format or can be pointed at it from AGENTS.md / CLAUDE.md.

The point is leverage. Instead of re-explaining your conventions in every prompt, you encode them once. The agent then scaffolds features, places components, wires telemetry, and names types the way you would — without being told each time.

The Suite

Each skill is deliberately structure and rules, not a component library or a visual style. And each is grounded in a real system I've shipped, not abstract advice.

1. frontend-architecture — where everything lives

The foundation. It organizes apps around three questions a contributor should answer instantly without asking anyone: where does this code live?, what is allowed to import what?, and is this server state or UI state?

Five principles do all the work: feature modules own their world; pages are directories, not files; state is split by origin; imports cross boundaries only through barrels; and code is promoted, not pre-placed. The same module/page/state model maps onto Next.js App Router, React + Vite, Remix, and Expo / React Native — only the thin routing layer changes.

2. frontend-seo — discoverability as a system

A complete SEO system built as pure builder functions plus a thin framework adapter. Site identity lives in one constants module, every URL flows through a single canonicalUrl(), and search engines get generated sitemap.xml, robots.txt, an RSS feed, and typed JSON-LD structured data (Person, WebSite, BlogPosting, CreativeWork, BreadcrumbList, FAQPage) — all cross-referenced by stable @id.

3. frontend-lighthouse — a performance gate that blocks regressions

A Lighthouse CI gate around a single lighthouserc.cjs. It runs against the production build with median-of-N runs for stability and blocks pull requests that miss Google's "good" Core Web Vitals budgets (LCP ≤ 2500 ms, INP ≤ 200 ms via the TBT lab proxy, CLS ≤ 0.1) or the category score floors. Ships the config, an lhci script, and a GitHub Actions workflow.

4. frontend-data-contracts — type safety at the network edge

One typed API client as the single fetch boundary. The moment data crosses in, it's parsed into a trusted domain type (parse, don't validate) — or it becomes one normalized ApiError. A single { data } / { error } envelope, branded IDs so a CustomerId can't be passed where an InvoiceId is expected, and per-field server errors mapped straight onto form fields.

5. frontend-optimistic-mutations — the write path

The craft of making writes feel instant and safe. A fixed optimistic lifecycle — cancel in-flight queries, snapshot every affected cache, patch instantly, roll back verbatim on error, invalidate on settle — plus idempotency keys generated once at intent time so a retry replays the original response instead of double-charging, and lock-step coherence so the detail view and every list page always agree.

6. frontend-observability — the field side

The complement to the Lighthouse lab gate. A typed event taxonomy (no stringly-typed track("clicked_thing") scattered around), a best-effort non-blocking provider fan-out so a broken or absent analytics provider can never crash the app, real-user Core Web Vitals reported through the same pipe, error reporting at deliberate boundaries, and consent gating so nothing fires before opt-in. It speaks Firebase Analytics, GA4, Clarity, PostHog, OpenPanel, and Sentry — with the same adapter shape on web and React Native (the Firebase adapter guards the native module instead of window).

How They Fit Together

The skills aren't isolated — they reference each other where the seams meet:

• frontend-data-contracts defines the typed client; frontend-optimistic-mutations builds its write path on top of it.
• frontend-lighthouse is the lab performance gate; frontend-observability is the field side, reporting real-user vitals against the same metrics and thresholds.
• All of them live inside the module structure that frontend-architecture lays down — SEO in a service module, the client in shared/api-client, analytics in services/analytics.

The Rule I Reach For Most

If I had to keep one rule from the whole suite, it's still the state split from the architecture skill:

Never mirror server responses into the client store. The query/cache layer is the single source of truth for server data. UI state — open dialogs, filters, wizard steps, drafts — lives in the module store. Neither leaks into the other.

This single boundary prevents the most common way frontend codebases decay: fetched entities getting copied into a global store, then drifting out of sync with the server. The optimistic-mutations skill leans on exactly this — optimistic state lives in the query cache, never the store.

Try It

Install the whole suite, or just the skill you need, from skills.sh or straight from the repo:

# the whole suite
npx skills add stareezy-1/frontend-architecture-skill

# or a single skill
npx skills add stareezy-1/frontend-architecture-skill --skill "frontend-observability"

Every skill — directory layouts, conventions checklists, per-framework adapters, and the diagrams that show how the pieces fit — is on GitHub. It's all MIT licensed, so copy and adapt it freely.

If you try one and something doesn't map cleanly onto your stack, open an issue. The whole value of a portable skill is that it gets sharper the more codebases it meets.