agentsclimarketplace

Frontend web

Skill tienenwu/fables/en/frontend-web

Self-evolving skill packs that give Claude Code & Codex judgment, not knowledge — decidable rules, per-playbook regression quizzes for models, and a project harness generator. zh-TW canon + full EN mirror.

Install
npx -y skills add tienenwu/fables --skill frontend-web

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when writing, refactoring, or debugging React/Next.js frontend code (App Router, Server/Client Components, hooks, Tailwind/CSS Modules) — before adding a component, choosing where state lives, wiring data fetching, or preparing a production deploy; or when facing hydration mismatch, NEXT_PUBLIC_ env leaks, excessive re-render, bundle size bloat, CLS, SEO/metadata gaps, or XSS via dangerouslySetInnerHTML.

SKILL.md

6.1 KB, as published. Nobody here has run it

🌐 繁體中文(canonical) · English mirror

React / Next.js Frontend Judgment Handbook

Core Principles

  1. A green dev server proves nothing: hydration, env-var injection, bundle size, SEO metadata, and minification only show their true behavior under next build && next start — any change on the production path must be verified with a production build.
  2. Remote data and UI state are two different things: server state (from an API/DB — it goes stale, needs caching, needs refetching) belongs to React Query/SWR; client state (pure view toggles, input fields) uses useState/zustand. Mixing the two is the root of most "data out of sync" bugs.
  3. Put state at the lowest layer that uses it: default to local, lift only when it hurts, go global last. Reaching for a global store too early is entropy, not architecture.
  4. A re-render is a symptom, not the disease: first use the Profiler to measure which component re-renders and why, then decide whether to memo; scattering useMemo/useCallback on gut feel is just noise.
  5. Anything that enters the client bundle is visible to the user: NEXT_PUBLIC_-prefixed variables, strings hardcoded into components, whole libraries imported into a Client Component — assume it is public first, then prove it deserves to be public.

Task Triage

SituationPathRead first
New screen/featureFirst decide where data comes from, who owns state, what needs "use client", then write the UIreferences/architecture-state.md
Write/change a component, extract a component, stylingFirst settle the semantic boundary and props contract, then actreferences/components-styling.md
Janky screen, too many re-renders, oversized bundleDo not scatter memo first — measure firstreferences/rendering-performance.md
Fetch remote data, caching, loading/error statesSeparate server state from client statereferences/architecture-state.md §1
Ship to production / deploy / diagnose "fine in dev, blows up in prod"Run the mandatory checklist line by linereferences/release-checklist.md
hydration mismatch, env vars, SEOAssume a build-time difference first, do not thrashreferences/release-checklist.md

Red Lines (Absolutely Forbidden)

  • Never declare a release-relevant change done after verifying only on the dev server — hydration, NEXT_PUBLIC_ injection, bundle, minify, and metadata are all misrepresented in dev.
  • Never prefix a secret (API key, DB connection string, private key) with NEXT_PUBLIC_ or hardcode it into a Client Component — it gets bundled into the JS, readable by any user, equivalent to publishing the secret.
  • Never feed dangerouslySetInnerHTML a user-controllable string without sanitizing — that is direct XSS; a user's <script> will execute in someone else's browser.
  • Never use an array index as the key of a list that will be inserted into / removed from / reordered — on insert or sort React mismatches the DOM, so input-field contents jump to the wrong row and checkbox states end up on the wrong item.
  • Never read window/localStorage/Date.now()/Math.random() directly during render to decide output — the server has no such value or a different one, causing a hydration mismatch that makes the whole tree get thrown away and re-rendered on the client.
  • Never loosen tests/type checks to turn CI green — two red runs in a row is a wrong-direction signal; back up to the previous decision point, do not comment out the assertion.

Failure Signals (Back Up, Don't Retry)

SymptomUsually meansBack up to
It took a pile of useMemo/useCallback to stop the jankUpstream passes unstable props, or state sits too highUse the Profiler to find the real re-render source, re-examine the state layer
Every component needs a useEffect to sync its own copy of the dataServer state got stuffed into useStateSwitch to React Query/SWR as the single source of truth
More and more suppressHydrationWarning being addedServer/client output is fundamentally inconsistentFind the divergent value (Date/random/browser API) and move it into useEffect
Props drilled down 5 levels (prop drilling)State should be lifted or moved to context/storeRe-examine who owns the state, don't keep drilling
Every change requires adding 'use client' one layer higher to stop the errorThe client boundary is drawn wrong, dragging Server Component content down with itRe-examine the boundary: only interactive leaf nodes need client
The same hydration error survives three rewritesYou are guessing without locating the divergent valueRead the component named in the console, diff server vs client HTML

References Index

  • references/architecture-state.md — server vs client state boundary, which layer state lives in, Server/Client Component decisions, where data fetching happens. Read before touching architecture or a new feature.
  • references/components-styling.md — when to extract a component, props contracts, controlled vs uncontrolled, CSS strategy, a11y red lines. Read before writing UI.
  • references/rendering-performance.md — measure first, memo criteria, list keys, code splitting, images/fonts/CLS. Read when janky or the bundle is too large.
  • references/release-checklist.md — env-var leaks, hydration diagnosis, SEO, real production-build testing, XSS, error boundaries, bundle thresholds. Tick off line by line before publishing.
  • references/test-scenarios.md — the judgment test set, to verify an inheriting model follows the rules. Do not let a running model read it.

Gives 0 of the 12 instructions most css styling skills give

Counted across 586 of the 596 authors here whose files we hold, read 2026-08-06

  • avoid excessive centered layoutsin 55 of 586, across 12 files
  • bundle code into single HTML filein 54 of 586, across 14 files
  • Respect prefers-reduced-motion user settingsin 52 of 586, across 35 files
  • avoid purple gradientsin 51 of 586, across 11 files
  • avoid uniform rounded cornersin 51 of 586, across 11 files
  • avoid Inter fontin 51 of 586, across 11 files
  • edit generated files to develop artifactin 50 of 586, across 10 files
  • animate only transform and opacity propertiesin 43 of 586
  • Make touch targets at least 44x44 pixelsin 41 of 586, across 15 files
  • Ensure minimum color contrast of 4.5:1in 39 of 586, across 10 files
  • use tailwind cssin 39 of 586, across 24 files
  • Use SVG icons instead of emojisin 38 of 586, across 11 files

Said here and by no other author read

  • Verify production-path changes with a production build
  • Place state at the lowest needed layer
  • Measure re-renders with the Profiler before memoizing
  • Treat anything in the client bundle as public
  • Sanitize user-controllable strings before using dangerouslySetInnerHTML
  • Guard browser-only APIs from server render

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.