@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/browser-compatibility-review/references/browserslist-matrix-interpretation.md

@@ -0,0 +1,49 @@
+# Browserslist Matrix Interpretation
+
+Use this reference when reading, interpreting, or proposing a change to the project's `.browserslistrc` / `package.json` `browserslist` config, or reconciling it with build-tool targets (Autoprefixer, Babel `preset-env`, `postcss-preset-env`, esbuild `target`).
+
+> Version note (uncertainty flag): Context7 did not resolve a dedicated `browserslist` library at the time this skill was authored (only adjacent tooling like `es-check`, which integrates with Browserslist, was found). Treat Browserslist query-syntax details below as `documentation-based (Context7 unavailable for this library)`, and always confirm exact current syntax against the project's own resolved config output and the official `browserslist/browserslist` GitHub README before relying on it for a production recommendation.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> There's no `.browserslistrc` file, so this project doesn't have a declared matrix — I'll just eyeball it.
+
+Wrong. Browserslist resolves configuration from multiple possible locations, in a defined precedence, and most frontend build tools (Autoprefixer, Babel, ESLint's `eslint-plugin-compat`, PostCSS presets) read it implicitly. Before declaring "no matrix exists," check all of the standard resolution points:
+
+- a `browserslist` key in the project's `package.json`,
+- a `.browserslistrc` file at the project root or a parent directory,
+- a `BROWSERSLIST` environment variable (rare, but overrides file-based config when set),
+- a shared/extended config referenced via `extends` in either of the above.
+
+If genuinely none exist, Browserslist falls back to its own defaults (`> 0.5%, last 2 versions, Firefox ESR, not dead`) — that fallback *is* the effective matrix, and should be reported as such rather than treated as "no matrix."
+
+## Reading the matrix correctly
+
+- Browserslist queries combine like `> 0.5%, last 2 versions, not dead` — each comma-separated clause is a query, and by default clauses are combined with logical OR (a browser matching *any* clause is included), unless explicitly joined with `and`. Do not assume AND semantics for comma-separated queries without confirming against the project's resolved output.
+- `not dead` excludes browsers without official support or security updates for the past 24 months (per Browserslist's documented `dead` query) — a matrix without `not dead` may be implicitly including officially unsupported browsers, which is itself worth flagging.
+- Percentage-based queries (`> 0.5%`) are usage-share-relative and will silently shift over time as global usage shifts — a matrix expressed this way is not a fixed, auditable list; if the review needs a fixed matrix (e.g. for a compliance/procurement commitment), recommend resolving the query to a concrete browser list and pinning that, or flag the drift risk explicitly.
+- To see the *actual resolved list* of browsers/versions a config expands to (not just the raw query string), the standard approach is running the project's own Browserslist resolution tooling (commonly exposed via the `browserslist` CLI or a project script) rather than manually reasoning about what a query string expands to — verify the exact command locally instead of assuming a specific CLI invocation, since this detail was not confirmed via Context7 for this skill.
+
+## Non-negotiable rules
+
+1. **Never approve or reject a feature's compatibility using an assumed matrix.** Always resolve the project's actual config (file-based, `package.json`-based, or the documented Browserslist default) before making a claim.
+2. **Distinguish the declared query from the resolved browser list.** "last 2 versions" is not itself a browser list; it must be resolved against current release data to know which concrete versions are in scope, and that resolution changes over time as new versions ship.
+3. **Reconcile the Browserslist matrix with the build tool's actual behavior separately per tool.** Babel `preset-env`, Autoprefixer, and `postcss-preset-env` each consume the same Browserslist config but apply it differently (transpilation targets vs CSS prefixing vs CSS feature polyfilling) — do not assume that because Babel is configured correctly, CSS-level compatibility is automatically covered, or vice versa.
+4. **A percentage- or "last N versions"-based query is a moving target.** Flag this explicitly when a stakeholder wants a fixed compliance commitment; recommend either pinning explicit browser/version pairs or re-verifying the resolved list on a defined cadence.
+5. **Proposing a matrix change is a data-backed recommendation, not a unilateral edit.** Base any proposed change on real usage/analytics data for the org's actual audience, and route the recommendation to the product/analytics owner rather than silently narrowing or widening support.
+
+## Verification targets
+
+- The actual `browserslist` key / `.browserslistrc` content in the project (read directly).
+- The resolved concrete browser/version list the query expands to, obtained via the project's own tooling — verify the exact invocation locally rather than assuming one.
+- Whether Babel, Autoprefixer, and any CSS preset-env-style tool in the build pipeline are all wired to the same Browserslist config (shared root config) rather than divergent per-tool overrides.
+
+## When to push back
+
+Push back if the user asks to:
+
+- widen or narrow the supported-browser matrix without any usage/analytics justification,
+- treat a percentage-based query as a fixed, auditable list for a compliance statement without resolving and pinning it,
+- add a browser-compatibility "fix" that actually just silences a linter (`eslint-plugin-compat` disable comment) rather than resolving the underlying gap.

package/skills/frontend/browser-compatibility-review/references/fallback-verification-patterns.md

@@ -0,0 +1,54 @@
+# Fallback Verification Patterns
+
+Use this reference when a finding requires checking whether an actual feature-detection gate or polyfill exists and correctly covers the risky code path — across JS, CSS, and HTML — rather than accepting an assertion that "there's a fallback."
+
+## What people get wrong
+
+The common bad assumption is:
+
+> The PR description says there's a fallback, so the fallback question is closed.
+
+That is not evidence. A description, a comment, or a variable name (`hasPolyfillFallback`) is not proof that a gate exists, that it is correctly scoped to the risky code path, or that it fails safe. Always read the actual gating code before closing a fallback finding.
+
+## Three fallback mechanisms, not one
+
+Do not treat "fallback" as a single undifferentiated concept. There are three distinct mechanisms, each with its own failure modes:
+
+1. **CSS `@supports` (feature queries)** — gates a CSS declaration block on whether the engine supports a given property/value pair.
+   - Failure mode: `@supports` itself has near-universal support, but the *query* can be written incorrectly (testing the wrong property, or a value that is always true/false), silently making the gate a no-op.
+   - Verification: confirm the `@supports` condition actually names the property/value being used in the gated block, and that a real non-supporting fallback declaration exists *before* the `@supports` block (CSS cascade order — the fallback must be overridable, not overridden).
+
+2. **JS runtime feature detection** (`if ('IntersectionObserver' in window)`, `typeof`, `in` checks, capability probing) — gates a code path on whether an API exists before calling it.
+   - Failure mode: detecting the *existence* of an API is not the same as detecting *correct/complete* behavior — some browsers ship a partial or buggy implementation that passes an existence check but fails at runtime. For any feature with known partial-implementation history, verify the detection checks the specific method/behavior actually used, not just the top-level constructor.
+   - Verification: confirm the detected branch and the fallback branch are both reachable in the code (not dead code), and that the fallback branch has been exercised — read it, do not assume it degrades gracefully.
+
+3. **Polyfills** (loaded unconditionally or conditionally) — ship an implementation of the missing capability.
+   - Failure mode: an unconditionally-loaded polyfill ships bytes to every user, including the ~95%+ who already have native support, with zero runtime code-splitting; a conditionally-loaded polyfill (dynamic `import()` behind a feature-detection check) avoids that cost but must be verified to not create a race condition where the gated code runs before the polyfill import resolves.
+   - Verification: confirm whether the polyfill load is conditional or unconditional (check the bundler output / import site), and if conditional, confirm the code that depends on the polyfilled API awaits the import before use.
+
+## HTML-level fallback pattern
+
+For new HTML elements/attributes, the platform's own graceful-degradation model (unknown elements render as inline/anonymous boxes, unknown attributes are ignored) is sometimes sufficient — but only when the fallback behavior of "ignore it" is actually an acceptable UX, not a broken one. Do not accept "the browser will just ignore it" as a verified fallback without checking whether ignoring the attribute leaves the feature in a broken or misleading state (e.g. a `<dialog>` element with no polyfill on a browser that doesn't support it does not just degrade — it fails to open at all).
+
+## Non-negotiable rules
+
+1. **A fallback finding is not closed until the actual gating code has been read.** Comments, descriptions, and test names are not evidence.
+2. **The fallback path must be reachable and non-dead.** If the "supported" branch always evaluates true in every test/CI browser, the fallback branch may be unexercised dead code — flag this explicitly.
+3. **Existence checks are not behavior checks.** For features with a documented history of partial/buggy implementations, verify the detection matches the actual method/behavior used.
+4. **Unconditional polyfill loading is a performance finding, not just a compatibility non-issue.** Note the bundle-size cost even when the fallback itself is technically correct.
+5. **CSS cascade order matters.** A fallback declaration placed *after* the `@supports`-gated declaration will win regardless of support, silently defeating the gate — always check declaration order, not just presence of the `@supports` block.
+
+## Verification targets
+
+- The literal `@supports`, `if`/`in`/`typeof` check, or dynamic-`import()` gate in the diff or file, read directly — not paraphrased from a PR description.
+- CSS declaration order around any `@supports` block.
+- Whether the polyfill import is conditional (behind a feature check) or unconditional, and whether dependent code awaits it.
+- Whether the fallback branch is exercised by any existing test, or is unexercised dead code.
+
+## When to push back
+
+Push back if the user says:
+
+- "there's a fallback, trust me" without pointing at code,
+- "the browser will just ignore the unsupported part" for a feature whose absence actually breaks core functionality (not genuinely inert),
+- "we'll add the polyfill later" while shipping the unguarded feature now to a matrix that doesn't yet support it.

package/skills/frontend/build-tooling-vite-webpack-review/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: build-tooling-vite-webpack-review
+description: Reviews Vite and Webpack build/chunking configuration and bundle-size composition for duplicate dependencies, unsplit vendor chunks, and tree-shaking failures, always version-labeling config since Vite 8 replaced Rollup-era manualChunks with Rolldown-based codeSplitting.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: compute
+---
+
+# Build Tooling (Vite/Webpack) Review
+
+## Purpose
+
+Bundler config advice that doesn't match the installed major version is worse than no advice — it produces a config diff that silently no-ops, throws at build time, or (worst case) applies to the wrong bundler engine entirely. Vite ships two build engines depending on version and config shape (Rollup-backed `rollupOptions`, or Rolldown-backed `rolldownOptions`), and Vite 8 removed the object form of `manualChunks` outright. This skill reviews Vite/Webpack build and chunking *configuration itself* — the config file, not the resulting bundle bytes — and treats the target bundler's exact major version as a required input, not an assumption, before proposing any config diff.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review or tune Vite `build.rollupOptions`/`build.rolldownOptions` or Webpack `optimization.splitChunks` chunking configuration,
+- diagnose a duplicate-dependency-across-chunks defect or an unsplit vendor chunk caused by chunking config (not by application-level import boundaries),
+- evaluate a proposed bundler migration (Webpack to Vite, Rollup-backed Vite to Rolldown-backed Vite, or a Vite major-version upgrade) for build-time and config-compatibility impact,
+- diagnose a tree-shaking failure that traces back to bundler/build config (module format, `sideEffects` field interaction with the bundler, barrel-file re-exports defeating static analysis) rather than to source-code side effects,
+- set up or review a CI bundle-size budget gate at the build-tool level (build script, CI job config).
+
+## When NOT to use
+
+- Setting or auditing the *numeric* size budget itself, ranking analyzer contributors by byte weight vs. execution cost, or deciding route/component-level code-splitting boundaries — hand off to `bundle-budget-code-splitting-review` for that; this skill reviews the bundler config mechanism, not the budget methodology or split-boundary decision.
+- Verifying that tree-shaking actually eliminated dead code via a before/after byte diff, or auditing `sideEffects: false` correctness on a specific package — hand off to `tree-shaking-dead-code-review` for that; this skill only flags build-config patterns (barrel imports, module-format mismatches) that are *known to defeat* tree-shaking, it does not verify the outcome.
+- Non-bundler build tooling (Babel-only transpilation pipelines with no bundling step, TypeScript `tsc`-only builds, esbuild/Rolldown used as a library outside Vite/Webpack) — different config surface, not in scope here.
+
+## Context7 Documentation Protocol
+
+Vite's build-engine and chunking API surface changed between major versions — do not prescribe a config from memorized training data.
+
+1. Call `ToolSearch` with query `"context7"` (or `"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs"`) to load the Context7 tools if not already loaded this session.
+2. Call `mcp__Context7__resolve-library-id` for each bundler in scope (`/vitejs/vite`, Webpack, `/rollup/rollup`, and `/rolldown/rolldown` if the project's Vite build is Rolldown-backed) before prescribing any chunking configuration.
+3. Call `mcp__Context7__query-docs` for the specific mechanism — e.g. "rollupOptions.output.manualChunks vs rolldownOptions.output.codeSplitting", "splitChunks cacheGroups defaults", "manualChunks object form vs function form" — before ruling on it. Do this per review; do not reuse a prior session's memory of bundler internals.
+4. Known version-sensitive facts verified via Context7 as of this skill's `updated` date:
+   - Vite's migration guide documents that the **object form** of `build.rollupOptions.output.manualChunks` was **removed**, and the **function form** was **deprecated**; the replacement is `build.rolldownOptions.output.codeSplitting`, which takes a `groups` array of `{ name, test }` entries (Rolldown's declarative chunk-grouping API). Do not hand a project on that config path a `manualChunks: { vendor: [...] }` object-form snippet — it will not apply.
+   - Rollup itself (used directly, or via Vite versions/configs that still route through `rollupOptions`) continues to support both the object form and function form of `output.manualChunks` per Rollup's own configuration docs — the removal is specific to Vite's option surface and its migration path toward Rolldown, not a Rollup-wide deprecation. Confirm which bundler engine actually processes the config (`rollupOptions` vs `rolldownOptions` key) before applying either party's rules.
+   - Vite ships a built-in `splitVendorChunkPlugin` that composes with function-form `manualChunks` but explicitly logs a warning and no-ops when combined with the object form — treat "vendor chunk isn't splitting and there's a console warning about `splitVendorChunk`" as a symptom of this specific interaction, not a generic bug report.
+5. Webpack's `optimization.splitChunks` surface (`cacheGroups`, `chunks: 'all' | 'async' | 'initial'`, `minSize`, `maxInitialRequests`) is comparatively stable across recent majors per Context7-grounded docs, including its documented defaults (`minSize: 20000`, `defaultVendors`/`default` cache groups with `priority: -10`/`-20`) — still confirm the installed Webpack major before asserting a specific default, since defaults have shifted across major versions historically.
+6. If Context7 is unavailable or returns no relevant match for the installed bundler, fall back to `official_docs` and mark the claim `documentation-based (Context7 unavailable)` rather than presenting it as freshly verified.
+7. Never invent a bundler config key, CLI flag, or plugin option that no queried source confirms.
+
+## Lean operating rules
+
+- Confirm the installed Vite major version and which output-options key (`rollupOptions` vs `rolldownOptions`) the project's own config already uses before proposing a diff — these are two different bundler engines with two different chunking APIs, and giving the wrong era's config is a concrete, verified failure, not a style choice.
+- Distinguish Vite's dev-server behavior (native ESM, no bundling, chunking config irrelevant) from its production build behavior (bundled via Rollup or Rolldown depending on version/config); every recommendation in this skill applies only to the production build path.
+- Flag barrel-file (`index.ts` re-export) imports and wildcard imports of large libraries (icon sets, date libraries, utility libraries) as build-config-relevant tree-shaking risks when the project's module format or bundler settings can't statically resolve them — name the specific named/subpath-import fix, and hand off to `tree-shaking-dead-code-review` to verify the byte-level outcome.
+- Treat a duplicate-dependency-across-chunks finding as a chunk-grouping *config* defect (fix `manualChunks`/`codeSplitting`/`cacheGroups`), not an application-code defect — do not propose restructuring import statements to solve what a config change solves more directly.
+- Require a stated measured baseline (current bundle output, build time) before endorsing any bundler or bundler-major migration, plus a rollback path (pinned lockfile entry, ability to revert the config key).
+- Recommend a CI bundle-size budget gate at the build-tool/CI-job level for any budget-critical route that lacks one, rather than treating build-config review as a one-time audit — but define the numeric budget itself only via `bundle-budget-code-splitting-review`.
+- Do not evaluate bundle-size numbers as if they were field/RUM Core Web Vitals data; a build's stats output is lab data from a CI build unless explicitly stated otherwise.
+- Never accept "it built without errors" as evidence a chunking config change is correct — a removed or renamed option key can silently no-op (see the Vite 8 `manualChunks` object-form removal) rather than error.
+
+## References
+
+Load these only when needed:
+
+- [Vite chunking config reference](references/vite-chunking-config.md) — use when reviewing or writing `rollupOptions.output.manualChunks` or `rolldownOptions.output.codeSplitting`, or diagnosing which bundler engine a Vite config actually invokes.
+- [Webpack splitChunks reference](references/webpack-splitchunks-config.md) — use when reviewing or writing `optimization.splitChunks`, `cacheGroups`, or `runtimeChunk` configuration.
+- [Migration and config-diff safety](references/migration-and-config-diff-safety.md) — use before endorsing a bundler migration or a chunking-config change, to confirm baseline capture, rollback path, and the verification steps that must precede calling a config change complete.
+
+## Response minimum
+
+Return, at minimum:
+
+- the bundler and confirmed major version (and, for Vite, the confirmed output-options key: `rollupOptions` or `rolldownOptions`) the guidance targets,
+- build-config findings (duplicate-dependency chunk-grouping defects, config keys that no longer apply for the confirmed version, barrel-file/module-format patterns defeating tree-shaking) with file/line evidence,
+- proposed chunking/config diff (not applied), labeled lab vs field for any performance number cited,
+- evidence level (`live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`),
+- migration caveat (baseline + rollback) if a bundler or bundler-major change is recommended, and a handoff note to `bundle-budget-code-splitting-review` or `tree-shaking-dead-code-review` if the user's actual question is budget-setting or tree-shaking verification rather than config review.

package/skills/frontend/build-tooling-vite-webpack-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "build-tooling-vite-webpack-review",
+  "name": "Build Tooling (Vite/Webpack) Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Vite and Webpack build configuration, code-splitting/chunking strategy, and bundle-size budgets, version-labeling every recommendation because Vite 8's Rolldown-based codeSplitting API replaced the Rollup-era manualChunks option.",
+  "source_type": "original",
+  "official_docs": [
+    "https://vite.dev/guide/build.html",
+    "https://vite.dev/guide/migration.html",
+    "https://webpack.js.org/guides/code-splitting/",
+    "https://webpack.js.org/plugins/split-chunks-plugin/"
+  ],
+  "security_notes": "Bundle-analyzer output shared outside the org must not include source maps that reveal internal API paths or accidentally-inlined environment values. Any dependency with an install-time script that runs during the build must be reviewed before it's allowed to affect the production bundle. Static-review-only skill: it reads and greps build config and source; it does not execute builds, install dependencies, or run bundler CLIs. Treat any credential-shaped string found in a pasted build config, CI job definition, or analyzer report as unsafe to echo in the transcript.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/build-tooling-vite-webpack-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/build-tooling-vite-webpack-review/references/migration-and-config-diff-safety.md

@@ -0,0 +1,41 @@
+# Migration and Config-Diff Safety
+
+Use this reference before endorsing any bundler migration (Webpack to Vite, Rollup-backed Vite to Rolldown-backed Vite, or a Vite/Webpack major-version bump) or before calling any chunking-config change complete.
+
+## What people get wrong
+
+The naive assumption is:
+
+> The build succeeded with the new config, so the migration/change is done.
+
+Wrong on two counts. First, a removed-but-not-erroring option (see `references/vite-chunking-config.md` on the Vite `manualChunks` object-form removal) means a "successful" build can silently be running a different chunking strategy than the team believes — success is not evidence of equivalence. Second, "the build succeeded" says nothing about whether the resulting bundle composition, chunk count, or build time actually moved in the intended direction, or whether a rollback path exists if it didn't.
+
+## Non-negotiable rules
+
+1. **Capture a measured baseline before any config or bundler change is applied.** At minimum: current chunk list with sizes (from the existing build's stats/manifest output), current total build time, and current bundler/major version. Without this, "did the migration help" is unanswerable after the fact.
+2. **State the rollback path explicitly before endorsing the change.** For a config-only change, this is typically "revert this diff, config keys are additive/isolated." For a bundler-major or engine-swap migration (e.g., adopting Rolldown-backed Vite), confirm whether the change is a single reversible config-key swap or whether it also touches lockfile-pinned plugin versions that may not be compatible with the prior engine — a plugin written against Rollup's plugin API is not guaranteed compatible with Rolldown's plugin API even where the two claim general compatibility; confirm via Context7 rather than assuming.
+3. **Never treat "build succeeded, no errors" as proof a chunking-config change took effect.** Require a chunk-list diff (names, count, sizes) between before and after. An unchanged chunk list after an intentional config edit means the edit likely didn't apply — check for the specific silent-no-op patterns named in the Vite and Webpack references before assuming the config is simply already optimal.
+4. **Do not endorse a bundler migration on build-time or DX grounds alone without also stating the bundle-composition impact**, or explicitly noting that composition impact is unverified. A faster build with an unreviewed change in chunk boundaries can trade build-time wins for runtime request-count or duplicate-dependency regressions — that trade-off must be named, not silently accepted.
+5. **Flag any migration proposal that lacks a stated baseline or rollback path as incomplete**, regardless of how confident the proposal otherwise sounds — this is the same discipline this skill applies to config-key claims: unverified confidence is not evidence.
+6. **When the user's actual goal is a numeric bundle-size budget or code-splitting boundary decision** (not a config-mechanism review), hand off to `bundle-budget-code-splitting-review` rather than expanding this skill's scope to cover budget methodology.
+7. **When the user's actual goal is verifying that a config change eliminated dead code** (byte-level tree-shaking outcome, `sideEffects` correctness), hand off to `tree-shaking-dead-code-review` rather than asserting a tree-shaking outcome from config inspection alone — this skill can flag config patterns *known to defeat* tree-shaking (barrel imports, module-format mismatches) but does not verify the resulting byte-level outcome itself.
+
+## Minimal safe review flow
+
+1. Confirm the current bundler, major version, and (for Vite) the active output-options key (`rollupOptions` vs `rolldownOptions`).
+2. Capture the baseline: current chunk list/sizes and current build time, from user-provided build output or stats file — do not fabricate baseline numbers.
+3. Ground every config-key claim via Context7 for the confirmed version before proposing a diff (see the Context7 Documentation Protocol in `SKILL.md`).
+4. Propose the config diff, not an applied change — this is a static-review skill; it does not run builds.
+5. State the verification command the user (or their CI) must run to confirm the diff took effect (e.g., `npm run build -- --report` or the project's equivalent stats-output invocation) and what a successful before/after diff looks like.
+6. State the rollback path explicitly, even if it is as simple as "revert this config diff."
+
+## When to push back
+
+Push back if the user asks for:
+
+- a bundler-major or engine (Rollup-to-Rolldown) migration with no stated baseline and "we'll measure it after,"
+- a chunking-config change accepted as complete purely because the build didn't error,
+- merging all of `node_modules` into a single vendor chunk (Webpack) or an equivalent broad grouping (Vite) presented as a universal best practice rather than a named caching/parallelism trade-off,
+- a `manualChunks` config change on a Vite project without first confirming which output-options key and Vite major are actually in play.
+
+Those are not shortcuts. They are a config diff without evidence it does what it claims.

package/skills/frontend/build-tooling-vite-webpack-review/references/vite-chunking-config.md

@@ -0,0 +1,68 @@
+# Vite Chunking Configuration
+
+Use this reference when reviewing or writing Vite's production-build chunking configuration, or when a project reports a chunking config that "used to work" and no longer applies.
+
+> Version note: this reference reflects Context7-grounded Vite documentation as of this skill's `updated` date. Vite's build-engine option surface has changed across major versions — re-verify against `mcp__Context7__query-docs` for `/vitejs/vite` before applying any snippet below to a specific installed version, and confirm the version with the project's own lockfile or `vite --version` output rather than assuming it from `package.json` ranges.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "Vite chunking config" is one API — `manualChunks` — and it works the same across every Vite version.
+
+Wrong. Vite's production build is not one bundler; it is a build-engine seam. Depending on the Vite major version and which output-options key the config uses, the actual bundling engine is either:
+
+- **Rollup**, addressed via `build.rollupOptions.output.manualChunks`, or
+- **Rolldown** (a Rust-based bundler with a Rollup-compatible API surface, but its own option shapes for some features), addressed via `build.rolldownOptions.output.codeSplitting`.
+
+A config snippet that is correct for one engine can silently no-op under the other. This is not a deprecation warning you can ignore — Vite's own migration guide documents the object form of `manualChunks` as **removed**, not merely discouraged.
+
+## Officially grounded shape (what Vite/Rollup/Rolldown docs actually say)
+
+Per Context7-grounded Vite build/migration docs and Rollup's own configuration docs:
+
+- **Rollup's `output.manualChunks`** (used when the config's build path routes through `rollupOptions`) supports two forms:
+  - **Object form**: `manualChunks: { 'vendor-react': ['react', 'react-dom'] }` — maps a chunk name to an explicit array of module specifiers. Rollup's own docs describe this as the simpler, safer form.
+  - **Function form**: `manualChunks(id) { if (id.includes('node_modules')) return 'vendor'; }` — receives the module ID (and `{ getModuleInfo, getModuleIds }`) and returns a chunk name string or `null`/`undefined` to leave the module unassigned. Rollup's docs note `output.onlyExplicitManualChunks` is itself a separate, deprecated option slated to become Rollup 5's default behavior — confirm this hasn't shifted before relying on implicit fallback chunking.
+  - Rollup itself has **not** removed either form; the removal described below is specific to Vite's own option surface on its migration path toward Rolldown.
+
+- **Vite's `build.rollupOptions.output.manualChunks`** — per Vite's migration guide (grounded via Context7): the **object form is removed** and the **function form is deprecated**. A project still passing `manualChunks: { vendor: [...] }` to `rollupOptions.output` on a Vite version past this removal will see the option ignored, not an error — this is the single most common false-negative in this review.
+
+- **Vite's `build.rolldownOptions.output.codeSplitting`** — the documented replacement. Per Vite's build guide and Rolldown's own `manualCodeSplitting` reference, this takes a declarative shape:
+
+  ```javascript
+  export default defineConfig({
+    build: {
+      rolldownOptions: {
+        output: {
+          codeSplitting: {
+            groups: [
+              { name: 'vendor-react', test: /node_modules\/(react|react-dom)/ },
+              { name: 'chunk', test: 'chunk.css' },
+            ],
+          },
+        },
+      },
+    },
+  })
+  ```
+
+  Each entry in `groups` is a `{ name, test }` pair; `test` can match on module ID pattern. This is a declarative alternative to `manualChunks`'s imperative function form, intended to avoid circular-dependency footguns that hand-written `manualChunks` functions can introduce.
+
+- **`splitVendorChunkPlugin`** — Vite ships a built-in plugin implementing a `vendor` chunk heuristic (any `node_modules` module, not CSS, statically imported by an entry point) as a `manualChunks` function. Per its own source (grounded via Context7): when composed with a user-supplied **function-form** `manualChunks`, it wraps and chains the two; when composed with an **object-form** `manualChunks`, it detects the object form and **logs a console warning that it has no effect**, then does nothing. A project reporting "the vendor-splitting plugin isn't working, no error, just a console warning" is very likely hitting exactly this interaction.
+
+## Non-negotiable review rules
+
+1. **Confirm the output-options key before applying either ruleset.** Grep the Vite config for `rollupOptions` vs `rolldownOptions` under `build`. These are not interchangeable, and a chunking snippet written for one silently does nothing under the other.
+2. **Confirm the installed Vite major.** Do not infer it from a `^7.0.0`-style semver range in `package.json` alone — a caret range can resolve to a version past a documented removal. Prefer lockfile-resolved version or a reported `vite --version` if available as user-provided evidence.
+3. **If the config uses `rollupOptions.output.manualChunks` as an object**, and the confirmed Vite major is on/after the version where Vite's migration guide documents the removal, flag this as a silent no-op, not a style nit — the chunking strategy the team believes is active is not running.
+4. **If the config uses `rollupOptions.output.manualChunks` as a function**, treat it as valid but flag it as a forward-migration item toward `rolldownOptions.output.codeSplitting`, per Vite's own deprecation notice — do not present the function form as the long-term recommended pattern.
+5. **When migrating a `manualChunks` function to `codeSplitting` groups**, do not assume a 1:1 mechanical translation. A `manualChunks` function can express arbitrary conditional logic (e.g., branching on `getModuleInfo(id).importers`); `codeSplitting`'s `groups` array is pattern-match-based (`test` against module ID). Confirm each branch of the original function has an equivalent `test` pattern before calling the migration complete — untranslatable branches are a real migration risk, not a formality.
+6. **Do not conflate Vite's dev-server module graph with its build chunking.** Chunking config has zero effect on `vite dev`; it applies only to `vite build`. A user reporting a "chunking problem" during local dev is describing something this config cannot cause.
+
+## Verification targets
+
+- The confirmed Vite major (from lockfile or reported CLI version) and the output-options key actually present in `vite.config.*`.
+- For a `manualChunks` object-form finding: the exact Vite version threshold from `mcp__Context7__query-docs` against `/vitejs/vite`'s migration guide, quoted, not paraphrased from memory.
+- For a proposed `codeSplitting` groups migration: each `groups[].test` pattern mapped explicitly back to the branch of the prior `manualChunks` function it replaces.
+- A build output diff (chunk list, sizes) confirming the new config actually changed the chunk boundaries — an unchanged chunk list after a config edit is evidence the edit didn't take effect, not evidence the config was already optimal.

package/skills/frontend/build-tooling-vite-webpack-review/references/webpack-splitchunks-config.md

@@ -0,0 +1,84 @@
+# Webpack SplitChunksPlugin Configuration
+
+Use this reference when reviewing or writing Webpack's `optimization.splitChunks` configuration, `cacheGroups`, or `runtimeChunk` settings.
+
+> Version note: confirm the installed Webpack major via `mcp__Context7__query-docs` against Webpack's own docs before asserting a specific default value below applies — `SplitChunksPlugin` defaults have shifted across major versions historically, and this reference documents the currently Context7-grounded defaults, not a version-pinned guarantee.
+
+## What people get wrong
+
+The naive assumption is:
+
+> `optimization.splitChunks: { chunks: 'all' }` is "the vendor-splitting setting" and turning it on is the whole job.
+
+Incomplete. `chunks: 'all'` only changes *which* chunks (`async`, `initial`, or both) are eligible for splitting — it does not by itself define a vendor group, a size threshold, or a request-count ceiling. Webpack's actual chunk-splitting behavior is the product of several settings interacting: `chunks`, `minSize`, `minChunks`, `maxAsyncRequests`, `maxInitialRequests`, `enforceSizeThreshold`, and the `cacheGroups` map. Reviewing only `chunks` and ignoring the rest of the object produces a config that "does something" without the reviewer knowing what.
+
+## Officially grounded shape (what Webpack docs actually say)
+
+Per Context7-grounded Webpack docs (`SplitChunksPlugin` reference and code-splitting/caching guides):
+
+- **Default `optimization.splitChunks` shape**, documented explicitly:
+
+  ```javascript
+  optimization: {
+    splitChunks: {
+      chunks: "async",
+      minSize: 20000,
+      minRemainingSize: 0,
+      minChunks: 1,
+      maxAsyncRequests: 30,
+      maxInitialRequests: 30,
+      enforceSizeThreshold: 50000,
+      cacheGroups: {
+        defaultVendors: {
+          test: /[\\/]node_modules[\\/]/,
+          priority: -10,
+          reuseExistingChunk: true,
+        },
+        default: {
+          minChunks: 2,
+          priority: -20,
+          reuseExistingChunk: true,
+        },
+      },
+    },
+  }
+  ```
+
+  The default `chunks: "async"` means only dynamically-imported (`import()`) chunks are eligible for splitting out of the box — a project relying on defaults and expecting *initial* (entry-point) chunks to also get vendor-split needs to explicitly set `chunks: "all"`, either globally or per cache group.
+
+- **Explicit vendor cache group** — the documented pattern for pulling all `node_modules` code into a named `vendors` chunk:
+
+  ```javascript
+  optimization: {
+    runtimeChunk: 'single',
+    splitChunks: {
+      cacheGroups: {
+        vendor: {
+          test: /[\\/]node_modules[\\/]/,
+          name: 'vendors',
+          chunks: 'all',
+        },
+      },
+    },
+  },
+  ```
+
+  Webpack's own caching guide pairs this with `runtimeChunk: 'single'` specifically for long-term-caching correctness — extracting the webpack runtime/manifest into its own chunk so that changes to application code don't invalidate the vendor chunk's content hash. A `vendor` cache group added without `runtimeChunk: 'single'` is a common half-fix: the vendor chunk hash still churns on unrelated app changes because the runtime is bundled with it.
+
+- **Custom cache-group merging** — Webpack's docs note that merging all of `node_modules` into a single `vendors` chunk via a broad `test: /node_modules/` cache group "is not generally recommended" as a default strategy, but can be a deliberate trade-off for long-term caching in specific deployment setups. Treat a broad single-vendor-chunk config as an explicit trade-off to confirm with the team, not a default best practice to apply unprompted.
+
+## Non-negotiable review rules
+
+1. **Read the whole `splitChunks` object, not just `chunks`.** `minSize`, `maxInitialRequests`, and `enforceSizeThreshold` jointly determine whether a module that "should" be split actually gets split. A module below `minSize` (default 20000 bytes) will not become its own chunk regardless of `cacheGroups` targeting, unless a cache group's own `enforce: true` overrides that.
+2. **Confirm `chunks` scope per cache group, not just globally.** A global `chunks: 'async'` with a `vendor` cache group that doesn't override `chunks: 'all'` will not split vendor code out of the initial/entry bundle — only out of dynamically-imported chunks. This is the most common "I added a vendor cache group and nothing changed in the initial bundle" defect.
+3. **Pair any named vendor cache group with `runtimeChunk: 'single'` when the goal is long-term-caching stability**, and say so explicitly if the config is missing it — otherwise the vendor chunk's cache-busting behavior won't match what the team expects.
+4. **Do not propose a broad `test: /node_modules/` single-vendor-chunk config as a default recommendation.** Per Webpack's own docs, this is an explicit trade-off (fewer, larger, more cache-stable chunks vs. finer-grained, more parallel-loadable chunks), not a universal best practice — surface it as a choice with a named trade-off, not a fix.
+5. **Confirm the installed Webpack major before asserting any specific default value** (e.g., `minSize: 20000`) — quote the value from `mcp__Context7__query-docs` against the confirmed major rather than this reference's cached snapshot, since defaults have changed across majors historically.
+6. **Distinguish `optimization.splitChunks` (automatic, heuristic-driven) from explicit multi-entry configuration** (`entry: { index: ..., another: ... }`) — a duplicate-dependency finding across two *entry points* (not two dynamically-split chunks) is a `splitChunks` cache-group problem, not an entry-config problem; do not propose merging entries as the fix when the actual defect is a missing/misconfigured cache group.
+
+## Verification targets
+
+- The confirmed Webpack major and the full resolved `optimization.splitChunks` object (defaults plus overrides), not just the cache-group diff.
+- The `chunks` scope value effective for the specific cache group in question (group-level override, if present, wins over the global setting).
+- A build stats output (`webpack --json` or `webpack-bundle-analyzer` treemap) confirming the proposed cache-group change actually produced the intended chunk split, with a before/after chunk-name and chunk-size comparison.
+- Whether `runtimeChunk` is configured, when reviewing a named vendor cache group intended for long-term-caching stability.

package/skills/frontend/bundle-budget-code-splitting-review/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: bundle-budget-code-splitting-review
+description: Reviews JavaScript/CSS bundle composition against explicit numeric budgets, evaluates route- and component-level code-splitting boundaries, and requires a CI-enforced budget before endorsing any size fix as resolved.
+allowed-tools: Read Grep Glob Bash(npm run build:*) Bash(du:*)
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: operational
+---
+
+# Bundle Budget & Code-Splitting Review
+
+## Purpose
+
+Teams routinely respond to "the bundle feels big" with an ad hoc `React.lazy()` here and a dynamic `import()` there, ship it, and call the finding closed once the build succeeds. That proves nothing: it does not show whether the total byte weight moved, whether the change reduced or inflated the request count, or whether the win survives the next dependency bump. This skill turns "bundle feels big" into a numeric, device/network-scoped budget tied to INP/TTI, ranks analyzer output by both byte weight and main-thread execution cost, classifies each contributor into a specific remediation path, and refuses to mark a size finding resolved without a CI-enforced budget check — a one-time manual fix without an enforced budget is a regression waiting to happen.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- reduce JavaScript or CSS bundle size,
+- review a bundle-analyzer report (webpack-bundle-analyzer, rollup-plugin-visualizer, or equivalent stats output),
+- set or enforce a performance budget for a route or shared entry,
+- decide where to add route-level or component-level code splitting,
+- assess the size impact of adding a new dependency before it merges.
+
+## When NOT to use
+
+- Pure image/media asset optimization — different budget class (bytes-per-image, format/compression), different tooling; not this skill's concern.
+- Server-side bundle or cold-start size for a serverless/edge function — different runtime, not the client-bundle budget this skill enforces.
+- Deciding whether a chunk's *contents* are dead code once it is correctly split — hand off to `tree-shaking-dead-code-review` for that specific question; a chunk can be correctly split and still be full of unused exports, which is a distinct defect from a splitting-boundary defect.
+- Diagnosing which Core Web Vitals sub-phase is regressing before a cause is known — hand off to `core-web-vitals-triage` first if the user only has a vague "it feels slow" complaint with no analyzer report yet; return here once JS weight is confirmed as the dominant contributor.
+
+## Context7 Documentation Protocol
+
+Bundler chunking APIs are version-sensitive and have changed shape recently — do not prescribe a config from memorized training data.
+
+1. Call `ToolSearch` with query `"context7"` (or `"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs"`) to load the Context7 tools if not already loaded this session.
+2. Call `mcp__Context7__resolve-library-id` for the bundler in scope (Vite, webpack, Rollup, esbuild, Rolldown) before prescribing any chunking configuration.
+3. Call `mcp__Context7__query-docs` for the specific mechanism — e.g. "manualChunks vs codeSplitting", "splitChunks cacheGroups", "dynamic import chunk naming" — before ruling on it. Do this per review; do not reuse a prior session's memory of bundler internals.
+4. Known version-sensitive trap verified via Context7 as of this skill's `updated` date: Vite 8 (Rolldown-powered) removes the object form of `build.rollupOptions.output.manualChunks` entirely and deprecates the function form; the documented replacement is `build.rolldownOptions.output.codeSplitting` with a `groups` array (`{ name, test }` entries). Do not hand a Vite 8+ project a `manualChunks: { vendor: [...] }` object-form snippet — it will not apply. For Vite <8, function-form `manualChunks(id) { ... }` is still valid but is itself deprecated and should be flagged as a forward-migration item, not endorsed as the long-term pattern.
+5. webpack's chunking surface (`optimization.splitChunks.cacheGroups`, dynamic `import()` with `webpackChunkName` magic comments) is comparatively stable across recent majors per Context7-grounded docs, but still confirm the installed webpack major before prescribing a specific `cacheGroups` shape, since defaults (`chunks: 'async'` vs `'all'`) affect which imports are eligible for splitting.
+6. If Context7 is unavailable or returns no relevant match for the installed bundler, fall back to `official_docs` and mark the claim `documentation-based (Context7 unavailable)` rather than presenting it as freshly verified.
+7. Never invent a bundler config key, CLI flag, or plugin option that no queried source confirms.
+
+## Lean operating rules
+
+- Establish the numeric budget before ranking anything. A budget with no device/network class and no percentile is not a budget — it is a guess. Refuse to close a finding against an undefined budget.
+- Rank analyzer contributors by both parsed/gzipped byte size and main-thread execution cost; these produce different orderings, and execution cost correlates more directly with INP than raw byte size does. Report both, do not collapse them into one number.
+- Classify every large module into exactly one path: needed on the critical path (keep, minimize), needed but deferrable (route/component-split candidate), duplicated across chunks (fix chunk-grouping config, not application code), or a heavier-than-necessary dependency (replace, or hand off to `tree-shaking-dead-code-review` if the issue is unused exports rather than the dependency itself).
+- Treat over-splitting as a real regression, not just under-splitting. Every new chunk is a new request; if the aggregate request-overhead cost (connection reuse aside, still parse/eval/scheduling cost) offsets the byte savings, the split is net-negative. Require the byte-vs-request-count comparison before endorsing a split.
+- Confirm the installed bundler major version via Context7 before prescribing `manualChunks`, `rolldownOptions.codeSplitting`, or `splitChunks` syntax — see Context7 Documentation Protocol. Do not assume a memorized API is still current.
+- Never accept "it built without errors" as evidence a split is beneficial. Require a before/after byte comparison from the analyzer output, gzipped or brotli as configured for production.
+- Flag any dynamic `import()` whose module specifier is built from unsanitized user input as a code-injection risk, not merely a performance nit — this is a security-relevant finding, not a style note.
+- Do not recommend inlining third-party scripts to "save a request" without naming the CSP/subresource-integrity trade-off of inlined vs. externally loaded, SRI-checkable code.
+- Require a CI-enforced budget (bundlesize, Lighthouse CI budget, or bundler-plugin size-limit check) as a condition of marking any size finding resolved. A manual one-time fix with no enforcement is not a fix, it is a snapshot.
+
+## References
+
+Load these only when needed:
+
+- [Budget methodology](references/budget-methodology.md) — use when the user has no existing budget, or an existing budget lacks a device/network class or percentile, and one must be established or corrected.
+- [Bundler chunking APIs](references/bundler-chunking-apis.md) — use when prescribing or reviewing Vite, webpack, or Rollup chunking configuration; contains the version-sensitive API grounding.
+- [Code-splitting boundaries](references/code-splitting-boundaries.md) — use when deciding where to add route- or component-level splitting, or when diagnosing duplicated-dependency-across-chunks and over-splitting.
+- [CI enforcement and verification](references/ci-enforcement-and-verification.md) — use for every review to specify the CI-enforced budget mechanism, the verification command, and the adversarial checklist before closing the finding.
+
+## Response minimum
+
+Return, at minimum:
+
+- the numeric budget in scope (bytes, compression form, device/network class, percentile), stated explicitly or flagged as missing,
+- the ranked contributor list with both byte size and main-thread execution-cost figures,
+- per-item classification (keep / split / replace / dead-code-handoff / chunk-grouping-fix) with the concrete config diff, version-confirmed against the installed bundler major,
+- the CI-enforced budget definition to add, not just a one-time manual fix,
+- the verification command (`npm run build -- --report` or the project's equivalent analyzer invocation) and the request-count check confirming the split did not net-negative the change.

package/skills/frontend/bundle-budget-code-splitting-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "bundle-budget-code-splitting-review",
+  "name": "Bundle Budget & Code-Splitting Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews JavaScript/CSS bundle composition against explicit numeric budgets, ranks analyzer contributors by byte weight and main-thread execution cost, evaluates route- and component-level code-splitting boundaries against version-confirmed bundler chunking APIs, and requires a CI-enforced budget before endorsing any size fix as resolved, loaded progressively.",
+  "source_type": "original",
+  "official_docs": [
+    "https://web.dev/articles/reduce-javascript-payloads-with-code-splitting",
+    "https://web.dev/articles/your-first-performance-budget",
+    "https://vite.dev/guide/build.html",
+    "https://webpack.js.org/guides/code-splitting/",
+    "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules/Dynamic_module_loading",
+    "https://webpack.js.org/plugins/split-chunks-plugin/"
+  ],
+  "security_notes": "Do not recommend inlining third-party scripts to save a request without disclosing the CSP/subresource-integrity trade-off of inlined vs. externally loaded, SRI-checkable code. Flag any dynamic import() of a module specifier built from unsanitized user input as a code-injection risk, not merely a performance concern. Do not accept or echo any credential-shaped string found in a pasted build config or analyzer report as if it were safe to keep in the transcript.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/bundle-budget-code-splitting-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/bundle-budget-code-splitting-review/references/budget-methodology.md

@@ -0,0 +1,36 @@
+# Budget Methodology
+
+Use this reference when the user has no existing performance budget, or an existing budget is missing a device/network class, a compression form, or a percentile — establish or correct it before ranking anything against it.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "Keep the bundle small" is a budget.
+
+It is not. A budget with no number is a slogan. A number with no device/network class and no percentile is a coin flip about whose experience it describes. Per web.dev's performance-budget guidance, a usable budget names:
+
+1. **the metric being bounded** — total JS/CSS transfer bytes, per-route transfer bytes, or a timing metric (TTI/INP) the byte budget is a proxy for,
+2. **the compression form** — gzip or brotli, matching what production actually serves; raw/uncompressed bytes overstate the number users pay for, and mixing forms across comparisons invalidates the comparison,
+3. **the device/network class** — a mid-tier mobile CPU on a throttled "good 4G" profile is a meaningfully different budget than an unthrottled desktop; web.dev's budget guidance frames budgets in terms of a target device class precisely because bundle-parse/execution cost scales with CPU, not just network time,
+4. **the percentile** — p75 is the conventional anchor (it is also the percentile Core Web Vitals field assessment uses), not the best-case or median session.
+
+## Establishing a budget when none exists
+
+1. Ask (or infer from existing CI config, `lighthouserc`, `bundlesize.config.json`, or a `size-limit` entry) whether a budget already exists in any form. Do not assume none exists just because this review wasn't asked to check.
+2. Anchor the budget to a route classification, not a single global number:
+   - **critical path / shared entry** — loaded on every route; tightest budget, since it blocks first render everywhere.
+   - **secondary route** — route-specific bundle loaded via code splitting; budget can be looser since it does not block other routes.
+   - **vendor chunk** — third-party dependency weight; budget separately from application code so a dependency bump is caught distinctly from an application-code regression.
+3. State the number in gzipped (or brotli, matching production) bytes, tied to p75 on the project's target device/network class. If the project has no stated target device/network class, default to a mid-tier mobile device on a throttled "good 4G" profile per web.dev's stated default budget context, and say explicitly that this default was assumed, not confirmed with the user.
+4. Tie the byte budget back to a timing outcome (TTI or INP) where possible — a byte number with no timing justification is arbitrary. State the reasoning explicitly (e.g., "X KB of parse/execute cost on the target device class corresponds to roughly Y ms of main-thread blocking, which risks the INP budget").
+
+## Correcting an existing but underspecified budget
+
+If a budget exists but is missing a device/network class or a percentile, do not silently adopt it as sufficient. State the gap explicitly as a finding, propose the missing dimension using the defaults above, and note that the corrected budget needs sign-off before being treated as CI-enforceable — see [CI enforcement and verification](ci-enforcement-and-verification.md).
+
+## Non-negotiables
+
+- Do not rank an analyzer report against a budget that has no stated compression form — a byte number with unstated compression is not comparable to anything.
+- Do not accept "under 250 KB" with no percentile or device class as a complete budget; treat it as a starting number that needs the missing dimensions filled in before enforcement.
+- Do not invent a budget number without grounding it in either the project's existing target (stated by the user, present in CI config) or web.dev's documented default budget context — state which one was used.