npm - @decocms/start - Versions diffs - 0.39.0 → 0.40.1 - Mend

@decocms/start 0.39.0 → 0.40.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (34) hide show

package/.agents/skills/deco-to-tanstack-migration/references/commerce/README.md ADDED Viewed

@@ -0,0 +1,78 @@
+# Commerce & Widget Types Migration
+## Commerce Types
+Commerce types live in `@decocms/apps/commerce/types`. Import directly:
+```typescript
+import type { Product, AnalyticsItem, BreadcrumbList } from "@decocms/apps/commerce/types";
+```
+Key types available: `Product`, `ProductGroup`, `ProductListingPage`, `ProductDetailsPage`, `Offer`, `AggregateOffer`, `UnitPriceSpecification`, `ImageObject`, `PropertyValue`, `BreadcrumbList`, `SiteNavigationElement`, `Brand`, `Review`, `AggregateRating`, `Filter`, `FilterToggle`, `FilterRange`, `SortOption`, `PageInfo`, `Suggestion`, `Search`, `AnalyticsItem`, `AddToCartParams`.
+Replace old imports:
+```bash
+sed -i '' 's|from "apps/commerce/types.ts"|from "@decocms/apps/commerce/types"|g'
+sed -i '' 's|from "~/types/commerce"|from "@decocms/apps/commerce/types"|g'
+```
+## Commerce Utilities
+Also from `@decocms/apps`:
+```typescript
+import { mapProductToAnalyticsItem } from "@decocms/apps/commerce/utils/productToAnalyticsItem";
+import { parseRange, formatRange } from "@decocms/apps/commerce/utils/filters";
+```
+Replace old imports:
+```bash
+sed -i '' 's|from "apps/commerce/utils/productToAnalyticsItem.ts"|from "@decocms/apps/commerce/utils/productToAnalyticsItem"|g'
+sed -i '' 's|from "apps/commerce/utils/filters.ts"|from "@decocms/apps/commerce/utils/filters"|g'
+```
+## Widget Types
+CMS widget types are site-local since they're just string aliases. Create `~/types/widgets.ts`:
+```typescript
+export type ImageWidget = string;
+export type HTMLWidget = string;
+export type VideoWidget = string;
+export type TextWidget = string;
+export type RichText = string;
+export type Secret = string;
+export type Color = string;
+export type ButtonWidget = string;
+```
+Replace:
+```bash
+sed -i '' 's|from "apps/admin/widgets.ts"|from "~/types/widgets"|g'
+```
+## UI Components (Site-Local)
+Image, Picture, Seo, Theme etc. are **site-local components** -- they do NOT belong in `@decocms/apps`.
+Create these in `~/components/ui/`:
+- `Image.tsx` - thin `<img>` wrapper (accepts `preload`, `fit` props for API compat)
+- `Picture.tsx` - `<picture>` + `<Source>` wrapper
+- `Seo.tsx` - head meta tags (stub or real implementation)
+- `Theme.tsx` - CSS variable injection (stub or real)
+- `PoweredByDeco.tsx` - footer badge
+- `Video.tsx` - `<video>` wrapper
+- `SeoPreview.tsx` - admin SEO preview (stub)
+Replace:
+```bash
+sed -i '' 's|from "apps/website/components/Image.tsx"|from "~/components/ui/Image"|g'
+sed -i '' 's|from "apps/website/components/Picture.tsx"|from "~/components/ui/Picture"|g'
+```
+## Verification
+```bash
+grep -r 'from "apps/' src/ --include='*.ts' --include='*.tsx'
+# Should return ZERO matches
+```

package/.agents/skills/deco-to-tanstack-migration/references/css-styling.md ADDED Viewed

@@ -0,0 +1,156 @@
+# CSS / Tailwind v4 / DaisyUI Gotchas
+> oklch triplets, logical properties, DaisyUI collapse, theme prefixes, sidebar.
+## 15. DaisyUI v4 Theme in Preview Shell
+DaisyUI v4 with Tailwind v4's `@plugin "daisyui/theme"` scopes all color variables to `[data-theme="light"]`. The admin preview HTML shell (`/live/previews/*`) must include this attribute, or colors will be wrong.
+**Symptom**: Preview in admin shows default/missing colors while production looks correct.
+**Fix**: Configure the preview shell in `setup.ts`:
+```typescript
+setRenderShell({
+  css: appCss,
+  fonts: [...],
+  theme: "light",     // adds data-theme="light" to <html>
+  bodyClass: "bg-base-100 text-base-content",
+  lang: "pt-BR",
+});
+```
+The production HTML has `<html lang="pt-BR" data-theme="light">` set by the TanStack root layout. The preview shell must replicate this.
+## 17. SiteTheme is a Stub
+`Theme.tsx` returns `null`. Colors come from CSS at build time, not CMS at runtime.
+## 31. CSS Theme Class Prefixes Must Not Be Renamed
+**Severity**: HIGH — breaks all theme colors
+The original site uses `seasonal-*` CSS class prefixes for theme variables (e.g., `bg-seasonal-brand-terciary-1`, `text-seasonal-neutral-1`). During migration, do NOT rename these to `header-*`, `footer-*`, or any other prefix. The theme variables are defined centrally and all components reference the same `seasonal-*` namespace.
+**Fix**: Only change what React strictly requires: `class` → `className`, `for` → `htmlFor`. Preserve all original CSS class names exactly.
+## 37. DaisyUI v4 Collapse Broken with Tailwind v4
+**Severity**: MEDIUM — filter sidebars, FAQ accordions, any collapsible section renders collapsed
+DaisyUI v4's collapse component uses `grid-template-rows: auto 0fr` with `content-visibility: hidden` and expands via `:has(>input:checked)`. In combination with Tailwind v4, the expand chain breaks — content stays collapsed regardless of checkbox state.
+**Symptom**: Filter sidebar shows as empty space. Collapse titles may render but content is permanently hidden. Custom CSS overrides on `.collapse` conflict with DaisyUI's generated styles.
+**Fix**: Replace DaisyUI collapse with native `<details>/<summary>` HTML elements:
+```typescript
+// Before: DaisyUI collapse with hidden checkbox
+<div className="collapse">
+  <input type="checkbox" defaultChecked />
+  <div className="collapse-title">Category</div>
+  <div className="collapse-content">...filters...</div>
+</div>
+// After: Native HTML, works everywhere
+<details open className="group">
+  <summary className="cursor-pointer font-semibold">Category</summary>
+  <div className="mt-2">...filters...</div>
+</details>
+```
+## 40. Filter Sidebar Invisible Due to Background Color Match
+**Severity**: LOW — cosmetic, but confusing during development
+The aside element for search/category filters renders correctly in the DOM (proper width, height, content) but appears invisible because its background matches the page background (e.g., both `#E9E9E9`).
+**Symptom**: Filters appear "non-existent" even though they're in the DOM. Filter links are accessible but invisible.
+**Fix**: Add a contrasting background to the filter aside:
+```typescript
+<aside className="... bg-white rounded-lg p-4">
+```
+## 42. Tailwind v4 Logical vs Physical Property Cascade Conflict
+**Severity**: CRITICAL — causes container width mismatches across the entire site
+Tailwind v4 generates **logical CSS properties** (`padding-inline`, `margin-inline`) while Tailwind v3 generated **physical properties** (`padding-left`, `padding-right`). When an element has BOTH shorthand (`px-*`) and longhand (`pl-*`/`pr-*`) responsive classes, the cascade breaks silently.
+**Symptom**: Containers are narrower or have asymmetric padding compared to production. The layout "looks off" at certain breakpoints but works at others.
+**Root cause**: In Tailwind v3, `md:px-6` and `sm:pl-0` both target `padding-left` — same CSS property, media query specificity decides the winner. In Tailwind v4, `md:px-6` targets `padding-inline` (shorthand) while `sm:pl-0` targets `padding-inline-start` (longhand). These are different CSS properties. If `padding-inline-start` appears later in the compiled stylesheet, it overrides the shorthand's start value, creating asymmetric padding.
+**Example**:
+```html
+<!-- This pattern exists in many Deco storefronts -->
+<div class="pl-4 sm:pl-0 md:px-6 xl-b:px-0 max-w-[1280px] mx-auto">
+```
+In Tailwind v3: at `md` viewport, `px-6` sets `padding-left: 1.5rem` and `padding-right: 1.5rem`, cleanly overriding `sm:pl-0`.
+In Tailwind v4: at `md` viewport, `px-6` sets `padding-inline: 1.5rem`, but `pl-0` (from `sm:`) may still override `padding-inline-start` depending on stylesheet order.
+**Fix**: Replace mixed shorthand + longhand patterns with consistent longhand properties:
+```
+md:px-6 xl-b:px-0       →  md:pl-6 md:pr-6 xl-b:pl-0 xl-b:pr-0
+px-4 lg:px-6 xl-b:px-0  →  pl-4 pr-4 lg:pl-6 lg:pr-6 xl-b:pl-0 xl-b:pr-0
+```
+**Detection**: Find all elements with mixed patterns:
+```bash
+grep -rn 'px-[0-9].*pl-\|pl-.*px-[0-9]\|px-[0-9].*pr-\|pr-.*px-[0-9]' src/ --include='*.tsx'
+```
+Only convert `px-*` on elements that ALSO have `pl-*` or `pr-*`. Don't blindly replace all `px-*` across the codebase — elements with only `px-*` (no mixed longhand) work fine.
+Also check for the same issue with `mx-*` mixed with `ml-*`/`mr-*`, and `my-*` mixed with `mt-*`/`mb-*`.
+## 43. CSS oklch() Color Variables Must Store Triplets, Not Hex
+**Severity**: HIGH — all SVG icons render as black, brand colors break
+Sites that use `oklch(var(--variable))` in SVG fill/stroke attributes (common in Deco storefronts with seasonal/theme color systems) require the CSS variables to store **oklch triplets** (`100% 0.00 0deg`), NOT hex values (`#FFF`). `oklch(#FFF)` is invalid CSS — the browser ignores it and falls back to black.
+**Symptom**: Slider arrows, footer icons, search icons, filter icons — anything using `oklch(var(--...))` — renders as black circles/shapes instead of the brand colors.
+**Root cause**: The original site's Theme section (via Deco CMS) outputs oklch triplets into CSS variables. During migration, if the CSS variables are manually set to hex values, every `oklch()` wrapper produces invalid CSS.
+**Fix**: Convert all theme CSS variables from hex to oklch triplets:
+```css
+/* WRONG — invalid CSS when used as oklch(var(--bg-seasonal-2)) */
+--bg-seasonal-2: #FFF;
+/* CORRECT — oklch(100% 0.00 0deg) is valid */
+--bg-seasonal-2: 100% 0.00 0deg;
+```
+**Dual-usage caveat**: Variables used BOTH inside `oklch()` wrappers AND directly in CSS properties need different handling:
+```css
+/* @theme entries for Tailwind utilities — need oklch() wrapper */
+--color-bg-seasonal-1: oklch(var(--bg-seasonal-1));
+/* Direct CSS usage — also needs oklch() wrapper */
+background-color: oklch(var(--bg-seasonal-1));
+```
+The DaisyUI v4 pattern: `@theme` entries map `--color-X` to `var(--Y)`. Tailwind generates `background-color: var(--color-X)` which resolves to the raw triplet — invalid without the `oklch()` wrapper. Wrap all `@theme` entries that reference oklch-triplet variables.
+**Python conversion helper**:
+```python
+from colorjs import Color
+c = Color("#EE4F31")
+l, c_val, h = c.convert("oklch").coords()
+print(f"{l*100:.2f}% {c_val:.2f} {h:.0f}deg")  # 64.42% 0.20 33deg
+```

package/.agents/skills/deco-to-tanstack-migration/references/deco-framework/README.md ADDED Viewed

@@ -0,0 +1,128 @@
+# Deco Framework Import Elimination
+Replace all `@deco/deco/*` and `$fresh/*` imports with inline equivalents. No shim files needed.
+## $fresh/runtime.ts
+### asset(url)
+The `asset()` function in Fresh prepends the build hash path. In Vite, static assets are handled automatically. Just remove the wrapper:
+```typescript
+// OLD
+import { asset } from "$fresh/runtime.ts";
+<img src={asset("/sprites.svg")} />
+// NEW
+<img src="/sprites.svg" />
+```
+### IS_BROWSER
+```typescript
+// OLD
+import { IS_BROWSER } from "$fresh/runtime.ts";
+// NEW (inline)
+const IS_BROWSER = typeof document !== "undefined";
+```
+## @deco/deco (bare import)
+### SectionProps
+```typescript
+// OLD
+import type { SectionProps } from "@deco/deco";
+type Props = SectionProps<typeof loader>;
+// NEW (inline type)
+type SectionProps<T extends (...args: any[]) => any> = ReturnType<T>;
+```
+### Resolved
+```typescript
+// OLD
+import type { Resolved } from "@deco/deco";
+// NEW
+type Resolved<T = any> = T;
+```
+### context
+```typescript
+// OLD
+import { context } from "@deco/deco";
+if (context.isDeploy) { ... }
+// NEW
+const context = { isDeploy: false, platform: "tanstack-start", site: "my-store", siteId: 0 };
+```
+## @deco/deco/blocks
+### Section, Block
+```typescript
+// OLD
+import type { Section } from "@deco/deco/blocks";
+// NEW
+type Section = any;
+type Block = any;
+```
+These were used for Deco CMS section composition. In TanStack Start, sections are just React components.
+## @deco/deco/hooks
+### useScript / useScriptAsDataURI
+These serialize a function into an inline `<script>` string. Create `~/sdk/useScript.ts`:
+```typescript
+export function useScript(fn: (...args: any[]) => void, ...args: any[]): string {
+  const serializedArgs = args.map((a) => JSON.stringify(a)).join(",");
+  return `(${fn.toString()})(${serializedArgs})`;
+}
+export function useScriptAsDataURI(fn: (...args: any[]) => void, ...args: any[]): string {
+  const code = useScript(fn, ...args);
+  return `data:text/javascript;charset=utf-8,${encodeURIComponent(code)}`;
+}
+```
+### usePartialSection
+Deco partial sections don't apply in TanStack Start. Stub:
+```typescript
+export function usePartialSection(props?: Record<string, unknown>) {
+  return props || {};
+}
+```
+## @deco/deco/o11y
+```typescript
+// OLD
+import { logger } from "@deco/deco/o11y";
+logger.error("failed", err);
+// NEW
+console.error("failed", err);
+```
+## Automation
+All of these are safe for bulk sed (each import pattern maps to exactly one replacement).
+## Verification
+```bash
+grep -r '@deco/deco' src/ --include='*.ts' --include='*.tsx'
+grep -r '\$fresh/' src/ --include='*.ts' --include='*.tsx'
+# Both should return ZERO matches
+```

package/.agents/skills/deco-to-tanstack-migration/references/gotchas.md ADDED Viewed

@@ -0,0 +1,13 @@
+# Gotchas Index
+This file is an index. Each topic has its own focused file.
+| File | Topic | Key Gotchas |
+|------|-------|-------------|
+| [react-hooks-patterns.md](react-hooks-patterns.md) | useEffect, useQuery, useMemo, lazy init | #2, #33, #46, #47 |
+| [react-signals-state.md](react-signals-state.md) | TanStack Store, signal.value, subscribe() | #3, #19, #38 |
+| [jsx-migration.md](jsx-migration.md) | Preact→React JSX differences | #4–6, #11, #20–22, #41 |
+| [vtex-commerce.md](vtex-commerce.md) | VTEX loaders, cart, facets, price specs | #1, #7–8, #32, #34–36, #39 |
+| [worker-cloudflare.md](worker-cloudflare.md) | Worker entry, build, Cloudflare, npm | #9–10, #12–14, #19, #24–28, #30, #44–45 |
+| [css-styling.md](css-styling.md) | Tailwind v4, oklch, DaisyUI | #15, #17, #31, #37, #40, #42–43 |
+| [admin-cms.md](admin-cms.md) | Admin routes, schema, device context | #16, #18, #23, #26, #29 |

package/{.cursor/skills/deco-tanstack-hydration-fixes/SKILL.md → .agents/skills/deco-to-tanstack-migration/references/hydration-fixes.md} RENAMED Viewed

@@ -1,7 +1,3 @@
----
-name: deco-tanstack-hydration-fixes
-description: Fix hydration mismatches, flash-of-white, CLS from third-party scripts, scroll-to-top bugs, and React DOM warnings in Deco storefronts on TanStack Start/React/Cloudflare Workers. Use when debugging hydration errors, page flicker during navigation, blank screen on F5, layout shifts from external scripts, or React console warnings about invalid DOM properties.
----
 # Hydration & Navigation Fixes for Deco TanStack Storefronts
@@ -466,3 +462,142 @@ When investigating hydration/flash issues on a Deco TanStack storefront:
 8. **Test with F5 (hard reload)** — SPA navigation may hide issues that appear on cold load
 9. **Check scroll behavior** — navigate from shelf to PDP; verify page scrolls to top
 10. **Compare SSR HTML vs client render** — view source (`Ctrl+U`) and compare with inspected DOM to find hydration diffs
+---
+## 13. `useDevice()` Hydration Mismatch in Eager Sections
+### Root Cause
+`@decocms/start` shell-renders sections in a **separate React root** that does NOT include providers from `__root.tsx`. This means `useDevice()` — which reads from `Device.Provider` — falls back to the context default (`isMobile: true`) on the server, while the client goes through `__root.tsx` and gets whatever value the Provider has.
+Result: server renders mobile layout, client renders desktop layout → structural hydration mismatch.
+This affects ONLY **eager sections** (sections in `alwaysEager` or not wrapped in CMS `Lazy.tsx`). Deferred sections render a skeleton server-side, and the real component loads client-side AFTER hydration — no mismatch.
+### Which sections are affected
+Check `alwaysEager` in `setup.ts`:
+```typescript
+setAsyncRenderingConfig({
+  alwaysEager: [
+    "site/sections/Header/Header.tsx",
+    "site/sections/Header/NewHeader.tsx",
+    "site/sections/Footer/Footer.tsx",
+    "site/sections/Theme/Theme.tsx",
+    "site/sections/Images/Carousel.tsx",
+    "site/sections/Tipbar.tsx",
+  ],
+});
+```
+Any of these that call `useDevice()` and render different HTML structure based on `isMobile` will have a hydration error.
+`LoadingFallback` components are also server-rendered (they're the skeleton while deferred section loads). LoadingFallbacks that use `useDevice()` to change the count or structure of elements will cause hydration mismatches on the skeleton itself.
+### Fix Pattern A: Use `device` prop from loader (structural branches)
+For sections that already receive `device` from their loader (`ctx.device`), use the prop instead of the hook:
+```typescript
+// Before — useDevice() reads from context, missing during shell render
+function Header({ device, ...props }: Props) {
+  const { isMobile } = useDevice(); // ← wrong: context not available in shell render
+  if (isMobile) return <MobileLayout />;
+  return <DesktopLayout />;
+}
+// After — device prop comes from loaderData, consistent on server + client
+function Header({ device, ...props }: Props) {
+  const isMobile = device === "mobile" || device === "tablet"; // ← correct
+  if (isMobile) return <MobileLayout />;
+  return <DesktopLayout />;
+}
+```
+The `device` prop comes from the section loader:
+```typescript
+export async function loader(props: Props, req: Request, ctx: AppContext) {
+  return {
+    ...props,
+    device: ctx.device as "mobile" | "desktop" | "tablet",
+  };
+}
+```
+`ctx.device` is detected from the request `User-Agent` header server-side. TanStack Start serializes loaderData and sends it to the client, so both server and client always use the same value. No mismatch.
+Also fix the section's `LoadingFallback` to use `props.device` instead of `useDevice()`:
+```tsx
+// Before
+export const LoadingFallback = (props: LoadingFallbackProps & Props) => {
+  const device = useDevice();
+  const deviceProp = device.isMobile ? "mobile" : "desktop";
+  return <Header {...props} device={deviceProp} />;
+};
+// After
+export const LoadingFallback = (props: LoadingFallbackProps & Props) => {
+  return <Header {...props} device={props.device ?? "desktop"} />;
+};
+```
+### Fix Pattern B: Remove redundant JS conditionals (show/hide with CSS)
+When a section renders show/hide elements based on `isMobile` but the containing elements ALREADY have responsive CSS classes (`hidden lg:block`, `hidden lg:flex`, `lg:hidden`), the JS conditional is redundant and causes the mismatch. Simply remove it:
+```tsx
+// Before — JS conditional + CSS class (redundant, causes mismatch)
+{!isMobile && (
+  <div className="hidden lg:flex">...</div>
+)}
+// After — CSS alone handles responsive behavior
+<div className="hidden lg:flex">...</div>
+```
+This is the correct fix for Footer and similar layout sections where mobile/desktop differences are already handled by Tailwind responsive prefixes.
+### Fix Pattern C: CSS-only responsive sizing (LoadingFallback skeletons)
+For `LoadingFallback` components that use `useDevice()` to vary sizes or counts, replace JS with responsive Tailwind classes:
+```tsx
+// Before — causes hydration mismatch on skeleton
+function LoadingCard() {
+  const device = useDevice();
+  return (
+    <div className={`max-w-[${device.isMobile ? "160px" : "320px"}]`}>
+      <div className={`h-${device.isMobile ? "40" : "60"}`} />
+    </div>
+  );
+}
+// After — CSS handles responsive sizing, no JS needed
+function LoadingCard({ className }: { className?: string }) {
+  return (
+    <div className={`max-w-[160px] sm:max-w-[320px] ${className ?? ""}`}>
+      <div className="h-40 sm:h-60" />
+    </div>
+  );
+}
+// For count variations in LoadingFallback:
+// Before (renders 2 on mobile / 4 on desktop)
+{Array(device.isMobile ? 2 : 4).fill(0).map((_, i) => <LoadingCard key={i} />)}
+// After (always renders 4, CSS hides extras on mobile)
+<LoadingCard />
+<LoadingCard />
+<LoadingCard className="hidden sm:flex" />
+<LoadingCard className="hidden sm:flex" />
+```
+### Quick diagnosis
+Search for `useDevice` in eager sections to find candidates:
+```bash
+rg "useDevice" src/sections/ src/components/header/ src/components/footer/ --glob "*.tsx"
+```
+Any result in a component that's always-eager and renders different element types/counts based on `isMobile` needs one of the fix patterns above.

package/.agents/skills/deco-to-tanstack-migration/references/imports/README.md ADDED Viewed

@@ -0,0 +1,70 @@
+# Preact -> React Import Migration
+Mechanical find-and-replace. Safe to automate with `sed`.
+## Replacements
+| Find | Replace |
+|------|---------|
+| `from "preact/hooks"` | `from "react"` |
+| `from "preact/compat"` | `from "react"` |
+| `from "preact"` | `from "react"` |
+## Special Cases
+### ComponentChildren -> ReactNode
+Preact's `ComponentChildren` maps to React's `ReactNode`:
+```typescript
+// OLD
+import type { ComponentChildren } from "preact";
+// NEW
+import type { ReactNode as ComponentChildren } from "react";
+```
+If you want to modernize fully, rename `ComponentChildren` to `ReactNode` across the codebase.
+### JSX type
+```typescript
+// OLD
+import type { JSX } from "preact";
+// NEW (works unchanged)
+import type { JSX } from "react";
+```
+### FunctionalComponent -> FC
+```typescript
+// OLD
+const Foo: preact.FunctionalComponent<Props> = ...
+// NEW
+import React from "react";
+const Foo: React.FC<Props> = ...
+```
+## Automation
+```bash
+# Bulk replace (macOS sed)
+find src/ -name '*.ts' -o -name '*.tsx' | xargs sed -i '' \
+  -e 's|from "preact/hooks"|from "react"|g' \
+  -e 's|from "preact/compat"|from "react"|g'
+# Bare preact requires care (don't match preact/hooks or preact/compat)
+find src/ -name '*.ts' -o -name '*.tsx' | xargs sed -i '' \
+  's|from "preact"|from "react"|g'
+```
+Then handle `ComponentChildren` files individually.
+## Verification
+```bash
+grep -r 'from "preact' src/ --include='*.ts' --include='*.tsx'
+# Should return ZERO matches
+```

package/{.cursor/skills/deco-islands-migration/SKILL.md → .agents/skills/deco-to-tanstack-migration/references/islands.md} RENAMED Viewed

@@ -1,7 +1,3 @@
----
-name: deco-islands-migration
-description: Eliminate the src/islands/ directory when migrating Deco storefronts from Fresh/Preact to TanStack Start/React. Explains why islands don't make sense in the new stack, the problems they cause, how to systematically repoint or move them, and how to fix vanilla-JS DOM patterns that break React hydration. Use when auditing or removing islands from a migrated storefront.
----
 # Deco Islands Migration — From Fresh Islands to React Components
@@ -239,13 +235,3 @@ function Drawer({ class: classProp = "", className = "" }: Props) {
 - [ ] Build succeeds (`npm run build` / `bun run build`)
 - [ ] Dev server starts without errors
 - [ ] Interactive elements work: add to cart, sliders, drawers, modals
-## Related Skills
-| Skill | Purpose |
-|-------|---------|
-| `deco-to-tanstack-migration` | Full migration playbook (imports, signals, architecture) |
-| `deco-tanstack-navigation` | SPA navigation patterns (`<a>` → `<Link>`, `useNavigate`, `loaderDeps`, forms) |
-| `deco-tanstack-storefront-patterns` | Runtime fixes post-migration (nested sections, caching, SliderJS, async_hooks, cart, server functions) |
-| `deco-storefront-test-checklist` | Context-aware QA checklist generation |
-| `deco-typescript-fixes` | TypeScript error patterns and fixes |