@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/sveltekit-routing-load-review/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: sveltekit-routing-load-review
+description: Statically review SvelteKit route files (+page.js, +page.server.js, +layout.js, +layout.server.js, +server.ts) to verify universal-vs-server load placement, catching server-only secrets, database clients, or privileged API access that would leak into or execute inside the browser.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# SvelteKit Routing & Load Function Review
+
+## Purpose
+
+Review SvelteKit route files for correct universal-vs-server `load` function placement without re-litigating progressive-enhancement UX, form-action design, or component styling in every response. This skill exists because SvelteKit's universal `load` functions (`+page.js` / `+layout.js`) run on the server for the initial SSR render **and again in the browser** on every subsequent client-side navigation — a fact that is routinely missed and turns a misplaced database call or secret reference into a client-side credential exposure, not just a style defect.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a new or changed SvelteKit route's `load` functions before merge,
+- investigate a secret, database error, or unexpected network call surfacing in the browser console or network tab for a SvelteKit route,
+- determine whether data-fetching for a given route is placed in the correct file (`+page.js` vs `+page.server.js`, `+layout.js` vs `+layout.server.js`),
+- audit `+layout`/`+page`/`+server` file precedence for a route tree.
+
+Do not use this skill for:
+
+- progressive-enhancement or `<form>` action / `use:enhance` UX review — use `sveltekit-progressive-enhancement-review` instead,
+- pure component-internal state with no `load` function involved,
+- live performance profiling of load waterfalls — that needs runtime tracing, not static review.
+
+## Context7 Documentation Protocol
+
+- Resolve the library ID with `resolve-library-id` (matched result: `/sveltejs/kit`) before citing any SvelteKit-specific claim.
+- Before asserting the universal-vs-server execution model, call `query-docs` against `/sveltejs/kit` for "load functions" and quote the precise rule: a universal `load` (`+page.js`/`+layout.js`) runs on the server during SSR and hydration, then runs **again in the browser** on every subsequent client-side navigation (or always in the browser if SSR is disabled / the route is a SPA); a server `load` (`+page.server.js`/`+layout.server.js`) always runs only on the server. If both exist for a route, the server `load` runs first and its return value becomes the `data` property passed into the universal `load`.
+- Verify the SvelteKit major version installed in the repo (`package.json`) before asserting version-specific behavior of `$env/static/private` / `$env/dynamic/private` enforcement or server-only module protection — this has evolved across releases (private `$env/*` client-side imports were blocked starting in a 1.0-pre release).
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+- Never assume a repo's SvelteKit config (`kit.env.privatePrefix`, adapter, `ssr`/`csr` page options) matches defaults without reading `svelte.config.js` and any per-route page-option exports — page options change when/whether a universal `load` ever runs on the server at all.
+
+## Lean operating rules
+
+- First classify every load-bearing route file as universal (`+page.js`, `+layout.js`) or server (`+page.server.js`, `+layout.server.js`) by filename suffix alone — never by guessing from content or route name.
+- Treat every universal `load` function as browser-reachable code, full stop. It is not "mostly server-side" or "server-side on first load" — SvelteKit re-runs it client-side on every subsequent navigation by default.
+- Do not assume SvelteKit's build-time `$env/static/private` / `$env/dynamic/private` import guard catches every leak. It blocks direct imports of those modules from client-reachable files, but it does not catch manual `process.env` reads, a `$lib/server`-protected module re-exporting a secret through a non-`.server` module, or a secret being copied into the plain object a server `load` returns.
+- Trace secrets and DB clients through the full import graph, including transitive `$lib` imports — a universal `load` that imports an innocuous-looking `$lib/utils.js` which itself imports `$lib/server/db.js` is still a leak path (and SvelteKit's server-only module protection should catch that specific case at build time; verify it does, do not assume).
+- Treat any private value present in the plain object a server `load` (or `+layout.server.js`) returns as a candidate leak the moment a universal `load`, a client component, or `page.data`/`$page.data` can read it — server `load` output crosses the server/client boundary via devalue serialization, it is not automatically safe just because it originated server-side.
+- Never mark a `+page.server.js` or `+layout.server.js` file itself as a browser-exposure risk for containing secrets or DB calls — those files are always server-only by SvelteKit's routing contract; the risk is in what they choose to *return*, not that they execute.
+- Do not flag deep or repeated `+layout.server.js` logic as a leak; flag it as a MEDIUM duplication/maintainability finding only, distinct from HIGH-severity leak findings.
+- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the leak-tracing decision tree, and the required output shape.
+- [Routing conventions](references/routing-conventions.md) — load only when `+layout`/`+page`/`+server` file precedence or route-tree structure (not just load placement) is in question.
+
+## Response minimum
+
+Return, at minimum:
+
+- the route(s) and file(s) in scope, each labeled universal or server load,
+- ranked findings with file:line evidence and the full import/data-flow trace for any leak finding,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`),
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., unverified `svelte.config.js` env prefix, unread transitive `$lib` module).

package/skills/frontend/sveltekit-routing-load-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "sveltekit-routing-load-review",
+  "name": "SvelteKit Routing & Load Function Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews SvelteKit route files for correct universal-vs-server load placement, preventing server-only logic from executing in the browser.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kit.svelte.dev/docs/load",
+    "https://kit.svelte.dev/docs/routing",
+    "https://svelte.dev/docs/kit/load",
+    "https://svelte.dev/docs/kit/routing"
+  ],
+  "security_notes": "Server-only secrets, database clients, or privileged third-party API keys reachable from a +page.js/+layout.js (universal load, which runs in the browser too) is a credential-exposure defect — escalate as HIGH, not a style preference. Static-review-only skill: it reads and greps route source but never executes, builds, or runs application code.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/sveltekit-routing-load-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/sveltekit-routing-load-review/references/routing-conventions.md

@@ -0,0 +1,35 @@
+# Routing Conventions: File Roles and Precedence
+
+Use this reference only when a review also needs to assess `+layout`/`+page`/`+server` file precedence or route-tree structure — not for a load-placement-only review (see `workflow-and-output.md` for that).
+
+## Officially grounded file roles
+
+Per SvelteKit's routing documentation:
+
+- **`+page.svelte`** — the component rendered for a route.
+- **`+page.js`** — exports a universal `load` (typed `PageLoad`). Runs on the server during SSR/hydration, then again in the browser on subsequent client-side navigations (subject to page options).
+- **`+page.server.js`** — exports a server `load` (typed `PageServerLoad`), always server-only. Renaming `+page.js` to `+page.server.js` is the documented mechanism for moving a load function that needs a database or private env var out of universal-execution scope. Can also export form `actions`.
+- **`+layout.svelte`** — wraps child routes; layouts nest by directory structure.
+- **`+layout.js` / `+layout.server.js`** — same universal/server split as page equivalents, but the returned data is available to the layout's own component and to every child route via `await parent()`.
+- **`+server.js`/`+server.ts`** — exports HTTP method handlers (`GET`, `POST`, etc.) for a route, making it an API endpoint rather than a page. Always server-only.
+
+## Precedence and data flow
+
+- If a route has both a server `load` and a universal `load` (e.g., `+page.server.js` and `+page.js` in the same directory), **the server `load` runs first**. Its return value becomes the `data` property on the `LoadEvent` passed into the universal `load`. Do not describe these as running "in parallel" or "independently" — they are sequential and dependent.
+- A server `load`'s return value must be serializable via devalue (JSON-representable types plus `BigInt`, `Date`, `Map`, `Set`, `RegExp`, and repeated/cyclical references). A universal `load` has no such restriction and may return non-serializable values (component constructors, class instances, functions) — this asymmetry is a useful signal during review: if a "server load" is returning something devalue cannot serialize, either the classification is wrong or the code will fail at runtime, not just leak.
+- A `+layout.server.js`'s data is available to every nested route's `load` via the `parent()` function — trace `parent()` calls when checking whether a leak in a layout's server `load` return value actually reaches a specific deeply nested universal `load`.
+- Prerendered routes invoke `load` at build time, not per-request — flag this distinction only if the review scope includes prerendering/page-option correctness; it does not change the leak-tracing rules above.
+
+## Review-relevant precedence pitfalls
+
+- Do not assume a `+page.server.js` with no corresponding `+page.js` implies the route has no client-reachable data flow — the server `load`'s return value still reaches the client as `data`/`$page.data` for the page component itself, even with no universal `load` present. Apply the same leak-tracing rules from `workflow-and-output.md` regardless of whether a sibling universal `load` exists.
+- Do not assume `+layout.js`/`+layout.server.js` data is scoped narrowly — it is available to the entire subtree beneath that layout, which widens the blast radius of any leak found there compared to a single `+page.js`.
+- A `+server.ts` in the same directory as a `+page.js`/`+page.server.js` is a separate concern from page load functions; do not conflate an API endpoint's own request-handling logic with the page's load-function review unless the page's universal `load` calls that endpoint via `fetch()`, in which case trace the endpoint's response shape for any leaked field the same way you would trace a server `load`'s return value.
+
+## When to push back
+
+Push back if the user asks you to:
+
+- "just put it in `+page.js` so it fetches faster" when the data source requires a private credential or database access — that is not faster, it is a credential-exposure defect.
+- treat a `+layout.server.js` leak as low-severity because "it's just the layout" — layout-scoped leaks reach a wider client-visible subtree than a single page's leak, not a narrower one.
+- skip verifying the installed SvelteKit version's `$env`/server-only-module enforcement because "the docs say it's blocked" — documentation describes the current release's behavior; it does not prove the repo's pinned version enforces it the same way.

package/skills/frontend/sveltekit-routing-load-review/references/workflow-and-output.md

@@ -0,0 +1,60 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure, the leak-tracing decision tree, and the required output shape for a SvelteKit routing/load review.
+
+> Version note: `$env/*` client-import enforcement and server-only module protection are Vite-plugin-driven and have evolved across SvelteKit releases. Verify the installed `@sveltejs/kit` version in `package.json` before asserting exact enforcement behavior; do not assume the latest documented behavior applies to an older installed version.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "`+page.js` is the client file and `+page.server.js` is the server file — as long as I don't put a DB call directly in `+page.js`, I'm safe."
+
+That is incomplete in two ways:
+
+1. `+page.js` (and `+layout.js`) are **universal** — SvelteKit runs them on the server for the first SSR render, then re-runs them **in the browser** for every subsequent client-side navigation. It is not "the client file"; it is "the file that runs in both places," and the browser-execution half is where secrets leak.
+2. A secret can leak without ever being imported into a universal `load` file directly — it leaks the moment it appears anywhere inside the plain object a server `load` *returns*, because that object is serialized (via devalue) and shipped to the browser as `data`/`$page.data` regardless of whether anything downstream "needed" it.
+
+## Step-by-step workflow
+
+1. **Inventory route files.** For every route directory in scope, list `+page.js`, `+page.server.js`, `+layout.js`, `+layout.server.js`, and `+server.ts`/`+server.js` present. Classify each by filename suffix alone: `.server.` → server load, otherwise → universal load. Do not infer classification from file content or route name.
+2. **Confirm page options.** Read any `export const ssr` / `export const csr` in `+page.js`/`+layout.js` for the route. If `ssr = false`, the "universal load runs server-first" assumption is void — the universal load runs client-only, in a SPA-style mount, from the start. If `csr = false`, the universal load never re-runs client-side on navigation (full-page reloads instead) — note this because it changes (lowers) the leak surface but should still be verified rather than assumed.
+3. **Trace each universal load's imports.** For every `+page.js`/`+layout.js` in scope, follow its import graph, including transitive `$lib` imports, looking for:
+   - direct imports from `$env/static/private` or `$env/dynamic/private` (SvelteKit's Vite plugin should block this at build time for client-reachable files — verify the repo's SvelteKit version actually enforces this, do not assume),
+   - imports of a module under `$lib/server/` or named `*.server.js`/`*.server.ts` (SvelteKit's server-only module protection should block this too — same verification caveat),
+   - manual `process.env.<SECRET>` reads that bypass both of the above guards,
+   - a database client (Prisma, Drizzle, raw driver, etc.) instantiated or imported directly.
+4. **Trace server-`load` return values.** For every `+page.server.js`/`+layout.server.js` in scope, inspect the object literal(s) returned by `load`. Flag any field that is a raw secret, API key, session token, or full DB-record dump not intended for client consumption — that object becomes `data` in the child universal `load` and `$page.data` in every component, i.e. it is client-visible the instant it is returned, independent of whether the universal `load` "does" anything with it.
+5. **Check route-tree precedence** only if `+layout`/`+page`/`+server` structural correctness is also in question — load `references/routing-conventions.md` for that sub-review.
+6. **Rank and report findings** per the output shape below.
+
+## Leak-tracing decision tree
+
+- Universal `load` (or a module it transitively imports) directly imports `$env/static/private`, `$env/dynamic/private`, or reads `process.env.<SECRET>` → **HIGH**. State whether the repo's SvelteKit version's build-time guard would catch this import path or whether it is a bypass (e.g., `process.env` read, or a non-`.server`-suffixed module outside `$lib/server/` that re-exports a value originally sourced from a private env var).
+- Universal `load` imports a `$lib/server/*` or `*.server.js` module directly → **HIGH** unless the repo's verified SvelteKit version enforces server-only module protection for that exact import path, in which case this is a build-time-blocked case; still flag it as a MEDIUM code-smell (the import should never have been attempted) rather than close the finding silently.
+- Server `load` (`+page.server.js`/`+layout.server.js`) returns an object containing a raw secret, token, or credential intended only for server-to-service calls → **HIGH**, regardless of whether any universal `load` or component currently reads that field. The leak is the serialization to the client, not the eventual consumption.
+- Server `load` output is consumed unchanged by a child universal `load` that then spreads or forwards it further (e.g., into a client-side third-party SDK init call) → **HIGH**, trace and cite both hops.
+- `+page.server.js`/`+layout.server.js` contains a DB call or secret access with no client-visible leak in its return value → **not a finding for this skill**; this is expected, correct placement.
+- Duplicate near-identical server `load` logic repeated across sibling `+page.server.js` files that could be consolidated into a shared `+layout.server.js` → **MEDIUM**, maintainability/duplication, not a security finding.
+- `+server.ts` (API route) referenced by a universal `load`'s `fetch()` call, where the `+server.ts` handler itself correctly guards secrets server-side → **not a finding**; note it as an alternative-pattern observation only if the review scope includes route-tree precedence.
+
+## Adversarial checklist
+
+Before closing a review with no HIGH findings, confirm:
+
+- Did you classify every file by filename suffix, not by assumption?
+- For every universal `load`, did you check `ssr`/`csr` page options before asserting when/whether it runs server-side vs. client-side?
+- Did you follow *transitive* `$lib` imports, not just the direct imports in the load file itself?
+- Did you inspect the actual object returned by every server `load`, not just whether it "looks like" it fetches sensitive data?
+- Did you verify the installed SvelteKit version's enforcement behavior for `$env/*/private` and server-only modules rather than assuming current docs apply unconditionally?
+- If you found zero leaks, is that because none exist, or because you didn't trace far enough?
+
+## Output shape
+
+Every review response must include:
+
+1. **Scope** — routes and files reviewed, each labeled universal-load or server-load (or both, if the route has paired files).
+2. **Findings** — ranked HIGH → MEDIUM → LOW, each with `file:line`, the classification (misplacement vs. leak vs. duplication), the full import/data-flow trace for any leak finding, and a concrete fix sketch (e.g., "move to `+page.server.js`" or "strip `apiKey` field from the returned object before it reaches `data`").
+3. **Evidence level** per finding: `repo evidence` (read the actual file/import), `documentation-based` (asserting SvelteKit's enforcement behavior from docs without confirming the installed version), or `inference` (plausible but unverified, e.g., a dynamic import you could not statically resolve).
+4. **Verdict** — approve / approve-with-notes / block. A single HIGH leak finding is a block.
+5. **Open questions** — anything the review could not verify (unread `svelte.config.js`, unresolved dynamic import, unconfirmed SvelteKit version).

package/skills/frontend/tree-shaking-dead-code-review/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: tree-shaking-dead-code-review
+description: Verifies that a bundler's tree-shaking actually eliminated dead code by inspecting output bytes and sideEffects/module-format configuration, rather than trusting a clean build as proof of elimination.
+allowed-tools: Read Grep Glob Bash(npm run build:*)
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: operational
+---
+
+# Tree-Shaking & Dead-Code Review
+
+## Purpose
+
+"The build succeeded" and "the code was tree-shaken" are unrelated claims. A production build with zero errors can still ship a fully dead, unreferenced module byte-for-byte, because tree-shaking is not a guaranteed pass — it is a conditional static-analysis optimization that silently no-ops the moment it hits a CJS `require`, a missing or wrong `sideEffects` field, a barrel-file re-export, or a development-mode build. This skill treats "eliminated" as a claim that must be proven from bundle-analyzer output bytes and module lists, before and after, in a production build — never inferred from build success, and never inferred from a `sideEffects: false` change applied without reading the target module for real side effects first, since that specific mistake causes silent runtime breakage (dropped polyfills, dropped CSS injection, dropped security-relevant initialization), not just a size regression.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- verify why a supposedly-unused import is still present in bundle-analyzer output,
+- evaluate whether a new dependency is tree-shakeable before it is added,
+- configure or review a `sideEffects` field in package.json for an app or a library the user is authoring,
+- explain why a `sideEffects: false` change either had no effect or broke something at runtime.
+
+## When NOT to use
+
+- General bundle-size triage with no specific dead-code suspicion yet — use `bundle-budget-code-splitting-review` first to establish the numeric budget and rank contributors; hand off here once a specific module is suspected of being fully unused rather than merely heavy.
+- Deciding route- or component-level code-splitting boundaries — that is a splitting-boundary decision, not an elimination-verification decision; `bundle-budget-code-splitting-review` owns it.
+- Diagnosing which Core Web Vitals sub-phase is regressing with no analyzer report yet — hand off to `core-web-vitals-triage` first, return here once dead code is the named suspect.
+
+## Context7 Documentation Protocol
+
+Tree-shaking configuration surface differs by bundler and has shifted across majors (Rolldown replacing Rollup inside Vite 7+, webpack's `sideEffects`/`usedExports` interaction, Rollup's `treeshake` preset system). Do not prescribe a fix 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 actually installed in the project (webpack, Rollup, or Vite/Rolldown) before prescribing any `sideEffects` or `treeshake` configuration — do not assume the bundler from the framework name alone.
+3. Call `mcp__Context7__query-docs` for the specific mechanism in question — e.g. "sideEffects array vs boolean", "treeshake.moduleSideEffects options", "production mode requirement for usedExports" — before ruling on it. Do this per review; do not reuse a prior session's memory of bundler internals.
+4. Context7-grounded facts to confirm, not assume:
+   - webpack: tree-shaking requires `mode: 'production'` (or `optimization.usedExports` explicitly enabled) to take visible effect; `sideEffects: false` in package.json additionally requires `optimization.providedExports` (on by default in production mode) to let webpack drop unused-export modules; a module with real side effects (e.g. CSS imports) must be listed explicitly, e.g. `"sideEffects": ["**/*.css"]`, or that side effect is silently dropped.
+   - Rollup: `treeshake` accepts `false`, a preset (`'smallest' | 'safest' | 'recommended'`), or a fine-grained object — `moduleSideEffects` (boolean, `'no-external'`, a string array, or a predicate function) and `propertyReadSideEffects` are the two options most often responsible for either under- or over-aggressive elimination.
+   - Vite 7+ ships Rolldown as its production bundler; `build.rollupOptions` is now an alias for `build.rolldownOptions` and is deprecated in favor of it — verify which option surface the installed Vite major actually documents before prescribing config keys.
+5. 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.
+6. Never invent a bundler config key, CLI flag, or `package.json` field that no queried source confirms.
+
+## Lean operating rules
+
+- Require confirmation the build ran in production mode before evaluating any tree-shaking claim. A development-mode build routinely skips or partially applies elimination by design; "it's still there in dev" proves nothing.
+- Determine the suspect dependency's actual module format from its package.json (`exports`/`module` with an `import` condition vs. a `main`/`require`-only CJS entry) — do not infer format from the package's popularity or age. CJS defeats static tree-shaking analysis regardless of bundler, and is the most common silent cause of "unused code that won't go away."
+- Check `sideEffects` in both the app's own package.json and the suspect dependency's package.json. A missing field or `sideEffects: true` tells the bundler to assume every import has a side effect and keep it — this is often correct behavior being mistaken for a bug.
+- Before proposing or accepting `sideEffects: false` on any module, read that module for top-level side-effecting code — global polyfills, CSS-in-JS injection, prototype patching, analytics auto-init, CSP nonce injection, sanitizer initialization. A false `sideEffects: false` claim is a correctness bug that ships silently; it will not show up as a build error.
+- Rule out a barrel-file re-export pattern (`import * as utils from './utils'`, or a package `index.js` that re-exports everything) in the app's own code before blaming the dependency — this is a common tree-shaking blocker that has nothing to do with the dependency's configuration.
+- Never accept "no build errors" or "the build completed" as proof of elimination. Require a bundle-analyzer or output-file diff showing the specific module or byte range is actually absent, taken from a production build, before and after the change.
+- After any `sideEffects: false` change, require a runtime smoke test of the affected surface, not just a rebuild — dropped initialization code fails at runtime, not at build time.
+- Confirm the installed bundler and its major version via Context7 before prescribing exact config syntax — see Context7 Documentation Protocol. Do not assume a memorized API is still current.
+
+## References
+
+Load these only when needed:
+
+- [Module format and sideEffects field](references/module-format-and-sideeffects.md) — use when determining whether a dependency is ESM or CJS, and when reading or writing the `sideEffects` field in package.json (webpack's flag semantics and the production-mode requirement).
+- [Rollup and Vite treeshake options](references/rollup-vite-treeshake-options.md) — use when the project is Rollup- or Vite/Rolldown-based and the review needs `treeshake.moduleSideEffects`, `propertyReadSideEffects`, or preset-level configuration.
+- [ESM/CJS interop and verification](references/esm-cjs-interop-and-verification.md) — use when the suspect module's format is ambiguous, when CJS interop is suspected as the blocker, and for the before/after diff and runtime-smoke-test verification workflow that closes out every review.
+
+## Response minimum
+
+Return, at minimum:
+
+- the module format (ESM/CJS) and `sideEffects` field state for both the app and the suspect dependency, cited from the actual package.json content read,
+- confirmation the evidence came from a production-mode build, not development mode,
+- the exact package.json or bundler-config change proposed, with syntax version-confirmed via Context7 against the installed bundler major,
+- the before/after bundle-analyzer byte and module-count diff proving elimination, not just build success,
+- a correctness caveat and runtime-smoke-test requirement whenever `sideEffects: false` is newly applied.

package/skills/frontend/tree-shaking-dead-code-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "tree-shaking-dead-code-review",
+  "name": "Tree-Shaking & Dead-Code Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Verifies that a bundler's tree-shaking actually eliminated dead code by inspecting output bytes, module format, and sideEffects/treeshake configuration against a production-mode before/after diff, rather than trusting a clean build as proof of elimination, loaded progressively.",
+  "source_type": "original",
+  "official_docs": [
+    "https://webpack.js.org/guides/tree-shaking/",
+    "https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking",
+    "https://rollupjs.org/configuration-options/#treeshake",
+    "https://nodejs.org/api/packages.html#packagejson-and-file-extensions",
+    "https://web.dev/articles/reduce-javascript-payloads-with-tree-shaking"
+  ],
+  "security_notes": "Do not recommend blanket sideEffects: false on a package the reviewer has not verified is actually side-effect-free (e.g., polyfills, CSS imports, analytics auto-init) -- this silently drops required initialization code, which is a correctness bug, not just a size issue, and can remove security-relevant setup such as CSP nonce injection or sanitizer initialization. Require a runtime smoke test, not just a rebuild, after any sideEffects: false change. Do not accept or echo any credential-shaped string found in a pasted build config, package.json, or analyzer report as if it were safe to keep in the transcript.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/tree-shaking-dead-code-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/tree-shaking-dead-code-review/references/esm-cjs-interop-and-verification.md

@@ -0,0 +1,57 @@
+# ESM/CJS Interop and the Verification Workflow
+
+Use this reference when the suspect module's format is ambiguous, when CJS interop is suspected as the actual blocker, and for the before/after diff and runtime-smoke-test steps that close out every review in this skill.
+
+## What people get wrong
+
+The naive story is:
+
+> I imported it with `import`, so it's an ES module now.
+
+Wrong. Writing `import x from 'pkg'` in your own source does not change what `pkg` itself is. Per Node.js's package.json documentation, a package's actual module system is determined by its own `"type"` field, its `"exports"` map conditions, and file extensions (`.mjs`/`.cjs` override `"type"`) — not by the syntax the *importer* happens to use. Bundlers perform CJS/ESM interop specifically so that `import`-syntax consumers can still consume CJS packages, and that interop is exactly what defeats static tree-shaking: the bundler cannot statically prove which of a CJS module's dynamically-assigned `module.exports` properties are unused, so it must keep the whole thing.
+
+## Diagnosing interop as the cause
+
+Before concluding a bundler configuration is wrong, rule out CJS interop as the actual and unfixable-by-config cause:
+
+1. Check the dependency's `package.json` `"exports"` map for an `"import"` condition pointing at a real ESM build. If the only entry is `"require"` or a bare `"main"` pointing at a `.js` file with no `"type": "module"`, the package is CJS-only at that entry point — no bundler `sideEffects` or `treeshake` setting will make it statically analyzable.
+2. Check whether the package ships *both* CJS and ESM builds but exposes only a barrel-style default export from the ESM entry (e.g. `lodash-es`'s top-level `index.js` re-exporting every function) versus a per-function subpath (`lodash-es/debounce`). Importing the barrel entry can still pull in far more than needed even when the package is technically ESM, because the bundler must still resolve and analyze the whole re-export graph; importing the specific subpath sidesteps that entirely and is usually the more reliable fix regardless of `sideEffects` configuration.
+3. Check the app's *own* code for a barrel-file pattern before blaming the dependency at all: `import * as utils from './utils'` where `./utils/index.js` re-exports every internal module, or a component library's internal `index.ts` that re-exports every component. This is one of the most common tree-shaking blockers and has nothing to do with any external dependency's configuration — the fix is importing the specific submodule directly, or restructuring the barrel to preserve per-export side-effect metadata the bundler can act on.
+
+## Example: the "why is lodash still in my bundle" case
+
+A report of "lodash is in the bundle even though we only use `lodash-es`'s `debounce`" is almost always one of:
+
+- The app actually imports from the CJS `lodash` package somewhere (a transitive dependency, or a stray import), not `lodash-es` — confirm via the analyzer's module-resolution path, not the package name alone.
+- The app imports the `lodash-es` barrel default (`import _ from 'lodash-es'` or `import { debounce } from 'lodash-es'`) rather than the subpath (`import debounce from 'lodash-es/debounce'`). Named imports from a barrel *can* still tree-shake correctly under a fully ESM, side-effect-clean barrel, but many barrels re-export in ways that retain more than expected — subpath import is the more reliable fix and should be verified by diff, not assumed to work either way.
+
+Recommend the narrowest import path the package actually exposes, then confirm via analyzer diff that only the intended submodule remains — do not close the finding on the recommendation alone.
+
+## The verification workflow
+
+Every finding in this skill closes only with evidence, not a config change alone:
+
+1. **Confirm production mode.** Re-run (or ask for) the project's production build command. A development-mode analyzer run is not admissible evidence either for "it's broken" or "it's fixed."
+2. **Capture the before state.** Record the suspect module's presence and byte size (parsed and gzipped/brotli, matching how the project already measures) from the analyzer output.
+3. **Apply the narrowest fix.** Prefer, in order: correcting an app-side barrel import → correcting a `sideEffects` field with side-effecting files explicitly listed → switching to a bundler-level `moduleSideEffects`/`treeshake` override only when the first two do not apply → replacing a CJS-only dependency with an ESM-native alternative or its narrowest subpath.
+4. **Capture the after state.** Re-run the identical production build and analyzer command. Diff module list and byte counts against the before state.
+5. **Runtime smoke test, mandatory whenever `sideEffects: false` changed.** Load the affected page or component in the built (not dev-server) output and confirm styling, polyfilled behavior, and any global registration the module was responsible for still function. A passing build after `sideEffects: false` proves nothing about runtime correctness — that field's entire failure mode is silent at build time.
+
+## Hard stops
+
+- Do not apply `sideEffects: false` without having read the target module for top-level side effects.
+- Do not claim tree-shaking success, or failure, from a development-mode build.
+- Do not treat "no build errors" as proof of elimination in either direction.
+- Do not close a finding without a before/after analyzer diff attached.
+
+## Adversarial checklist
+
+Before closing any review under this skill, confirm:
+
+- Was the diff taken from a production build, not development mode?
+- Is the dependency's actual module format verified from its own `package.json`, not assumed from its name or popularity?
+- If `sideEffects: false` was applied or proposed, was the target module's source actually read for side effects first?
+- Is a barrel-file import pattern in the app's *own* code ruled out as the real blocker, separately from the dependency's configuration?
+- Was a runtime smoke test performed after any `sideEffects: false` change, not just a rebuild?
+
+If any answer is no, the review is not done.

package/skills/frontend/tree-shaking-dead-code-review/references/module-format-and-sideeffects.md

@@ -0,0 +1,61 @@
+# Module Format and the sideEffects Field
+
+Use this reference when determining whether a dependency is structurally tree-shakeable, and when reading or writing the `sideEffects` field for webpack-family bundlers.
+
+## What people get wrong
+
+The naive story is:
+
+> The bundler is smart enough to figure out what's unused. If it doesn't, the bundler is broken.
+
+Wrong. Tree-shaking is a conditional optimization built on two independent prerequisites, and if either is missing the bundler is not broken — it is behaving exactly as documented:
+
+1. The module must be statically analyzable ES modules (`import`/`export`), not `require`/`module.exports`.
+2. The bundler must be told, explicitly or by default assumption, which modules have no side effects, so it is safe to drop unreferenced exports.
+
+Neither prerequisite is automatic. Both must be verified, not assumed.
+
+## Module format: the first gate
+
+Static analysis of `import`/`export` bindings is what lets a bundler know, at build time, exactly which exports are used and which are not. `require()` calls are dynamic and CommonJS's `module.exports` object can be mutated at runtime in ways a static analyzer cannot fully prove safe — so a CJS module is generally not tree-shakeable, regardless of which bundler processes it.
+
+Check module format from the dependency's own `package.json`, not from assumption:
+
+- An `"exports"` field with an `"import"` condition, or a top-level `"module"` field pointing at an ESM build, signals the package ships (or can ship) ES modules.
+- A `"main"` field with no ESM entry point, or a package that only exposes `require()`-compatible output, is CJS-only. Static tree-shaking of that package's internals is not achievable through configuration; the fix is choosing a narrower import path the package exposes, or an ESM-native alternative.
+
+Do not assume format from the package's popularity, age, or name. Long-lived, widely used packages are exactly the ones most likely to still ship a CJS-only default entry for backward compatibility while also shipping an ESM build the app is failing to resolve.
+
+## The sideEffects field: the second gate
+
+Per webpack's own guidance, tree-shaking of unused *exports* within an otherwise-imported ESM module is a separate mechanism (`usedExports`) from tree-shaking of unused *whole modules* (`sideEffects`). The `sideEffects` field governs the latter: it tells webpack whether a module can be dropped entirely if none of its exports are referenced.
+
+- `"sideEffects": false` at the package level tells the bundler: assume nothing in this package has an import-time side effect; safe to drop any file whose exports are unused.
+- Omitting the field, or `"sideEffects": true`, tells the bundler to assume every file might have a side effect and to keep every imported file regardless of whether its exports are used.
+- A module that genuinely does have import-time side effects — CSS imports, global polyfills, prototype patching, analytics auto-registration — must be listed explicitly if the rest of the package is marked side-effect-free, e.g.:
+
+```json
+{
+  "name": "awesome-ui",
+  "sideEffects": ["**/*.css"]
+}
+```
+
+Marking the whole package `sideEffects: false` while a CSS import exists uninstrumented inside it will silently drop the CSS from the production bundle. This does not produce a build error. It produces broken styling in production that only shows up after deploy.
+
+## The production-mode requirement
+
+Per webpack's documented guidance, tree-shaking's user-visible effect (actual removal of dead code from output) requires `mode: 'production'`, or `optimization.usedExports` explicitly enabled in a non-production config. In development mode, webpack intentionally may keep `usedExports` analysis observable in the module graph without physically removing the code from the bundle, specifically so developers can inspect what *would* be removed. A development-mode bundle showing a module present is not evidence tree-shaking is broken — it may be evidence tree-shaking was never active for that build.
+
+`"sideEffects": false` additionally depends on `optimization.providedExports` to identify which exports are actually used before webpack can drop unused ones; this is enabled by default under `mode: 'production'`, but if a project runs a custom production-like config outside the `mode` shorthand, confirm the option is not disabled.
+
+## What to check, in order
+
+1. Confirm the analyzer output being reviewed came from a production-mode build. If not, stop and get one — nothing below is meaningful otherwise.
+2. Read the suspect dependency's `package.json` `exports`/`module`/`main` fields to determine module format.
+3. Read `sideEffects` on both the app's own `package.json` and the dependency's `package.json`.
+4. If proposing `sideEffects: false` (or adding a package to an existing `sideEffects` array as an exception), read the module's source for top-level side-effecting statements before proposing it — do not propose it from the field being merely absent.
+
+## Verification target
+
+A `package.json` diff and a bundle-analyzer module-list diff, both taken from a production build, one before and one after the change. "The build still succeeds" is not verification of either format or side-effect claims.

package/skills/frontend/tree-shaking-dead-code-review/references/rollup-vite-treeshake-options.md

@@ -0,0 +1,79 @@
+# Rollup and Vite Tree-Shaking Options
+
+Use this reference when the project bundles with Rollup directly, or with Vite (which bundles production builds through Rollup on Vite 5/6, and through Rolldown — a Rust reimplementation with a Rollup-compatible option surface — on Vite 7+). Confirm the installed major via Context7 before applying any snippet below; the option surface has moved.
+
+## What people get wrong
+
+The naive story is:
+
+> Rollup's ESM-first design means everything just gets tree-shaken automatically; there's nothing to configure.
+
+Incomplete. Rollup's `treeshake` option is not a single on/off switch — it accepts `false` (fully disabled), a named preset, or a fine-grained options object, and the two settings most responsible for either under-elimination or unsafe over-elimination are `moduleSideEffects` and `propertyReadSideEffects`, both of which default to conservative (safe but less aggressive) behavior unless explicitly overridden.
+
+## The treeshake option surface
+
+```javascript
+export default {
+  input: 'src/index.js',
+  output: { format: 'es', dir: 'dist' },
+  treeshake: {
+    moduleSideEffects: false,        // assume modules have no side effects
+    propertyReadSideEffects: false,  // property reads are side-effect-free
+    tryCatchDeoptimization: false,   // don't pessimistically include try-catch bodies
+    unknownGlobalSideEffects: false, // accessing unknown globals is safe
+    preset: 'smallest',              // or 'safest' / 'recommended'
+  },
+};
+```
+
+`treeshake` also accepts the boolean `true` (default behavior) or one of the preset strings directly (`'smallest' | 'safest' | 'recommended'`) without a full options object.
+
+### moduleSideEffects
+
+`moduleSideEffects` controls whether an entire imported module is retained even when none of its exports are used, mirroring in spirit what webpack's `sideEffects` package.json field does, but configured at the bundler level rather than (or in addition to) the package level. It accepts:
+
+- `boolean` — blanket true/false for all modules.
+- `'no-external'` — treat only external (`node_modules`) modules as side-effect-free; local project code keeps its analyzed side effects.
+- a string array — explicit module ID patterns to treat as side-effect-free.
+- a predicate function `(id, external) => boolean` for per-module logic.
+
+Setting this to `false` globally without auditing what actually lives in `node_modules` is the Rollup-side equivalent of the webpack `sideEffects: false` correctness trap: any dependency that performs import-time registration (polyfills, global CSS, `window` patches) will be silently dropped.
+
+### propertyReadSideEffects
+
+This governs whether Rollup assumes a property read (including getter invocation) can safely be removed if its result is unused:
+
+```javascript
+// Removed if treeshake.propertyReadSideEffects === false
+const foo = {
+  get bar() {
+    console.log('effect');
+    return 'bar';
+  },
+};
+const result = foo.bar;
+const illegalAccess = foo.quux.tooDeep; // would also throw at runtime if kept
+```
+
+Setting this `false` can eliminate code whose only purpose was a getter side effect (logging, lazy initialization, a Proxy trap). This is a narrower and less commonly needed lever than `moduleSideEffects` — do not reach for it as a first attempt to eliminate a stubborn module; confirm the actual blocker is a property read, not module-level retention, before touching this option.
+
+### External module elimination example
+
+```javascript
+// input
+import { unused } from 'external-a';
+import 'external-b';
+console.log(42);
+```
+
+With `treeshake.moduleSideEffects === true` (default-safe), both imports are retained even though `unused` is never referenced, because `moduleSideEffects: true` means Rollup assumes importing `external-a` and `external-b` might do something even without using their exports. With `moduleSideEffects: false`, both are dropped — which is correct only if neither package performs import-time work.
+
+## Vite / Rolldown specifics
+
+Vite's production build has historically gone through Rollup, exposed via `build.rollupOptions`. Starting with Vite 7.3.1, the production bundler is Rolldown, and `build.rollupOptions` is now documented as a deprecated alias for `build.rolldownOptions` — if both are set, `rollupOptions` is ignored and Vite emits a warning. Verify the installed Vite major via Context7 before choosing which option key to write into a config; a `rollupOptions.output.manualChunks` object-form snippet, or a Rollup-specific `treeshake` shape, is not guaranteed to carry over unchanged into `rolldownOptions`.
+
+`import.meta.env.DEV` and `import.meta.hot` guards are statically replaceable constants in Vite's build pipeline — code inside an `if (import.meta.env.DEV)` block is tree-shaken out of production builds by design. If a user reports dev-only code appearing in a production bundle, check whether the guard condition is actually one of these statically-analyzable forms rather than a runtime environment-variable read that the bundler cannot constant-fold.
+
+## Verification target
+
+A Rollup/Rolldown build with `--sourcemap` or the project's configured `rollup-plugin-visualizer`/equivalent output, diffed before and after any `treeshake` option change, on a production-mode build. Confirm via Context7 that the exact option key exists on the installed bundler version before writing it into config — `rollupOptions` vs `rolldownOptions` is the most likely place this silently drifts.

package/skills/frontend/typescript-contracts-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: typescript-contracts-review
+description: Review TypeScript diffs and tsconfig strictness posture for sound type contracts — auditing any/assertion usage at trust boundaries, unsound narrowing, and exported public-API type-surface breakage — so that a passing compile is meaningful evidence rather than a decorative pass, and requiring paired runtime validation wherever external data enters the type system.
+allowed-tools: Read Grep Glob Bash(git diff:*) Bash(tsc --noEmit:*) WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: compliance
+---
+
+# TypeScript Contracts Review
+
+## Purpose
+
+"The build passes" is only meaningful evidence of type safety if the active tsconfig is actually strict and the code doesn't defeat it with `any`, unchecked assertions, or broad suppression comments — and TypeScript types are fully erased at compile time, so a type annotation on external data (a parsed JSON response, a third-party SDK payload, a URL parameter) provides zero runtime protection unless paired with an actual runtime validator. This skill exists so those two failure modes — a loose or silently-weakened tsconfig, and type annotations that assert safety no runtime check backs up — get audited explicitly instead of being assumed away by a green checkmark. It also checks exported public-API type surfaces so a "just an internal refactor" diff doesn't silently break every downstream consumer of a published package.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a TypeScript/TSX diff for type-safety soundness before merge,
+- audit a codebase's tsconfig strictness posture against current TypeScript-recommended defaults,
+- check `any`/type-assertion/non-null-assertion usage, especially at external-data boundaries,
+- verify a discriminated union or type-guard function actually narrows correctly,
+- assess whether a change to an exported/published package breaks its public API type surface.
+
+Do not use this skill for:
+
+- pure runtime/logic bug hunting that has nothing to do with type contracts — that is a general code-review task,
+- JavaScript files with no type annotations or JSDoc types — there is no type contract to audit,
+- live `tsc --noEmit`/type-coverage execution results interpretation beyond what this static review can determine from the diff — report that a live run is needed rather than fabricating its result.
+
+## Context7 Documentation Protocol
+
+- Resolve the TypeScript library ID with `resolve-library-id` before ruling on any compiler-flag or strict-family question; do not answer from memory, because recommended defaults change across releases (confirmed via Context7: TypeScript 5.9's `tsc --init` now emits `noUncheckedIndexedAccess: true` and `exactOptionalPropertyTypes: true` as a separate "Stricter Typechecking Options" block alongside `strict: true`, where earlier `tsc --init` output only set `strict: true`).
+- Before asserting which individual flags `strict: true` bundles (`strictNullChecks`, `noImplicitAny`, `noImplicitThis`, `alwaysStrict`, `strictFunctionTypes`, `strictBindCallApply`, `strictPropertyInitialization`, `useUnknownInCatchVariables`), call `query-docs` against the current TypeScript docs rather than reciting a memorized list — the bundle is described as open-ended ("future versions of TypeScript may introduce additional stricter checking under this flag"), so a stale list under-reports what a repo's `strict: true` actually enables on its installed compiler version.
+- Before flagging or endorsing a `typescript-eslint` rule (e.g. `no-explicit-any`, `no-unsafe-assignment`, `no-non-null-assertion`), verify via `query-docs` whether that rule is in the repo's active shared config (`recommended`, `recommended-type-checked`, `strict-type-checked`) — rule membership across those tiers has changed between major versions (confirmed via Context7: the v7→v8 `recommended-type-checked` diff added/removed multiple rules), so do not assume a rule is enabled just because the repo extends a config by name without checking the installed version.
+- Read `package.json`/lockfile first to confirm the installed `typescript` and `typescript-eslint`/`@typescript-eslint/*` major versions before citing version-gated behavior (e.g. `exactOptionalPropertyTypes` semantics, `satisfies` operator availability, `const` type parameters) — do not assume a feature is available because it appears in current docs if the installed major predates it.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label every version-sensitive claim `documentation-based, unverified against installed compiler version`.
+
+## Lean operating rules
+
+- Never accept "the build passes" as sufficient evidence of type safety without checking the actual tsconfig strict-family flags in effect — a loose config proves far less than developers assume, and `strict: true` alone (pre-5.9 `tsc --init` default) does not imply `noUncheckedIndexedAccess` or `exactOptionalPropertyTypes` are on.
+- Every new `any` must carry an adjacent justification comment; flag unjustified `any` as blocking, especially inside application logic that later consumers trust as validated.
+- Every trust-boundary type (parsed JSON, third-party SDK response, `postMessage` payload, URL/query-param, form input, environment variable) must be paired with an actual runtime validator — a type annotation alone is erased at compile time and enforces nothing at runtime.
+- Treat any proposal to loosen existing tsconfig strictness (removing `strict`, disabling `strictNullChecks`) as requiring an explicit, separately-reviewed migration plan, not a routine PR change.
+- Flag broad `@ts-nocheck`/file-level suppression as blocking by default; require `@ts-ignore`/`@ts-expect-error` to carry an adjacent comment explaining why, weighted higher severity if the suppressed code is security- or trust-boundary-relevant.
+- Do not let generic-type complexity become unreadable; a type requiring a comment to explain what it constrains is a design smell worth simplifying, not a badge of sophistication.
+- Do not run or assert `tsc --noEmit` success from memory — invoke it or explicitly flag that CI must, rather than fabricating a compile-success claim.
+- When a diff touches an exported/published package's public surface, check for a breaking type change (removed export, narrowed parameter type, widened return type becoming a narrower consumer-facing type, added required property) before approving; a type-only change can still be a semver-breaking change even with zero runtime behavior difference.
+
+## References
+
+Load these only when needed:
+
+- [Strict-flag posture reference](references/strict-flag-posture.md) — use when auditing or recommending a tsconfig strict-family flag set, including which flags are bundled under `strict` vs. separately opt-in (`noUncheckedIndexedAccess`, `exactOptionalPropertyTypes`), and how to read a repo's actual effective config (including `extends` chains).
+- [Trust-boundary validation patterns](references/trust-boundary-validation.md) — use when auditing external-data ingestion points (API responses, `JSON.parse`, `postMessage`, URL parsing, form/env input) for paired runtime validation against their declared types.
+- [Public API surface diffing](references/public-api-surface-diff.md) — use when a diff touches an exported/published package and a breaking-change check against the previous public `.d.ts`/export surface is needed.
+
+## Response minimum
+
+Return, at minimum:
+
+- the tsconfig strictness posture summary (which strict-family flags are on/off vs. current TypeScript-recommended defaults, and the compiler version that posture was checked against),
+- the `any`/assertion audit for every new `any`, `as`, and `!` in the diff, each flagged with its justification or lack thereof and file:line evidence,
+- the trust-boundary validation audit for every external-data ingestion point touched, naming the missing or present runtime validator,
+- the public-API surface diff and any breaking-change flags, when the diff touches an exported package,
+- verdict (approve / approve-with-notes / block),
+- residual risk notes for anything requiring a live `tsc --noEmit`/type-coverage run beyond this static diff review.