@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/browser-compatibility-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: browser-compatibility-review
+description: Audit JS/CSS/HTML feature usage against the project's declared Browserslist/supported-browser matrix using Baseline and caniuse status data, flag unguarded non-Baseline usage, and verify feature-detection or polyfill fallback coverage, with per-feature caniuse/Baseline lookups loaded only for features actually in question.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: platform
+---
+
+# Browser Compatibility Review
+
+## Purpose
+
+"Works on my browser" is not a compatibility strategy. This skill checks used web-platform features against the org's actual declared supported-browser matrix (Browserslist config or an explicit browser-version list) using Baseline/caniuse status, and verifies that any feature outside "widely available" has a real feature-detection or polyfill fallback rather than a silent failure.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a PR using a new JS API, CSS feature, or HTML element for cross-browser risk,
+- audit the overall Baseline-status distribution of features used in a codebase,
+- decide whether a feature needs a polyfill, feature-detection gate, or is safe to use unguarded,
+- propose narrowing or widening the org's supported-browser matrix,
+- triage a browser-specific bug report.
+
+## Context7 Documentation Protocol
+
+Baseline status, caniuse support tables, and Browserslist/tooling behavior change on their own release cadences, independent of this skill's version — never assert a feature's Baseline tier, a browser's support version, or a config-syntax detail from memory.
+
+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 in this session.
+2. Call `mcp__Context7__resolve-library-id` for `web-features` (prefer `/web-platform-dx/web-features`) when grounding a Baseline-status claim (widely/newly/limited availability, `baseline_low_date`/`baseline_high_date` semantics) — do not paraphrase Baseline's tiering from memory.
+3. Call `mcp__Context7__query-docs` for the specific feature or mechanism in question — e.g. "compute Baseline status for a compat key", "getStatus for a web-features id" — before stating a feature's tier as fact. Do this per review, not once from a prior session's memory.
+4. For the exact per-feature per-browser support matrix (which browser version added support), prefer live lookups against `https://caniuse.com/` and MDN's browser-compatibility tables in `official_docs` over Context7 paraphrase — Context7's `web-features` package computes Baseline tiers from that same underlying data but is not the source of truth for a single browser-version cell.
+5. Browserslist's own config syntax and query semantics are not consistently resolvable in Context7 (verified: no dedicated `browserslist` library was found when this skill was authored) — treat any Browserslist query-syntax claim as `documentation-based (Context7 unavailable for this library)` and confirm it against the project's actual `.browserslistrc` / `package.json` `browserslist` key and the official `browserslist/browserslist` GitHub README rather than inventing query syntax.
+6. If Context7 returns no relevant match for a claim, fall back to the `official_docs` URLs and mark the claim `documentation-based (Context7 unavailable)` instead of presenting it as freshly verified.
+7. Never invent a Baseline tier, a caniuse support percentage, or a Browserslist query keyword that no queried source confirms.
+
+## Lean operating rules
+
+- Always check the feature against the project's actual declared Browserslist config or explicit browser-version list — never approve based on the reviewer's own current browser, and never assume a default matrix (e.g. `> 0.5%, last 2 versions, Firefox ESR, not dead`) applies without reading the project's own config.
+- Distinguish Baseline "Newly available" (recently reached cross-engine support, but by definition still excludes older browsers within the ~2.5-year newly-to-widely window) from "Widely available" (safe to use unguarded for most matrices) from "Limited availability" (requires a fallback). Treat these as the three tiers computed from `baseline_low_date` / `baseline_high_date`, not as marketing labels.
+- For any Limited-Availability feature, or a Newly-Available feature whose window excludes a browser/version actually in the project's matrix, verify a real `@supports`/feature-detection/polyfill exists and correctly gates the risky code path — do not accept an assertion that a fallback "exists" without reading the code that implements it.
+- Weigh polyfill bundle-size cost against the actual percentage of affected users (from real analytics/RUM data if available) rather than blanket-recommending every polyfill; a polyfill added for a browser with near-zero real traffic is often a worse tradeoff than accepting the gap.
+- Treat any hard failure (thrown exception, blank render, broken checkout) as strictly higher severity than cosmetic degradation (missing rounded corners, no animation), and prioritize findings accordingly.
+- Recommend supported-browser-matrix changes only as data-backed proposals to product/analytics owners — this skill does not unilaterally decide the org's matrix, it surfaces the gap and the tradeoff.
+- Never recommend disabling a security-relevant browser default (mixed-content blocking, SameSite cookie defaults, CSP enforcement, Permissions Policy) as a "compatibility workaround" — that is a security regression, not a fix, and must be flagged as such if proposed by the user.
+- Load reference files only for the review question actually in scope (single-feature triage vs full-codebase Baseline sweep vs matrix-change proposal); do not preload the full feature catalog for a one-feature check.
+
+## References
+
+Load these only when needed:
+
+- [Baseline status model](references/baseline-status-model.md) — use when determining or explaining the exact Baseline tier (widely/newly/limited) of a specific feature and what that tier does and does not guarantee for the project's matrix.
+- [Fallback verification patterns](references/fallback-verification-patterns.md) — use 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.
+- [Browserslist matrix interpretation](references/browserslist-matrix-interpretation.md) — use when reading, interpreting, or proposing a change to the project's `.browserslistrc`/`browserslist` config, or reconciling it with build-tool (Autoprefixer/Babel/postcss-preset-env) targets.
+
+## Response minimum
+
+Return, at minimum:
+
+- the feature(s) in scope and their exact Baseline status (widely / newly / limited, with the underlying date window if newly available),
+- the specific browsers in the org's declared matrix that lack support, if any, cited against the project's actual Browserslist/matrix config,
+- current fallback status (none / feature-detected / polyfilled) with the actual code shown, not an assertion,
+- severity distinction between hard failure and cosmetic degradation,
+- polyfill cost-vs-affected-user tradeoff note if a polyfill is recommended,
+- evidence label for every claim (`live evidence` from project config/code, `documentation-based`, or `inference`), and an explicit note when Context7 was unavailable for a cited claim.

package/skills/frontend/browser-compatibility-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "browser-compatibility-review",
+  "name": "Browser Compatibility Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Skill for auditing web-platform feature usage against the org's declared browser support matrix using Baseline/caniuse status, verifying graceful-degradation or polyfill coverage for any non-Baseline feature.",
+  "source_type": "original",
+  "official_docs": [
+    "https://web-platform-dx.github.io/web-features/",
+    "https://web.dev/baseline",
+    "https://caniuse.com/",
+    "https://github.com/browserslist/browserslist"
+  ],
+  "security_notes": "Static review only; never recommends disabling security-relevant browser defaults (mixed-content blocking, SameSite cookie defaults) as a compatibility workaround.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/browser-compatibility-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/browser-compatibility-review/references/baseline-status-model.md

@@ -0,0 +1,45 @@
+# Baseline Status Model
+
+Use this reference when determining or explaining the exact Baseline tier of a specific feature and what that tier does — and does not — guarantee for the project's own matrix.
+
+## What people get wrong
+
+The naive story is:
+
+> "Baseline: Widely available" means it works everywhere I need it to.
+
+Wrong. Baseline is computed against a fixed reference set of core browser engines (Chrome/Edge, Firefox, Safari — desktop and their mobile counterparts), not against the org's actual supported-browser matrix. A feature can be "Widely available" in Baseline terms and still be broken for a real user on an unsupported engine (older WebViews, embedded browsers, some enterprise-locked builds) that Baseline does not track at all. Baseline tells you about cross-engine standards convergence; it does not tell you about the org's own matrix.
+
+## Officially grounded tiers
+
+Per the `web-features` project's `compute-baseline` package (verified via Context7, `/web-platform-dx/web-features`):
+
+- Every computed status carries a `baseline` field with one of three effective values:
+  - `'high'` — **Widely available**. The feature has been supported by all core browser engines for roughly 30 months (2.5 years).
+  - `'low'` — **Newly available**. The feature just became supported across all core engines, but has not yet cleared the widely-available window.
+  - `false` — **Limited availability**. At least one core browser engine does not yet support the feature.
+- A `'low'`/newly-available result carries a `baseline_low_date` (when cross-engine support was first reached) and, once promoted, a `baseline_high_date` (when it crosses into widely-available, typically ~30 months after `baseline_low_date`).
+- `getStatus(featureId, compatKey)` returns the Baseline status for a feature that has completed the project's editorial review; `computeBaseline({ compatKeys, checkAncestors })` computes status for a set of raw compat keys, including features that have not undergone editorial review — treat the latter as provisional and say so.
+- `checkAncestors: true` matters for features that are only reachable through a parent capability gated behind a flag or prefix (e.g. an API method whose containing interface is itself experimental) — check ancestors before declaring a leaf API "supported."
+
+## Non-negotiable rules
+
+1. **Never collapse "Newly available" into "safe to use unguarded."** A feature that just crossed into `baseline: 'low'` explicitly excludes browser versions released before the cross-engine convergence date — if the project's matrix includes any browser version older than `baseline_low_date`'s corresponding release, the feature is Limited-Availability *for that project*, regardless of its global Baseline label.
+2. **Baseline is not the org's matrix.** Always re-derive the actual compatibility verdict against the project's declared Browserslist/matrix config (see `browserslist-matrix-interpretation.md`), not against Baseline's fixed reference set alone.
+3. **Editorial-reviewed vs computed-only status are not the same confidence level.** `getStatus` results have been through the web-features project's review process; raw `computeBaseline` results have not. Label computed-only results as provisional in the finding.
+4. **A single low-support browser in the matrix downgrades the whole finding.** If the matrix declares support for even one browser version below what the feature needs, the finding is "unguarded use of a Limited-Availability feature for this project," not "Widely available, no action needed."
+5. **Do not confuse Baseline tier with caniuse's raw percentage-of-global-usage figures.** caniuse usage stats answer "how many people, globally, use a supporting browser"; Baseline answers "has this converged across core engines." Both matter, but they answer different questions — cite whichever one actually grounds the claim being made, and do not substitute one for the other.
+
+## Verification targets
+
+- The Baseline `baseline` value and, if `'low'`, the `baseline_low_date` for the feature in question (via `mcp__Context7__query-docs` against `/web-platform-dx/web-features`, or the live `web-features` dataset / `https://web.dev/baseline`).
+- The per-browser support table for the feature on `https://caniuse.com/` or MDN's browser-compatibility table, to identify exactly which matrix-declared browser versions lack support.
+- The project's own Browserslist/matrix config (see `browserslist-matrix-interpretation.md`) to determine whether any excluded browser is actually in scope.
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a feature as "safe" solely because a badge or article calls it "Baseline" without stating which tier,
+- treat a computed-only (`computeBaseline`, no editorial review) result as an authoritative, final verdict,
+- ignore the project's own matrix because "Baseline says it's fine" — Baseline's reference set and the project's matrix are not the same thing, and conflating them produces false-negative compatibility reviews.

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.