feat(release): Split gpr and npm release into separate jobs

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

.changeset/README.md

@@ -34,8 +34,9 @@ Alle base-pakkene våre har `fixed versjonering`. Dette betyr at en bump på en
 ```sh
   "@navikt/ds-react",
   "@navikt/ds-css",
-  "@navikt/aksel-icons",
   "@navikt/ds-tokens",
   "@navikt/ds-tailwind",
-  "@navikt/ds-codemod"
+  "@navikt/aksel-icons",
+  "@navikt/aksel",
+  "@navikt/aksel-stylelint"
 ```

.changeset/config.json

@@ -1,5 +1,5 @@
 {
-  "$schema": "https://unpkg.com/@changesets/config@2.2.0/schema.json",
+  "$schema": "https://unpkg.com/@changesets/config@4.0.0/schema.json",
   "changelog": [
     "@svitejs/changesets-changelog-github-compact",
     { "repo": "navikt/aksel" }
@@ -30,7 +30,7 @@
     "aksel-sanity-studio",
     "aksel-icons-figma-plugin",
     "aksel-mcp",
-    "playroom"
+    "aksel-playroom"
   ],
 
   "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {

.cplt.toml

@@ -0,0 +1,7 @@
+# https://min-copilot.ansatt.nav.no/cplt
+[propose]
+allow_docker = true
+allow_localhost_any = true
+
+[propose.allow]
+localhost = [3000, 6006, 6007]

.github/copilot-instructions.md

@@ -9,6 +9,8 @@
 
 ## Behavior
 
+- Only respond in same language as the input. Prefer english always.
+- Use caveman-skill unless asked not to
 - No apologies, no "I think", no change summaries.
 - Answer-first. 0-2 sentences max.
 - No thinking aloud; do next edit. Explain only when asked or non-obvious.
@@ -18,60 +20,62 @@
 
 ## Repo summary
 
-- Yarn 4 workspaces monorepo: public React/CSS/tokens/icons/stylelint/CLI packages + docs site + playroom.
-- Stack: TypeScript 6, React 19, Next.js 16, Storybook 10, Vitest 4, ESLint 9, Stylelint 17, Biome 2, Prettier 3.
-- Node 22+, Yarn 4.12.0.
-- `@navikt/*` must stay React 17 compatible.
+- Nav's design system. Yarn 4 workspaces monorepo: published packages under `@navikt/` + docs site `aksel.nav.no/` + `apps/` + `tooling/`.
+- Stack: TypeScript 6, React 19 (dev), Next.js 16, Storybook 10, Vitest 4, ESLint 9, Stylelint 17, Biome 2 (lint only), Prettier 3 (formatting). Node 22+, Yarn 4.18.0.
+- Published `@navikt/*` packages must stay React 17 compatible (peer `react ^17 || ^18 || ^19`).
 
 ## Start and validate
 
 1. `corepack enable`
-2. `yarn install`
-3. `yarn boot`
+2. `corepack yarn install` (needs `NPM_AUTH_TOKEN` with `read:packages`). Without a token: `corepack yarn workspaces focus @navikt/aksel-icons @navikt/ds-tokens @navikt/ds-css @navikt/ds-react @navikt/ds-tailwind @navikt/aksel @navikt/aksel-stylelint`
+3. `corepack yarn boot` (builds all public packages; rerun after `corepack yarn clean`)
 
-- `yarn boot` after first install + after `yarn clean`.
-- Full install needs `NPM_AUTH_TOKEN` for GitHub Packages.
-
-Public-package-only: `yarn workspaces focus @navikt/aksel-icons @navikt/ds-tokens @navikt/ds-css @navikt/ds-react @navikt/ds-tailwind @navikt/aksel @navikt/aksel-stylelint`
+- Run agent commands through `corepack yarn`. Order: existing root/workspace script → Yarn-local binary → add a pinned dependency only when new tooling is required.
+- Never use `npx`, `pnpx`, `pnpm dlx`, `yarn dlx`, global binaries or curl-piped installers. Public consumer docs (`npx @navikt/aksel`) are intentional; keep them.
+- If Corepack/Yarn fails because of user-level configuration, report the exact error. Never edit user-home config.
+- Choosing checks: use the `aksel-local-validation` skill. Changed-file lint first, then the affected workspace, then root suites only when needed.
 
 ## Definition of done
 
 - Behavior/visual change: update impl + closest story + test.
-- New public export: sync component `index.ts`, `src/index.ts`, `package.json` exports.
-- User-facing change: add changeset unless told otherwise.
-- Validate with narrowest workspace command first.
+- New public export: sync component `index.ts`, `src/index.ts` (or `src/preview.ts`) and `package.json` exports, then `corepack yarn workspace aksel-playroom sync-imports` (root `lint` fails on stale playroom imports).
+- User-facing change to a published package: add a changeset (`add-changeset` skill) unless told otherwise.
 
-### Commands
+## Commands
 
-- `yarn boot` - build all
-- `yarn test` / `yarn lint` - all tests / all linting
-- `yarn lint:eslint` / `yarn lint:css` / `yarn lint:biome`
-- `yarn storybook` - root `:6006`
-- `yarn storybook:aksel` - website examples `:6007`
-- `yarn storybook:test` - browser tests (Playwright/Firefox)
-- `yarn dev` - website `:3000`
-- `yarn clean` - remove build artifacts
-- `yarn workspace @navikt/ds-react build|test`
-- `yarn workspace website test`
-- `yarn workspace playroom sync-imports`
-
-`yarn lint` fails if playroom imports stale → `yarn workspace playroom sync-imports`.
+- `corepack yarn eslint --max-warnings=0 --no-warn-ignored <files...>` / `corepack yarn stylelint <files...>` / `corepack yarn biome lint --no-errors-on-unmatched <files...>`
+- `corepack yarn tsc --noEmit --incremental false --project <tsconfig>` - targeted type-check
+- `corepack yarn workspace <name> <script>` - e.g. `@navikt/ds-react test` (Vitest + tsc), `website test`
+- `corepack yarn lint` / `corepack yarn test` / `corepack yarn boot` - root suites (slow; cross-workspace changes only)
+- `corepack yarn storybook` (:6006) / `corepack yarn storybook:aksel` (website examples, :6007, no secrets) / `corepack yarn storybook:test` (play tests, Playwright Firefox) / `corepack yarn dev` (website, :3000, needs Sanity token)
 
 ## Where to edit
 
-- `@navikt/core/react/src/<component>/` - component source, index, stories
-- `@navikt/core/react/src/index.ts` + `package.json` exports - public API surface
-- `@navikt/core/css/src/` - component CSS
-- `@navikt/core/tokens/src/` - design tokens
-- `@navikt/core/tailwind/` - Tailwind preset
-- `@navikt/aksel-icons/icons/` - source SVGs (`src/` generated)
-- `@navikt/aksel-stylelint/src/` - Stylelint rules
+Path-specific rules load automatically from `.github/instructions/` (see each `applyTo`).
+
+- `@navikt/core/react/src/<component>/` - components (`src/index.ts`, `src/preview.ts` + `package.json` exports = public API)
+- `@navikt/core/css/src/` - component CSS (`index.css` imports + layers)
+- `@navikt/core/tokens/src/` - design tokens · `@navikt/core/tailwind/` - Tailwind preset (generated from tokens)
+- `@navikt/aksel-icons/icons/` - source SVG + YML (`src/` generated)
+- `@navikt/aksel-stylelint/src/` - Stylelint rules + CSS class deprecations
 - `@navikt/aksel/src/` - CLI and codemods
-- `aksel.nav.no/website/` - Next.js docs site
-- `apps/playroom/` - playroom
-- `apps/mcp-server/` - MCP server
-- `apps/figma-icon-plugin/` - Figma plugin
-- Root: `eslint.config.js`, `stylelint.config.mjs`, `biome.json`, `tsconfig.json`, `.storybook/`
+- `aksel.nav.no/website/` - Next.js docs site · `aksel.nav.no/sanity-studio/` - CMS schema
+- `apps/playroom/`, `apps/mcp-server/`, `apps/figma-icon-plugin/` - apps · `tooling/` - ESLint plugin, scripts, changelog, analyzer
+- `.changeset/` - release notes · Root config: `eslint.config.js`, `stylelint.config.mjs`, `biome.json`, `vitest.config.ts`, `.storybook/`
+
+## Skills and agents
+
+- `aksel-local-validation` - pick and run the right lint/type/test commands
+- `code-review` - review a branch, diff or PR for consumer-facing risk
+- `add-changeset` - write `.changeset/*.md` (never run interactive `yarn changeset`)
+- `ds-component-restructure` - move/rename component files to canonical layout
+- `website-example` - add aksel.nav.no examples/templates
+
+## Gotchas
+
+- `.yarnrc.yml`: `enableScripts: false` (dependency install scripts don't run, e.g. Playwright browsers), `npmMinimalAgeGate: 7d` (new package versions under 7 days old are rejected), `defaultSemverRangePrefix: ""` (exact versions).
+- Never hand-edit generated output: `esm/`, `cjs/`, `dist/`, `@navikt/aksel-icons/src/`, `@navikt/aksel/src/version.ts`, tokens `token_docs.js`, tailwind `tailwind.config.js`.
+- Don't run scripts that write to Sanity/Figma/releases (`update:*`, `backup`, `fetch-new:icons`, `release`, `create-version`) unless asked.
 
 ## Coding defaults
 
@@ -79,6 +83,5 @@ Public-package-only: `yarn workspaces focus @navikt/aksel-icons @navikt/ds-token
 - Copy nearest existing pattern before writing new code.
 - Stable public APIs. Prefer additive props/exports.
 - `node:` imports for Node builtins. Never import from `esm/`/`cjs/` output.
-- Import order: `@navikt/*`, `@/*`, relative. (Prettier sorts)
 - Preserve JSDoc on public props/components when changing public APIs.
 - Reuse helpers: `cl`, `composeEventHandlers`, `useId`, `omit`, `useClientLayoutEffect`, `useEventListener`.

.github/instructions/changeset.instructions.md

@@ -0,0 +1,21 @@
+---
+description: "Writing changeset files for versioning public @navikt packages."
+applyTo: ".changeset/**"
+---
+
+# Changesets
+
+`yarn changeset` is interactive. Agents write `.changeset/<kebab-slug>.md` directly (see the `add-changeset` skill):
+
+```md
+---
+"@navikt/ds-react": patch
+---
+
+Component: Short, user-facing description of the change
+```
+
+- Publishable packages (versioned together via `fixed` in `config.json`): `@navikt/ds-react`, `@navikt/ds-css`, `@navikt/ds-tokens`, `@navikt/ds-tailwind`, `@navikt/aksel-icons`, `@navikt/aksel`, `@navikt/aksel-stylelint`. List only the packages actually changed.
+- Everything in `config.json` `ignore` (website, playroom, mcp, tooling, sanity) never gets a changeset.
+- Summary format: `<Component>: <what changed for consumers>`. It ends up in the public changelog, so write for consumers, not reviewers.
+- Don't edit `config.json`, `CHANGELOG.md` files or package versions. The release workflow does that.

.github/instructions/code-review.instructions.md

@@ -1,42 +0,0 @@
----
-description: "Code review instructions used when reviewing pull requests."
-applyTo: "**"
-excludeAgent: ["coding-agent"]
----
-
-# Code review focus
-
-Review for issues that could block release, surprise users, or create maintenance risk. Prefer high-signal findings over style-only comments.
-
-## What to check
-
-### 1. Public API and behavior
-
-- New or changed APIs should match existing naming, params, defaults, and behavior patterns.
-- Watch for breaking changes, regressions, and accidental behavior changes in public components, hooks, CSS, tokens, and CLI output.
-- Avoid introducing new patterns unless the change clearly justifies them.
-
-### 2. Documentation and examples
-
-- Public components and exported APIs should have accurate JSDoc, including `@default` where it adds clarity.
-- Check whether Storybook stories, website examples, and decision records need updates to match the new behavior.
-
-### 3. Tests
-
-- Flag missing or insufficient tests for changed behavior, edge cases, and regressions.
-- Prefer tests that prove the contract users rely on, not just implementation details.
-
-### 4. CSS and styling
-
-- If CSS class names are removed, verify deprecation handling in `@navikt/aksel-stylelint/src/deprecations.ts`.
-- If new CSS files or selectors are added, confirm they follow the repo's import and naming conventions.
-
-### 5. Exports and packaging
-
-- New public exports must be wired through the correct `index.ts` files and `package.json` exports when relevant.
-- Check that release-facing entry points stay consistent across packages.
-
-### 6. Changesets and migrations
-
-- User-facing changes should include a changeset with a clear summary and impact.
-- Breaking changes should also include a codemod when needed.

.github/instructions/code-syntax.instructions.md

@@ -1,11 +1,13 @@
 ---
-description: "JS/TS code conventions."
-applyTo: "**/*.tsx", "**/*.jsx", "**/*.ts", "**/*.js"
+description: "JS/TS conventions not enforced by ESLint/Biome: loops, export style and placement."
+applyTo: "**/*.ts,**/*.tsx,**/*.js,**/*.mts,**/*.mjs"
 ---
 
-# JS/TS instructions
+# JS/TS conventions
 
-- Prefer `for...of` over `Array.forEach`.
-- Named exports; type exports separate from value exports.
-- Group exports at bottom: values first, then types.
-- In `*.stories.*`, keep default export at top.
+Formatting, import order and `import type` are handled by Prettier and Biome. Don't hand-tune them.
+
+- Use `for...of` instead of `Array.forEach`. It supports `break`/`continue`/`await` and reads top-down.
+- Use named exports only. Keep type exports separate from value exports (`export { X }` / `export type { XProps }`).
+- Group exports at the bottom of the file, values first, then types. `react-docgen-typescript` (`docgen:meta`) depends on this pattern.
+- Exceptions to default exports: `*.stories.tsx` (CSF meta default export, kept at the top), and Next.js pages/website examples that the framework requires.

.github/instructions/codemod.instructions.md

@@ -0,0 +1,15 @@
+---
+description: "@navikt/aksel CLI and jscodeshift codemods: transforms, fixtures, migration registry."
+applyTo: "@navikt/aksel/**"
+---
+
+# @navikt/aksel CLI and codemods
+
+- Transforms live in `src/codemod/transforms/v<major>.0.0/<name>/<name>.ts`. Tests live in the sibling `tests/` folder.
+- Every transform is registered in `src/migrations-config.ts` (`value`, `path` without extension, `description`, `ignoredExtensions`). `value` must be unique and is the public CLI name (`v8-accordion-variant`).
+- Test with fixtures: `tests/<fixture>.input.js` → `tests/<fixture>.output.js`, run via `check(__dirname, { fixture, migration })` from `src/codemod/utils/check.ts`. Output is compared after Prettier, so whitespace doesn't matter.
+- Reuse helpers in `src/codemod/utils/` (imports, props, JSX values, token translation) before writing new AST code.
+- Fixtures (`*.input.*`, `*.output.*`) are excluded from ESLint and TypeScript. Don't "fix" them to match lint rules.
+- `src/version.ts` is generated by `build`. Don't edit it.
+- `tests/migrations.test.ts` checks `dist/`. Run `corepack yarn workspace @navikt/aksel build` before `test`, or new transforms fail with "transform-path" errors.
+- Consumer docs (`README.md`, website) show `npx @navikt/aksel ...` on purpose. Keep them.

.github/instructions/css.instructions.md

@@ -0,0 +1,15 @@
+---
+description: "Editing @navikt/ds-css component styles: file setup, layers, selectors, tokens, deprecations."
+applyTo: "@navikt/core/css/src/**"
+---
+
+# ds-css
+
+- One file per component in `src/` (`badge.css`). A new file must be `@import`ed in `src/index.css` with the right `layer(...)`, otherwise it isn't bundled. Most components use `aksel.components.modules`; form controls go through `form/index.css`.
+- Selectors use the `.aksel-<component>` prefix and BEM-ish `__part` / `--modifier`. State goes through `data-*` / ARIA attribute selectors, not extra modifier classes.
+- Use tokens only: public `--ax-*`, component-internal `--__axc-*`. No hardcoded colors, spacing or radii. Stylelint flags unknown custom properties.
+- Colors follow `data-color` (see nearby components). Don't add per-variant color selectors.
+- Focus uses `:focus-visible` (outline + `outline-offset`). Check `forced-colors`, print and dark theme in Storybook.
+- `prefers-reduced-motion` is handled globally in `baseline/baseline.css`. Don't duplicate it per component.
+- `baseline/tokens.css` re-exports `@navikt/ds-tokens` build output. Edit tokens in `@navikt/core/tokens/src`, not here.
+- Removing or renaming a class is breaking for consumers (for allready published components. Ignore for new components). Add it to `@navikt/aksel-stylelint/src/deprecations.ts`.

.github/instructions/ds-react-component.instructions.md

@@ -1,17 +1,33 @@
 ---
-description: "ds-react components and component CSS."
-applyTo: "@navikt/core/react/src/**", "@navikt/core/css/src/**"
+description: "Editing or adding @navikt/ds-react components, hooks and their public exports."
+applyTo: "@navikt/core/react/src/**"
 ---
 
-# ds-react component instructions
+# ds-react components
 
-- Read full component folder before editing.
-- Preserve `forwardRef`, `className`, `...rest`, `as`/`OverridableComponent` patterns.
-- `@navikt/*` must stay React 17 compatible. No React 18/19-only APIs; use internal `useId` etc.
-- `@navikt/*` TSX: import React explicitly (classic JSX).
+Read the whole component folder (`index.ts`, source, `.meta.ts`, stories, tests) before editing. Moving or renaming files: use the `ds-component-restructure` skill.
+
+## Compatibility (why: peer range is `react ^17 || ^18 || ^19`)
+
+- No React 18/19-only APIs. ESLint `no-restricted-imports` blocks e.g. `React.useId`. Use the internal `useId`, `useClientLayoutEffect`, etc. from `utils-external/`.
+- Import React explicitly in TSX (`import React from "react"`). `tsconfig` uses classic `jsx: "react"`.
 - Component `index.ts` starts with `"use client"`.
-- Use tokens, not hardcoded values. Token names: `--ax-*` (public), `--__axc-*` (internal).
-- Follow CSS nesting, `data-*` selectors, `focus-visible`, `forced-colors`, reduced-motion.
-- Prettier formats CSS; Biome lint-only.
-- Behavior/visual change: update nearest story + test.
-- Public component change: sync component `index.ts`, `src/index.ts`, `package.json` exports.
+
+## Component patterns
+
+- Preserve `forwardRef`, `className` merged via `cl("aksel-<name>", className)`, `...rest` spread, and `as`/`OverridableComponent` where they already exist.
+- Compound components: `const X = Object.assign(XRoot, { Item: XItem })`. Never cast with `as XComponent`, because `docgen:meta` can't extract props from a cast.
+- Colors: `data-color?: AkselColor`, not new `variant` color values.
+- User-facing strings come from `useI18n("<Component>")` with keys in `utils/i18n/locales/{nb,nn,en}.ts`. Add the key to all three.
+- Public props and components need JSDoc. Component JSDoc sits above the exported value, with `@see 🏷️ {@link XProps}` and an `@example`. Add `@default` when the default isn't obvious.
+
+## Public API surface (breaking = major changeset)
+
+- Stable component: export it from component `index.ts`, add it to `src/index.ts`, and add a `"./<Name>"` entry to `package.json` `exports` (both `import` and `require`).
+- Preview/beta component: export from `src/preview.ts` plus `"./PREVIEW/<Name>"` in `package.json` instead of `src/index.ts`.
+- Standalone components have `<Component>.meta.ts` (see `accordion/Accordion.meta.ts`). Sub-components don't.
+- Changing exports: run `corepack yarn workspace aksel-playroom sync-imports`, or root `lint` fails.
+
+## Validate
+
+`corepack yarn workspace @navikt/ds-react test` (Vitest + `tsc` type-check). Add `build` when exports or types change.

.github/instructions/icons.instructions.md

@@ -0,0 +1,14 @@
+---
+description: "@navikt/aksel-icons: adding/updating SVG icons and metadata; generated React components."
+applyTo: "@navikt/aksel-icons/**"
+---
+
+# aksel-icons
+
+- Source: `icons/<Name>.svg` + `icons/<Name>.yml`. Every SVG has a matching YML and vice versa (checked by `__tests__/validate-files.test.ts`). Most icons also have a `<Name>Fill` variant.
+- YML shape: copy a sibling, e.g. `icons/Airplane.yml` (`name`, `category`, `sub_category`, `keywords` (nb + en), `variant: Stroke|Fill`, `created_at: DD.MM.YYYY`).
+- SVG root: `width="24" height="24" viewBox="0 0 24 24" fill="none"`. Shapes use `fill="#202733"` (becomes `currentColor` at build) and `stroke-width` 1.5 if any. `__tests__/validate-svg*.test.ts` enforces this. Copy a sibling SVG.
+- `src/` React components, `dist/` and metadata are generated by `build` (SVGR). Never edit `src/` by hand.
+- `core-icons/` is only used for the downloadable zip. `fetch-new:icons` pulls from Figma and needs a token. Don't run it unless asked.
+- New icon = minor changeset for `@navikt/aksel-icons` (e.g. `Icons: New icons Timeline, TimelineFill`).
+- Validate: `corepack yarn workspace @navikt/aksel-icons test`. Run `build` when checking generated output.

.github/instructions/testing.instructions.md

@@ -1,14 +1,15 @@
 ---
-description: "Tests and stories."
-applyTo: "**/*.test.*", "**/*.stories.tsx"
+description: "Writing Vitest unit tests and Storybook stories/play tests."
+applyTo: "**/*.test.ts,**/*.test.tsx,**/*.stories.tsx"
 ---
 
-# Testing and Storybook instructions
+# Tests and stories
 
-- Prefer story `play` functions + `yarn storybook:test` for user flows; Vitest for logic/non-browser.
-- Prefer focused assertions over snapshots unless nearby tests use them.
-- Cover main path + 1-2 meaningful edge cases.
-- UI behavior change: update nearest story + test in same change.
-- Testing Library: query by role and name.
-- Stories use `@storybook/react-vite`, live next to components.
-- Prefer `yarn storybook` for component work over `yarn dev`.
+- User flows: use a story `play` function in `<Component>.tests.stories.tsx`. Pure logic and hooks: use Vitest `*.test.ts(x)` next to the source file.
+- `corepack yarn storybook:test` runs every story that has a `play` function (Storybook auto-tags them `play-fn`, see root `vitest.config.ts`). To opt out, use `tags: ["!play-fn", "skip-test"]` with a reason.
+- Play-test files set `parameters: { chromatic: { disable: true } }`. Visual stories feed Chromatic; use `renderStoriesForChromatic` from `utils/` when adding visual variants.
+- Import from `@storybook/react-vite` and `storybook/test`, not `@storybook/react` or `@storybook/test`.
+- Query by role and accessible name (`getByRole("button", { name })`). Avoid snapshots unless nearby tests already use them.
+- Cover the main path plus 1-2 meaningful edge cases. A behavior change updates the nearest story and test in the same change.
+- ds-react unit tests run with `TZ=UTC`. Date logic must not depend on the local timezone.
+- Browser tests need Playwright Firefox. Yarn has `enableScripts: false`, so if the browser is missing, report it instead of installing globally.

.github/instructions/tokens.instructions.md

@@ -0,0 +1,13 @@
+---
+description: "@navikt/ds-tokens and @navikt/ds-tailwind: token sources, generated output, build order."
+applyTo: "@navikt/core/tokens/**,@navikt/core/tailwind/**"
+---
+
+# Tokens and Tailwind
+
+- Token source of truth: `@navikt/core/tokens/src/tokens/**` (TypeScript), built with Style Dictionary (`src/index.ts`). Generated output: `dist/`, `token_docs.js`, and in tailwind `tailwind.config.js` and `tailwind4.css`. Never edit generated output; they're untracked.
+- Public CSS variables are `--ax-*`. Renaming or removing a token is breaking: it needs a major changeset plus a token migration in `@navikt/aksel` (see `src/codemod/v8-tokens/`) when consumers must migrate.
+- Light and dark themes are both generated. Check both when changing semantic color tokens.
+- Tailwind is built from `@navikt/ds-tokens/js`, so build tokens first: `corepack yarn workspace @navikt/ds-tokens build`, then `corepack yarn workspace @navikt/ds-tailwind build`.
+- Tests: `corepack yarn workspace @navikt/ds-tokens test` and `corepack yarn workspace @navikt/ds-tailwind test`.
+- `build` also generates the Figma config/plugin (`src/figma`). Changes there affect design tooling. Mention it in the PR.

.github/instructions/website.instructions.md

@@ -1,12 +1,14 @@
 ---
-description: "Website and playroom."
-applyTo: "aksel.nav.no/website/**, aksel.nav.no/playroom/**"
+description: "aksel.nav.no Next.js website: routers, examples/templates, Sanity data."
+applyTo: "aksel.nav.no/website/**"
 ---
 
-# Website and playroom instructions
+# Website (aksel.nav.no)
 
-- Stay in router already used nearby; don't mix `app/`/`pages/`.
-- `pages/eksempler/**` and `pages/templates/**`: only import from `@navikt/*` and `react`.
-- Reuse nearby utils/patterns before adding abstractions.
-- Prefer `yarn storybook:aksel` for examples/templates; `yarn dev` only for app-specific behavior.
-- `yarn storybook:aksel` needs no secrets. `yarn dev` needs `SANITY_READ_NO_DRAFTS`.
+- Both routers are in use: `app/` (App Router, `cacheComponents: true` in `next.config.ts`) and `pages/` (examples, templates, legacy). Stay in the router already used nearby. Don't move routes between them.
+- In `app/`, dynamic data needs Suspense or `"use cache"`, following nearby code. Cache Components errors at build time are real failures.
+- `pages/eksempler/**` and `pages/templates/**` are public code snippets. Use the `website-example` skill. ESLint rules `aksel-local/{import-check,comment-check,args-check}` enforce their shape.
+- Reuse `@/` utils and components nearby before adding abstractions.
+- Examples/templates: `corepack yarn storybook:aksel` (no secrets). `corepack yarn dev` only for app behavior; it needs `SANITY_READ_NO_DRAFTS` and `NPM_AUTH_TOKEN`.
+- Never run `update:*`, `backup` or other Sanity-writing scripts unless asked. They write to the CMS.
+- Tests: `corepack yarn workspace website test`. Examples: `corepack yarn workspace website validate:eksempler`.

.github/lsp.json

@@ -0,0 +1,22 @@
+{
+  "lspServers": {
+    "typescript": {
+      "command": "node",
+      "args": [
+        "./node_modules/typescript-language-server/lib/cli.mjs",
+        "--stdio"
+      ],
+      "fileExtensions": {
+        ".ts": "typescript",
+        ".tsx": "typescriptreact",
+        ".js": "javascript",
+        ".jsx": "javascriptreact",
+        ".mjs": "javascript",
+        ".cjs": "javascript",
+        ".mts": "typescript",
+        ".cts": "typescript"
+      },
+      "rootUri": "."
+    }
+  }
+}

.github/skills/add-changeset/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: add-changeset
+description: >
+  Create a Changesets entry for a user-facing change to a published Aksel
+  package without the interactive `yarn changeset` prompt. Use when a change
+  touches @navikt/ds-react, ds-css, ds-tokens, ds-tailwind, aksel-icons,
+  @navikt/aksel or aksel-stylelint and needs a version bump or changelog entry,
+  or when asked to "add a changeset".
+argument-hint: "Package(s) and a one-line summary of the change"
+---
+
+# Add changeset
+
+`yarn changeset` is interactive and will hang an agent. Write the file directly.
+
+## 1. Decide if a changeset is needed
+
+Needed: any consumer-visible change in a published package: behavior, props, CSS output, tokens, icons, CLI/codemods, types, or bug fixes.
+
+Not needed:
+
+- Changes only in ignored workspaces (`.changeset/config.json` → `ignore`: website, sanity-studio, playroom, mcp, tooling, figma plugin).
+- Stories, tests, internal refactors with identical output, docs and repo tooling.
+
+## 2. Pick the bump
+
+| Bump    | When                                                                                                                                  |
+| ------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `patch` | Bug fix, style fix, internal change with visible effect, new icon keyword                                                             |
+| `minor` | New component, prop, export, token, icon or codemod; new preview component                                                            |
+| `major` | Removed/renamed prop, export, CSS class or token, or changed default. Only when explicitly agreed: needs a codemod or migration notes |
+
+The packages in `config.json` `fixed` release together, so one bump moves all of them to the same version. Still list only the packages whose code changed.
+
+## 3. Write the file
+
+Path: `.changeset/<three-random-lowercase-words>.md` (e.g. `brave-owls-sing`). The slug must not already exist.
+
+```md
+---
+"@navikt/ds-react": minor
+"@navikt/ds-css": minor
+---
+
+Lookup: New component `Lookup`
+```
+
+Rules:
+
+- The summary starts with `<Component or area>:` (e.g. `Button:`, `Tokens:`, `Icons:`, `CLI:`), then what changed **for consumers**. One changeset per logical change.
+- Optional gitmoji after the colon is fine (`:tada:` for new components), matching nearby entries.
+- Don't edit `CHANGELOG.md`, package versions or `config.json`.
+
+## Done when
+
+The file exists, its frontmatter lists only changed published packages with valid bumps, and Prettier leaves it unchanged (`./node_modules/.bin/prettier --check .changeset/<file>.md`, or `corepack yarn prettier --check ...`).

.github/skills/aksel-local-validation/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: aksel-local-validation
+description: >
+  Select and run deterministic local validation for changes in the Aksel
+  monorepo. Use when linting, type-checking, testing, building, formatting, or
+  deciding which Yarn workspace commands cover changed files.
+argument-hint: "Changed files or feature area to validate"
+---
+
+# Aksel local validation
+
+Validate the smallest relevant surface with repository-pinned tools. Expand only when the result or dependency graph requires it.
+
+## Hard rules
+
+- Run repository commands through `corepack yarn`.
+- Prefer an existing root or workspace script. Otherwise use a binary already pinned in the root/workspace dependency graph.
+- Never use `npx`, `pnpx`, `pnpm dlx`, `yarn dlx`, a global binary, or a curl-piped installer.
+- Do not add a dependency only to run a one-off check. If the task truly needs new tooling, add and lock it explicitly.
+- Public consumer docs may intentionally show `npx @navikt/aksel`. Preserve those examples unless the task changes consumer setup.
+- If Corepack/Yarn reports a user-level configuration error, stop and report it. Never edit configuration outside the repository.
+- Do not claim type safety from ESLint or tests. Run a TypeScript-aware command when TypeScript behavior changed.
+
+## 1. Determine affected projects
+
+Start from changed files, not the whole repository:
+
+```sh
+git diff --name-only --diff-filter=ACMR
+git diff --cached --name-only --diff-filter=ACMR
+git ls-files --others --exclude-standard
+```
+
+For each file, read its nearest `package.json`, `tsconfig.json`, test, story, and export surface before choosing commands.
+
+| Path                            | Workspace                  | Preferred package checks                                                           |
+| ------------------------------- | -------------------------- | ---------------------------------------------------------------------------------- |
+| `@navikt/core/react/**`         | `@navikt/ds-react`         | `test` (Vitest + `tsc` type-check); `build` for export/type changes                |
+| `@navikt/core/css/**`           | `@navikt/ds-css`           | no `test` script: targeted `stylelint`, then `build` for imports/layers            |
+| `@navikt/core/tokens/**`        | `@navikt/ds-tokens`        | `test`, then `build` for generated output                                          |
+| `@navikt/core/tailwind/**`      | `@navikt/ds-tailwind`      | build `@navikt/ds-tokens` first, then `test` and `build`                           |
+| `@navikt/aksel-icons/**`        | `@navikt/aksel-icons`      | `test`; `build` for generation/export changes                                      |
+| `@navikt/aksel-stylelint/**`    | `@navikt/aksel-stylelint`  | `test`                                                                             |
+| `@navikt/aksel/**`              | `@navikt/aksel`            | `build` **before** `test` (`migrations.test.ts` reads `dist/`)                     |
+| `aksel.nav.no/website/**`       | `website`                  | `test`; `validate:eksempler` for examples/templates; avoid `build` (needs secrets) |
+| `aksel.nav.no/sanity-studio/**` | `aksel-sanity-studio`      | `type-check`, then `test` when behavior changes                                    |
+| `apps/playroom/**`              | `aksel-playroom`           | no `test` script: `sync-imports` when ds-react exports change                      |
+| `apps/mcp-server/**`            | `aksel-mcp`                | `test`, then `build`                                                               |
+| `apps/figma-icon-plugin/**`     | `aksel-icons-figma-plugin` | no `test` script: `build:plugin`                                                   |
+| `tooling/changelog/**`          | `aksel-changelog`          | `typecheck`                                                                        |
+| `tooling/analyzer/**`           | `aksel-analyzer`           | `test`                                                                             |
+
+Read the current manifest before running a table command. A manifest is source of truth if scripts change.
+
+## 2. Run changed-file lint
+
+Group only matching files:
+
+```sh
+corepack yarn eslint --max-warnings=0 --no-warn-ignored <changed .ts/.tsx/.js/.jsx files>
+corepack yarn stylelint <changed .css files>
+corepack yarn biome lint --no-errors-on-unmatched <changed supported source/config files>
+```
+
+Do not pass unsupported file types to make a command appear comprehensive. Documentation-only changes need no code validation unless a documentation check exists.
+
+## 3. Run TypeScript validation
+
+Use nearest applicable project:
+
+```sh
+corepack yarn tsc --noEmit --incremental false --project path/to/tsconfig.json
+```
+
+`--incremental false` prevents validation from creating `.tsbuildinfo` files. For a composite project, use its workspace build/type-check script instead.
+
+Prefer the workspace's own `type-check`, `typecheck`, or `build` script instead when it generates inputs, uses a build-specific tsconfig, or performs required transforms:
+
+```sh
+corepack yarn workspace <workspace> type-check
+corepack yarn workspace <workspace> typecheck
+corepack yarn workspace <workspace> build
+```
+
+If no suitable TypeScript command exists, report the gap. Do not substitute lint as a type-check.
+
+## 4. Run behavior tests
+
+Run the closest test file or workspace test command supported by that package. For visual or interaction changes, include the nearest story and Storybook browser test required by repository instructions.
+
+Examples:
+
+```sh
+corepack yarn workspace @navikt/ds-react test
+corepack yarn workspace website test
+corepack yarn workspace aksel-mcp test
+```
+
+## 5. Escalate deliberately
+
+Escalation order:
+
+1. changed-file lint;
+2. nearest TypeScript project;
+3. focused test or affected workspace script;
+4. dependent workspace build/test;
+5. root `lint`, `test`, or `boot` only for cross-workspace changes, shared configuration, generated public output, or a failure that requires broader evidence.
+
+Stop when every behavior and type surface touched by the change has a passing check. Report pre-existing or environment failures exactly; do not hide them with a weaker fallback.

.github/skills/code-review/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: code-review
+description: "Review Aksel changes or pull requests for consumer-breaking API changes, React 17/SSR compatibility, accessibility, export wiring, security, tests and changesets. Use when reviewing a branch, diff or pull request."
+argument-hint: "PR number, branch or files to review"
+---
+
+# Aksel code review
+
+## Repository context
+
+- Aksel is Nav's design system. The published `@navikt/*` packages are used across Nav on React 17–19, with SSR and CSR, in light and dark themes.
+- One bad release breaks many teams at once. Public API, accessibility and compatibility matter most.
+- Report findings. Don't edit code unless asked.
+
+## Process
+
+1. **Scope**: get the diff (`gh pr diff <n>` or `git diff origin/main...HEAD`) and the PR description. Note the stated goal.
+2. **Read**: for every changed file, read the surrounding code, component `index.ts`, stories, tests and the matching `.github/instructions/*.instructions.md`. Never review from the diff alone.
+3. **Check**: run the smallest validation that covers the change (`aksel-local-validation` skill). Tool output replaces style comments.
+4. **Analyze** against the checklist below.
+5. **Report** in the output format.
+
+## Priorities
+
+- 🔴 **Blocker**: must fix before merge. Breaks consumers, regresses accessibility, security issue or wrong behavior.
+- 🟡 **Suggestion**: should fix. Missing test, docs or changeset, maintainability risk, over-editing.
+- 💭 **Nit**: optional. Leave it out when in doubt.
+
+Skip anything ESLint, Stylelint, Biome, Prettier or TypeScript already catches. No praise-only or speculative comments. Every finding says **why** it matters and what to do.
+
+## Checklist
+
+### Public API (🔴)
+
+- Removed or renamed prop, export, CSS class, token or CLI command, or a changed default, on something already published → needs a `major` changeset, a deprecation path, or a revert.
+- New props and exports follow nearby naming and defaults. Prefer additive changes. Colors go through `data-color`, not new `variant` values.
+- Public props and components have JSDoc. `@default` and `@example` match behavior.
+
+### Compatibility (🔴)
+
+- No React 18/19-only APIs in `@navikt/*` (peer `react ^17 || ^18 || ^19`). Use the helpers in `@navikt/core/react/src/utils-external/` (`useId`, `useClientLayoutEffect`).
+- SSR-safe: no `window`, `document` or `localStorage` at module top level or during render.
+- No new runtime dependency in a published package without a clear reason (bundle size, consumer installs).
+
+### Accessibility (🔴)
+
+- Semantic HTML first. Correct roles, accessible names and states.
+- Full keyboard support, logical focus order, focus returned after close, visible `:focus-visible`.
+- Works in `forced-colors`, dark theme and at 200% zoom. Motion relies on the global `prefers-reduced-motion` handling.
+- User-facing strings use `useI18n`, with keys in `nb`, `nn` and `en` under `@navikt/core/react/src/utils/i18n/locales/`.
+
+### Wiring (🔴 for new public components)
+
+- Stable export: component `index.ts` → `@navikt/core/react/src/index.ts` → `package.json` `exports`. Preview: `@navikt/core/react/src/preview.ts` plus `"./PREVIEW/<Name>"`.
+- New CSS file is imported in `@navikt/core/css/src/index.css` with a `layer(...)`.
+- Removed published CSS classes are listed in `@navikt/aksel-stylelint/src/deprecations.ts`.
+
+### CSS and tokens (🟡)
+
+- `.aksel-<component>` prefix. State through `data-*` or ARIA selectors, not modifier classes.
+- Tokens only (`--ax-*`, internal `--__axc-*`). No hardcoded colors, spacing or radii.
+- Renaming or removing a token is breaking (🔴). Semantic color changes are checked in both light and dark.
+
+### Security and performance
+
+- 🔴 No `dangerouslySetInnerHTML` or unsanitized HTML from props. No secrets or `process.env` values leaking into published bundles or website client code.
+- 🔴 GitHub Actions: minimal `permissions`, new third-party actions pinned to a commit SHA, no untrusted input (`github.event.*`) interpolated into `run:`.
+- 🟡 No top-level side effects in library modules (breaks tree-shaking). No avoidable re-renders: stable context values, no new object or function props per render in hot paths.
+
+### Tests and docs (🟡)
+
+- A behavior change has a story `play` test or Vitest test proving the user-facing contract. Queries use role and accessible name.
+- Tests are deterministic: no dependence on timezone, current time or randomness.
+- Edge cases that are easy to miss: controlled vs. uncontrolled, `ref`/`className`/`...rest` forwarding, `as` prop, empty and very long content.
+- Website examples (`aksel.nav.no/website/pages/eksempler/`) are updated when usage changes.
+
+### Release (🟡, 🔴 if breaking)
+
+- User-facing change to a publishable package has a `.changeset/*.md` with the right bump and a `<Component>: <consumer-facing text>` summary. Website, playroom and tooling changes get none.
+- Breaking change that consumers can migrate mechanically has a codemod in `@navikt/aksel/src/codemod/transforms/`, registered in `@navikt/aksel/src/migrations-config.ts`.
+
+### Scope (🟡)
+
+- Over-editing: diff out of proportion to the stated goal (unrelated renames, refactors, reformatting, extra validation). Tests don't catch it, and it makes the diff hard to review.
+- No unrelated changes bundled. No skipped tests (`skip`, `!play-fn`) without a stated reason.
+- AI-generated code: patterns copied without adapting to Aksel conventions, error handling that looks right but isn't, missing edge cases. Ask the author to explain non-obvious design choices.
+
+## Output format
+
+```md
+### Summary
+
+What the change does, overall verdict and key risks (1–3 sentences).
+
+### Findings
+
+| File         | Line | Priority | Issue                                                   |
+| ------------ | ---- | -------- | ------------------------------------------------------- |
+| `Button.tsx` | 42   | 🔴       | `React.useId` breaks React 17: use internal `useId`     |
+| `button.css` | 10   | 🟡       | Hardcoded `#fff`: use `--ax-text-*` token for dark mode |
+
+### Details
+
+For each 🔴: why it matters and a suggested fix (short code snippet if helpful).
+```
+
+No findings: say so and list what you checked.
+
+## Boundaries
+
+- **Always**: read the actual code, run checks before reporting, order findings 🔴 → 🟡 → 💭.
+- **Ask first**: architectural changes, adding or removing dependencies, reviewing outside this repository.
+- **Never**: auto-fix or push, approve code you haven't read, skip the Public API, accessibility or security checks.

.github/skills/content-modeling-best-practices/SKILL.md

@@ -1,34 +0,0 @@
----
-name: content-modeling-best-practices
-description: Structured content modeling guidance for schema design, content architecture, content reuse, references versus embedded objects, separation of concerns, and taxonomies across Sanity and other headless CMSes. Use this skill when designing or refactoring content types, deciding field shapes, debating reusable versus nested content, planning omnichannel content models, or reviewing whether a schema is too page-shaped or presentation-driven.
----
-
-# Content Modeling Best Practices
-
-Principles for designing structured content that's flexible, reusable, and maintainable. These concepts apply to any headless CMS but include Sanity-specific implementation notes.
-
-## When to Apply
-
-Reference these guidelines when:
-
-- Starting a new project and designing the content model
-- Evaluating whether content should be structured or free-form
-- Deciding between references and embedded content
-- Planning for multi-channel content delivery
-- Refactoring existing content structures
-
-## Core Principles
-
-1. **Content is data, not pages** — Structure content for meaning, not presentation
-2. **Single source of truth** — Avoid content duplication
-3. **Future-proof** — Design for channels that don't exist yet
-4. **Editor-centric** — Optimize for the people creating content
-
-## References
-
-Start with the reference that matches the modeling decision in front of you, instead of loading every topic at once. See `references/` for detailed guidance on specific topics:
-
-- `references/separation-of-concerns.md` — Separating content from presentation
-- `references/reference-vs-embedding.md` — When to use references vs embedded objects
-- `references/content-reuse.md` — Content reuse patterns and the reuse spectrum
-- `references/taxonomy-classification.md` — Flat, hierarchical, and faceted classification

.github/skills/content-modeling-best-practices/references/content-reuse.md

@@ -1,127 +0,0 @@
-# Content Reuse Patterns
-
-Effective content models maximize reuse while minimizing duplication. Here are patterns for achieving both.
-
-## The Content Reuse Spectrum
-
-```
-Full Duplication ←————————————————→ Full Reference
-(Copy everything)                    (Link to one source)
-```
-
-Most real-world content sits somewhere in between.
-
-## Pattern 1: Shared Components
-
-Create reusable content blocks that can be embedded anywhere.
-
-**Use case:** Testimonials, FAQs, CTAs that appear on multiple pages.
-
-```typescript
-// Standalone testimonial documents
-defineType({
-  name: "testimonial",
-  type: "document",
-  fields: [
-    defineField({ name: "quote", type: "text" }),
-    defineField({ name: "author", type: "string" }),
-    defineField({ name: "company", type: "string" }),
-  ],
-});
-
-// Reference in page builders
-defineField({
-  name: "pageBuilder",
-  type: "array",
-  of: [{ type: "reference", to: [{ type: "testimonial" }] }],
-});
-```
-
-## Pattern 2: Shared Field Sets
-
-Extract common fields into reusable definitions.
-
-**Use case:** SEO fields, social metadata, common dates.
-
-```typescript
-// Shared field definition
-export const seoFields = [
-  defineField({ name: "seoTitle", type: "string" }),
-  defineField({ name: "seoDescription", type: "text" }),
-  defineField({ name: "ogImage", type: "image" }),
-];
-
-// Spread into multiple types
-defineType({
-  name: "page",
-  fields: [defineField({ name: "title", type: "string" }), ...seoFields],
-});
-
-defineType({
-  name: "post",
-  fields: [defineField({ name: "title", type: "string" }), ...seoFields],
-});
-```
-
-## Pattern 3: Taxonomy References
-
-Centralize classification for consistent tagging.
-
-**Use case:** Categories, tags, topics that span content types.
-
-```typescript
-// Central taxonomy
-defineType({
-  name: "category",
-  type: "document",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "slug", type: "slug" }),
-  ],
-});
-
-// Used across content types
-defineField({
-  name: "categories",
-  type: "array",
-  of: [{ type: "reference", to: [{ type: "category" }] }],
-});
-```
-
-## Pattern 4: Content Fragments
-
-Small, reusable pieces that combine into larger content.
-
-**Use case:** Bios, addresses, contact info.
-
-```typescript
-// Fragment type
-defineType({
-  name: "contactInfo",
-  type: "object",
-  fields: [
-    defineField({ name: "email", type: "email" }),
-    defineField({ name: "phone", type: "string" }),
-    defineField({ name: "address", type: "text" }),
-  ],
-});
-
-// Reused across types
-defineType({
-  name: "office",
-  fields: [
-    defineField({ name: "name", type: "string" }),
-    defineField({ name: "contact", type: "contactInfo" }),
-  ],
-});
-```
-
-## Anti-Pattern: Over-Abstraction
-
-Not everything needs to be reusable. If content is only used in one place, embedding is simpler.
-
-**Signs of over-abstraction:**
-
-- References that are only used once
-- Editors navigating multiple documents for one page
-- Complex queries joining rarely-shared content

.github/skills/content-modeling-best-practices/references/reference-vs-embedding.md

@@ -1,93 +0,0 @@
-# Reference vs Embedding Content
-
-When should content be linked (referenced) vs copied (embedded)? This decision affects reusability, query complexity, and editing workflows.
-
-## The Trade-offs
-
-| Aspect           | Reference                           | Embedded Object           |
-| ---------------- | ----------------------------------- | ------------------------- |
-| Reusability      | ✅ Shared across documents          | ❌ Copied per document    |
-| Single source    | ✅ Update once, reflects everywhere | ❌ Must update each copy  |
-| Query complexity | Requires joins/expansion            | Inline, simpler queries   |
-| Editing UX       | Separate editing interface          | All fields in one place   |
-| Independence     | Can exist on its own                | Only exists within parent |
-
-## When to Reference
-
-Use references when content:
-
-- **Is reusable** — Same author across many articles
-- **Needs central management** — Update product info once
-- **Has its own lifecycle** — Published/draft independent of parent
-- **Should stay in sync** — Price changes reflect everywhere
-
-**Examples:**
-
-- Author profiles
-- Product catalog items
-- Shared testimonials
-- Category taxonomy
-- Reusable CTAs
-
-## When to Embed
-
-Use embedded objects when content:
-
-- **Is unique to this document** — Page-specific hero
-- **Doesn't make sense alone** — SEO metadata
-- **Should be copied, not linked** — Historical snapshot
-- **Simplifies editing** — All fields in one form
-
-**Examples:**
-
-- SEO metadata
-- Page-specific sections
-- Address information
-- Social links
-- Configuration options
-
-## Sanity Implementation
-
-```typescript
-// Reference: Author is reusable
-defineField({
-  name: "author",
-  type: "reference",
-  to: [{ type: "author" }],
-});
-
-// Embedded: SEO is page-specific
-defineField({
-  name: "seo",
-  type: "object",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "description", type: "text" }),
-  ],
-});
-```
-
-## The Hybrid Approach
-
-Sometimes you want both: a reference for the canonical data, plus embedded overrides.
-
-```typescript
-defineField({
-  name: "featuredProduct",
-  type: "object",
-  fields: [
-    defineField({
-      name: "product",
-      type: "reference",
-      to: [{ type: "product" }],
-    }),
-    defineField({
-      name: "overrideTitle",
-      type: "string",
-      description: "Optional: Override the product title for this context",
-    }),
-  ],
-});
-```
-
-Query uses `coalesce(overrideTitle, product->title)`.

.github/skills/content-modeling-best-practices/references/separation-of-concerns.md

@@ -1,69 +0,0 @@
-# Separation of Content and Presentation
-
-The most important principle in structured content: **separate what content IS from how it LOOKS**.
-
-## The Problem
-
-When content is tied to presentation:
-
-- Redesigns require content migration
-- Content can't be reused across channels (web, mobile, voice)
-- Editors make design decisions instead of content decisions
-- A/B testing requires duplicate content
-
-## The Principle
-
-Model content based on **meaning and purpose**, not visual appearance.
-
-### Bad: Presentation-Focused
-
-```
-BigHeroText       → What if we want small heroes?
-RedButton         → What if brand colors change?
-ThreeColumnLayout → What if mobile needs one column?
-LeftSidebar       → Position is a frontend concern
-MobileImage       → Device-specific content is fragile
-```
-
-### Good: Meaning-Focused
-
-```
-Headline          → The main message (render however)
-CallToAction      → An action we want users to take
-Features          → A list of things (columns decided by frontend)
-RelatedContent    → Content relationships (position by context)
-Image             → One image with responsive crops
-```
-
-## Testing Your Model
-
-Ask: "If we completely redesigned the site, would these field names still make sense?"
-
-- `threeColumnFeatures` → ❌ Fails (what if 2 columns?)
-- `features` → ✅ Works (describes the content's purpose: a list of product features)
-- `blueHighlightBox` → ❌ Fails (what if we go purple?)
-- `callout` → ✅ Works (describes the content's role: an attention-grabbing aside)
-
-## Sanity Implementation
-
-```typescript
-// ❌ Avoid presentation-focused names
-defineField({ name: "bigHeroText", type: "string" });
-defineField({ name: "fontSize", type: "number" });
-defineField({ name: "backgroundColor", type: "color" });
-
-// ✅ Use meaning-focused names
-defineField({ name: "headline", type: "string" });
-defineField({
-  name: "emphasis",
-  type: "string",
-  options: { list: ["standard", "prominent"] },
-});
-defineField({
-  name: "tone",
-  type: "string",
-  options: { list: ["neutral", "warning", "success"] },
-});
-```
-
-The frontend translates `tone: 'warning'` to visual styles. Content stays semantic.

.github/skills/content-modeling-best-practices/references/taxonomy-classification.md

@@ -1,150 +0,0 @@
-# Taxonomy and Classification
-
-Organizing content with taxonomies enables filtering, navigation, and content relationships. Well-designed taxonomies scale; poorly designed ones become maintenance nightmares.
-
-## Types of Classification
-
-### Flat Taxonomy
-
-Simple list of terms with no hierarchy.
-
-**Use for:** Tags, simple categories
-**Example:** Blog tags: "javascript", "react", "tutorial"
-
-```typescript
-defineType({
-  name: "tag",
-  type: "document",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "slug", type: "slug" }),
-  ],
-});
-```
-
-### Hierarchical Taxonomy
-
-Terms with parent-child relationships.
-
-**Use for:** Product categories, content sections
-**Example:** Electronics > Phones > Smartphones
-
-```typescript
-defineType({
-  name: "category",
-  type: "document",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "slug", type: "slug" }),
-    defineField({
-      name: "parent",
-      type: "reference",
-      to: [{ type: "category" }],
-      description: "Parent category (leave empty for top-level)",
-    }),
-  ],
-});
-```
-
-### Faceted Classification
-
-Multiple independent dimensions.
-
-**Use for:** Complex filtering (e-commerce)
-**Example:** Filter by color AND size AND price range
-
-```typescript
-// Multiple taxonomy types
-defineField({ name: "color", type: "reference", to: [{ type: "color" }] });
-defineField({ name: "size", type: "reference", to: [{ type: "size" }] });
-defineField({
-  name: "material",
-  type: "reference",
-  to: [{ type: "material" }],
-});
-```
-
-## Design Principles
-
-### 1. Mutual Exclusivity (When Appropriate)
-
-Categories should be distinct. If items frequently belong to multiple categories, consider tags instead.
-
-**Categories:** One primary classification
-**Tags:** Many optional classifications
-
-### 2. User-Centric Naming
-
-Use terms your audience uses, not internal jargon.
-
-**Bad:** "Content Assets" (internal term)
-**Good:** "Resources" or "Downloads" (user term)
-
-### 3. Balanced Depth
-
-Too shallow: Everything lumped together
-Too deep: Users can't find anything
-
-**Rule of thumb:** 3-4 levels max for hierarchies
-
-### 4. Scalable Structure
-
-Design for 10x growth. Will your structure work with 10,000 items?
-
-## Querying Taxonomies
-
-### Get all items in a category
-
-```groq
-*[_type == "product" && category._ref == $categoryId]
-```
-
-### Get items in category OR children
-
-```groq
-// First get all descendant category IDs
-*[_type == "product" && category._ref in
-  *[_type == "category" && (
-    _id == $categoryId ||
-    parent._ref == $categoryId ||
-    parent->parent._ref == $categoryId
-  )]._id
-]
-```
-
-### Get category tree
-
-```groq
-*[_type == "category" && !defined(parent)]{
-  title,
-  slug,
-  "children": *[_type == "category" && parent._ref == ^._id]{
-    title,
-    slug,
-    "children": *[_type == "category" && parent._ref == ^._id]{
-      title,
-      slug
-    }
-  }
-}
-```
-
-## Common Mistakes
-
-### Over-categorization
-
-Creating a category for everything results in mostly-empty categories.
-
-**Fix:** Start minimal, add categories as content grows.
-
-### Inconsistent Granularity
-
-Some categories broad ("Technology"), others narrow ("React 18 Server Components").
-
-**Fix:** Define clear criteria for category creation.
-
-### No Governance
-
-Anyone can create taxonomy terms, leading to duplicates and inconsistency.
-
-**Fix:** Limit who can create/edit taxonomy documents. Use validation.

.github/skills/ds-component-restructure/SKILL.md

@@ -157,7 +157,7 @@ export type { <Component>TriggerProps };
 
 Update imports in `<Component>.meta.ts` to reflect new paths. If the meta file imports from the component's `index.ts`, no changes are needed.
 
-If component has no meta file, create one in the component root with the following content based on existing patterns.
+If component has no meta file, create `<Component>.meta.ts` in the component root. Copy the shape of `@navikt/core/react/src/accordion/Accordion.meta.ts`: import from `./index`, `name`, a `components` map using dotted keys for sub-components (`"Accordion.Item": AccordionItem`), and `keywords`, then `export { metadata }`.
 Note that each standalone component should have a meta file. But a "sub-component" (like `AccordionItem`) does not need a meta file.
 
 ### 7. Validate No Breaking Changes
@@ -169,7 +169,7 @@ Note that each standalone component should have a meta file. But a "sub-componen
 
 Concretely: grep for `export` lines in both versions and diff them. All component names and type names must match exactly.
 
-**Build.** Run `yarn workspace @navikt/ds-react build` — must succeed with no TypeScript errors.
+**Build.** Run `corepack yarn workspace @navikt/ds-react build` — must succeed with no TypeScript errors.
 
 **Package root.** Verify `@navikt/core/react/src/index.ts` still re-exports the component. No changes needed there unless the component's `index.ts` path changed (it shouldn't).
 
@@ -282,10 +282,7 @@ dialog/
 - **No breaking changes.** Public export names and prop shapes must be identical after restructuring.
 - **Named exports only.** No `default` exports; group named exports at the bottom of each file (values first, then types).
 - **Compound roots use `Object.assign`.** No `as <Component>Component` cast or `<Component>Component` interface — it breaks `yarn docgen:meta` prop extraction.
-- **React 17 compatible.** No React 18/19-only APIs. Import React explicitly in `.tsx` files.
-- `index.ts` must start with `"use client"`.
-- Use tokens, not hardcoded values.
-- Preserve `forwardRef`, `className`, `...rest`, `as`/`OverridableComponent` patterns.
+- Component rules (React 17 compatibility, `"use client"`, `forwardRef`/`className`/`...rest`/`as`, tokens) live in `.github/instructions/ds-react-component.instructions.md`. They still apply.
 - Keep JSDoc on public props and components. The component-level JSDoc block sits directly above the `Object.assign` call; sub-component `@see` tags go on the keys inside the `Object.assign` object literal.
 
 ## Reference Files

.github/skills/next-cache-component-adoption/SKILL.md

@@ -1,234 +0,0 @@
----
-name: next-cache-components-adoption
-description: >
-  Turn on Cache Components in a Next.js app and resolve the blocking routes it
-  surfaces. Use when the user wants to enable, adopt, or migrate to Cache
-  Components, flip the `cacheComponents` flag, work through a flood of
-  blocking-prerender / instant validation errors, run the
-  `cache-components-instant-false` codemod, or decide between opting routes out
-  with `export const instant = false` and fixing them in place.
----
-
-# next-cache-components-adoption
-
-Enable Cache Components on an app and walk it to a passing build. This skill sequences the work; per-error recipes live in the dev overlay fix cards and the build's terminal output. The [migrating to Cache Components guide](https://nextjs.org/docs/app/guides/migrating-to-cache-components) is the canonical reference for the concepts and per-API recipes this skill applies — consult it whenever the skill steps reference a pattern (`"use cache"`, `cacheLife`, `<Suspense>` placement, etc.) and you want the full explanation.
-
-## requires
-
-- **App Router project.** Cache Components is an App Router feature; `cacheComponents: true` does nothing for `pages/` routes. If the project has a `pages/` or `src/pages/` tree but no `app/` or `src/app/` tree, stop and tell the user — Pages → App migration is its own project, not part of this skill. A hybrid app (both `pages/` and `app/`) is fine: the flag affects the `app/` routes; `pages/` routes are unaffected and don't need opt-outs.
-
-- **Next.js 16.3 or later.** That release is where the pieces this skill relies on land: top-level `cacheComponents`, `export const instant`, the dev-overlay instant-navigation validation warnings, and the `cache-components-instant-false` codemod. If `next --version` reports below 16.3, upgrade first:
-  - `npx @next/codemod@latest upgrade latest` to apply the version-to-version codemods.
-  - Read the relevant [version upgrade guide](https://nextjs.org/docs/app/guides/upgrading) (e.g. [Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16)) for what the codemod doesn't cover.
-
-- **No incompatible config keys.** `cacheComponents: true` errors on any file that still exports `dynamic`, `revalidate`, or `fetchCache`. **Translate, don't delete.** Each export encodes behavior the route needs to keep doing; migrate each one to its Cache Components equivalent via the [migration guide's per-key sections](https://nextjs.org/docs/app/guides/migrating-to-cache-components#enable-cache-components). If a value can't be cleanly translated yet, leave a `// TODO: Cache Components adoption — restore revalidate = 3600` comment so the loop picks it up. The `cache-components-instant-false` codemod does not touch these.
-
-- **`experimental.dynamicIO` is fatal.** It was renamed to top-level `cacheComponents` and the old key now aborts before any build can run — remove it (or replace with `cacheComponents: true`) first. `experimental.useCache` is still accepted as a deprecated alias; redundant once `cacheComponents: true` is set, so remove it for clarity.
-
-### notes
-
-- **No passing baseline before the flag.** If the app already uses `"use cache"`, the pre-flag build errors with `please enable the feature flag cacheComponents`. Enabling the flag is the first thing you do (in Incremental, before the codemod; in Direct, before fixing routes) — not a thing to do _after_ getting a passing build. Note this in your starting summary so it doesn't read as a regression.
-
-- **Offline docs.** Guide links have offline copies under `node_modules/next/dist/docs/` (bundled since Next.js 16.2), with the directory layout numbered for ordering (e.g. `node_modules/next/dist/docs/01-app/02-guides/migrating-to-cache-components.md`). If you can't predict the numbered prefix, `find node_modules/next/dist/docs -name '<slug>.md'` resolves it. The `/docs/messages/*` error pages are not bundled.
-
-- **Older versions without bundled docs.** Suggest `npx @next/codemod@latest agents-md` to the user before starting: it downloads a version-matched copy to `.next-docs/` and writes an index into `AGENTS.md` / `CLAUDE.md`. It touches files in their repo, so ask first and run it only if they want it.
-
-## the shape of the work
-
-There's one loop: walk the route tree top-down, one feature at a time, adopting each route against `next dev` + a browser. The build is a final check for each feature, not the working surface.
-
-The choice in step 1 is whether to opt every route out of validation first or fix routes as you go. Either way the loop is the same:
-
-- **With a quiet pre-step (Incremental).** Run the codemod to opt every page and layout out of validation. Once you've also fixed what the codemod can't (sync-IO calls, leftover `revalidate`/`dynamic`/`fetchCache` exports), the build passes; you ship that as its own PR and then start the loop — removing one opt-out at a time and adopting that route. This splits the work into small, reviewable PRs.
-- **Without (Direct).** Enable `cacheComponents` and start the loop on whatever the build flags first. Same loop, but every fix sits on one branch until adoption is complete.
-
-In both, the per-route success bar is the same: **dev loop reports no errors AND `next build` passes**. Check in with the user after every feature. Expect to spend most of the time in the loop, not in the pre-step.
-
-## background
-
-`cacheComponents: true` requires every route to be prerenderable. A route that reads request-time data outside `<Suspense>` is "blocking" and fails the build. `export const instant = false` marks a route as allowed to block, which clears it in both dev and build; on a layout it covers the whole subtree during the build, but client navigations still validate each descendant segment on its own. Reads wrapped in a [`"use cache"`](https://nextjs.org/docs/app/api-reference/directives/use-cache) function count as cache boundaries, not blocking reads.
-
-Three classes of blocker come up, usually in this order:
-
-1. **Request-time reads** (`cookies()`, `headers()`, `await params`, `await searchParams`). All four block when awaited at the top of a page or layout. `params` and `searchParams` often get missed because they're not framed as "request data" the way cookies and headers are. The fix is to push the read into a `<Suspense>`-wrapped child — and for `params`/`searchParams`, forward the promise into the child and await it there; don't `await` at the page top.
-2. **Sync-IO at module/render time** (`new Date()`, `Date.now()`, `Math.random()`, `crypto.randomUUID()`). These fail the build even with `instant = false` — the opt-out doesn't suppress them. If they're in a shared layout, they block every route under it. The codemod can't fix them; you have to translate each one by hand before the build can pass (see the [incremental pre-step](#incremental)). Grep the whole repo for these calls before running anything else.
-3. **`"use cache"` files that read request data.** A file with a top-level `"use cache"` directive can't export `instant`; combining the two errors with `Only async functions are allowed to be exported in a "use cache" file.`, which means the directive was wrong for that route. Remove it before running the codemod.
-
-## working surfaces
-
-### finding blocking routes
-
-Prefer `next dev` over `next build` while you work.
-
-- **`next dev`** — the working surface. Visit a route; its blocking errors surface in the dev overlay with full stack traces and fix cards linking the per-error docs. Work one route at a time — errors don't accumulate in one place. The route itself still returns HTTP 200, so read the overlay (or `.next-dev.log`), not status codes. A cleared overlay is one half of calling a route clean — the other half is browser verification (see [step 2](#step-2-the-inner-loop-remove-opt-outs-one-feature-at-a-time)) and a passing build for that route.
-- **`next build`** — detection only. The build is `next dev`'s authoritative check, not its replacement. Use it as the last gate on each feature in the loop (a passing build is part of the per-route success bar) and as the final verification across the whole app. In Incremental, the build also confirms the pre-step (codemod opted every route out, no shared layout still has a sync-IO blocker) before you ship that PR. Don't reach for the build instead of the dev loop while you're working a route — a passing compile doesn't tell you what ended up in the static shell and what streamed. By default the build stops at the first blocking route, so it's also poor for sizing the work. Two flags help when iterating: `--debug-build-paths` builds only the routes you name (comma-separated glob patterns of file paths relative to the project root, e.g. `--debug-build-paths="app/admin/**/page.tsx"` — not URL paths; `--debug-build-paths="app/(marketing)/about/page.tsx"` — not `/about`; `--debug-build-paths="app/admin"` matches nothing and silently builds zero routes), and `--debug-prerender` disables the early exit so the build continues past the first prerender failure, reports every blocking route, and prints a fuller stack trace that names the originating file and line.
-
-Every blocking error has a docs page — open it. Both the dev overlay and the build terminal print a `https://nextjs.org/docs/messages/<slug>` link with each error. That page is the canonical recipe for the fix; the inline message is a summary. Fetch the link for every distinct error you encounter, even if you think you know the pattern — the recipes evolve, and the same error class can have different correct fixes depending on what the route reads. Don't improvise from the inline message alone. (`/docs/messages/*` pages aren't bundled offline; if you have no network, fall back to the per-API guides under `node_modules/next/dist/docs/` and note the limitation when you report back.)
-
-### verifying each fix at runtime
-
-A passing build or a cleared overlay isn't proof the route actually behaves — Cache Components is a runtime concern (a static shell with streamed data). Verify after every fix, not only at the end.
-
-In preference order:
-
-1. **[`next-dev-loop`](https://github.com/vercel/next.js/tree/canary/skills/next-dev-loop) — strongly preferred.** Cross-checks `/_next/mcp` against the live browser via `agent-browser` and surfaces both compile and runtime issues in one pass. The diagnostics (React tree, suspense boundaries, console + network) are richer than poking at `next dev` by hand.
-
-   Install it before starting the loop. Don't wait until you hit something `next dev` alone can't explain. Run:
-
-   ```bash
-   npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-dev-loop
-   ```
-
-   The skill requires `agent-browser >= 0.27.0` and walks you through it.
-
-   **Requires Turbopack.** If `package.json`'s `dev` script passes `--webpack`, flag it to the user and ask whether there's a reason to stay on webpack. If not, switch to Turbopack (the Next.js 16.3+ default). If they want to keep webpack, skip this install and use the [build-only loop](#the-loop-build-only-fallback) instead.
-
-   You don't need permission to install `next-dev-loop` itself. It's a tool, like installing a dev dependency. If a user is present, briefly tell them you're installing it for verification. In a non-interactive run (CI, dashboard, sandbox), install it without asking — "can't prompt the user" is not a reason to skip. The only legitimate skip is a real technical blocker: no network, no npm, read-only filesystem, a stated no-new-deps policy, or a webpack-only dev script. If you skip, name the specific blocker in your final report.
-
-2. **A browser you can drive yourself.** Playwright, `agent-browser` directly, any browser-automation tool. Use only when `next-dev-loop` is genuinely blocked. You'll miss the framework-side checks (`/_next/mcp`), so DOM assertions alone don't catch every regression — be more cautious about what you call "verified."
-
-3. **Build-only.** If you can't run a dev server at all, the build is your only signal. `○ (Static)` routes with no `<Suspense>` are fully verified by the build (nothing streamed to test). `◐ (Partial Prerender)` routes are only shell-verified — flag them when you report back.
-
-4. **No tooling at all.** Ask the user to run the dev server (or build) and report what they see, or commit the milestone you've reached and hand off.
-
-## step 1: choose a strategy
-
-Ask the user, in terms of the PRs they want, not the size of the job. Never use the internal labels (Incremental, Direct) when talking to the user — those are your own scaffolding. Ask in terms of PRs and features, e.g.: _"Do you want me to first open a PR that turns on Cache Components and opts every route out of validation, then handle the actual route adoptions feature-by-feature in follow-up PRs? Or do everything on one branch?"_ Even on a tiny app, the incremental path still has value (review-sized PR, revertible, the `// TODO: Cache Components adoption` markers double as your work queue for next session). Don't pick on their behalf.
-
-If there's no user to ask, default to **Incremental** and document the choice.
-
-- **Incremental** — quiet pre-step + the loop. Run the codemod to opt every page and layout out of validation, get the build passing, stop and check in with the user (see [end of the pre-step](#end-of-the-pre-step-check-in)), then enter [step 2's loop](#step-2-the-inner-loop-remove-opt-outs-one-feature-at-a-time) and ship each feature as a follow-up PR.
-- **Direct** — skip the pre-step. Enable `cacheComponents` and go straight to [step 2's loop](#step-2-the-inner-loop-remove-opt-outs-one-feature-at-a-time); the build's blocking routes are the work queue.
-
-### incremental
-
-Before invoking the codemod, fix the two classes of blocker it can't.
-
-1. **Sync-IO at module/render time.** Grep the whole repo for `new Date()`, `Date.now()`, `Math.random()`, and `crypto.randomUUID()` (not only `app/**/layout.{js,jsx,ts,tsx}` — the read might live in any component imported by a layout). Unblock each match with the `await connection()` + `<Suspense>` fix from its `blocking-prerender-*` error card: it defers the value to request time, exactly as it behaved before the migration, so it needs no product decision. Add this exact comment on the line above the `await connection()`:
-
-   ```tsx
-   // TODO: Cache Components adoption. Added to unblock the build: remove this connection() to re-trigger the error and review the fix options.
-   ```
-
-   It shares the `TODO: Cache Components adoption` prefix with the comments the codemod writes, so the check-in grep finds both. Removing the `await connection()` makes the error fire again with its fix cards — the same motion as removing an opt-out in the loop.
-
-2. **Incompatible segment configs.** Grep for `^export const (revalidate|dynamic|fetchCache)` across `app/` and translate per the `requires` note above. The codemod does not touch them; leaving them in place fails the build after the codemod.
-
-The codemod refuses to run on a dirty working tree. Commit or stash unrelated work first, or pass `--force` to let its edits land alongside your WIP. Common false positive: if you recently upgraded Next.js, `package.json` and the lockfile will already be dirty — commit those first.
-
-Use the `@canary` channel, not `@latest`. The `cache-components-instant-false` transform isn't in the stable `@next/codemod` release; `@next/codemod@latest` errors with `Invalid transform choice`.
-
-```bash
-npx @next/codemod@canary cache-components-instant-false ./app
-```
-
-Inserts `export const instant = false` (with a `// TODO: Cache Components adoption` comment) into every `app/**/{page,layout,default}` file, skipping files that already declare `instant` and any module marked `"use client"` or `"use server"`. Then set `cacheComponents: true`. The TODO comments are the work queue for the loop.
-
-If the codemod isn't available (older `@next/codemod`, sandboxed environment, offline run), reproduce it by hand: for every `app/**/{page,layout,default}.{js,jsx,ts,tsx}` that isn't `"use client"` or `"use server"` and doesn't already declare `instant`, insert this after the imports:
-
-```ts
-// TODO: Cache Components adoption. Refactor this route so this opt-out can be removed.
-// See: https://nextjs.org/docs/app/guides/migrating-to-cache-components
-export const instant = false;
-```
-
-The codemod opts every segment out, not only the root, on purpose. Resolution is top-down, first-explicit-config-wins: the highest `instant = false` decides the whole subtree. With an opt-out on every segment, removing one segment's opt-out validates only that segment; descendants keep their own opt-outs and stay passing. If only the root were opted out, removing it would re-arm validation for the entire app at once.
-
-Because the highest opt-out wins, remove them top-down (root layout first, then descend). Removing a leaf's opt-out does nothing while an ancestor still holds one.
-
-Confirm the pre-step with `next build`. The build is the proof, not the codemod run — a shared layout that calls `new Date()` / `Math.random()` directly still fails regardless of the opt-out (see [background](#background)).
-
-After the build passes, confirm the root layout got an opt-out (`grep -n "export const instant" app/layout.*`). The root layout renders every route, including framework routes like `/_not-found`, so if it was missed, add `export const instant = false` to it by hand.
-
-Synthetic routes like `/_not-found` have no user file — when they block, fix the root layout's opt-out, not the synthetic route. Client Components (`"use client"`) get no opt-out (it's a build error — `E1344` — to export `instant` from them) and rarely block on their own; when a client route blocks, fix the server-side data in its ancestor layout.
-
-### end of the pre-step: check in
-
-Incremental only. Stop here before starting step 2 — the pre-step is the shippable PR. Talk to the user in their language; don't say "Incremental" or other internal labels; talk about adoption, PRs, and what the app does now. Tell them:
-
-- What you did: turned on Cache Components, ran the codemod that opts every page and layout out of the new validation (or did it by hand), fixed any blockers the codemod can't (list them), confirmed the build passes.
-- What changed: every page and layout in `app/` now exports `instant = false` with a `// TODO: Cache Components adoption` comment, except client components and any that already had an `instant` export.
-- What to sanity-check: the diff is mostly mechanical (new exports + comments). The build passes. Routes still behave exactly as they did before — the opt-outs preserve current behavior; no rendering changes yet.
-- The question: "Want to open this as its own PR before we start adopting Cache Components route by route? Or keep going on this branch?" Wait for the answer.
-
-Moving to step 2 without checking in defeats the point of taking the incremental path.
-
-### direct
-
-Set `cacheComponents: true` and move to [step 2](#step-2-the-inner-loop-remove-opt-outs-one-feature-at-a-time). The build's blocking routes are the work queue.
-
-## step 2: the inner loop, remove opt-outs one feature at a time
-
-A "feature" is a single product surface — `app/settings/profile/**`, `app/posts/[slug]/**` — not a whole top-level app like `app/dashboard/**`. Finish one end-to-end before starting the next.
-
-Within a feature, walk top-down (layouts before pages, root layout first). Removing a layout's opt-out before its descendants exposes the layout's own blocking reads. (Direct: there are no opt-outs to remove — fix each failing route; if a hand-written opt-out on an ancestor shadows it, remove that first.)
-
-A passing build mid-walk doesn't mean the layout is clean. Removing a layout's opt-out while its descendant pages still have theirs keeps the build passing — each page shadows the inherited validation. The layout's actual blocking reads only surface once nothing below it shadows them. Don't call a feature done at the layout boundary.
-
-Use the **with-a-browser** loop unless a browser is genuinely unreachable. The [`next-dev-loop`](#verifying-each-fix-at-runtime) skill is the source of truth for what counts as "browser available" and how to install it.
-
-### the loop, with a browser (preferred)
-
-Per route:
-
-- Remove the opt-out (Incremental) or target the failing route (Direct).
-- Reload in dev. Overlay clean? Skip to verify. Overlay still red? Fix.
-- Fix — fetch the docs page linked from the error (`https://nextjs.org/docs/messages/<slug>`), apply the recipe from there. The inline overlay text is a summary; the docs page is the source of truth.
-- Verify in the browser. Confirm the visible content on first paint is what you intended in the shell — not stuck on a fallback, not silently streaming everything out of an empty shell.
-- Re-check siblings if the fix touched shared code (a layout, a sidebar component). A shared-shell change can fix the route you're on and break a sibling.
-
-### the loop, build-only (fallback)
-
-Used when there's no way to drive a browser — CI, sandbox, the user has no `next dev` running and you can't start one. Weaker signal: confirms the build passes and the route prerenders, but not what ended up in the static shell vs streamed.
-
-Per route:
-
-- Remove the opt-out (Incremental) or target the failing route (Direct).
-- Rebuild with `--debug-build-paths app/<route>/**` (only that route) or `--debug-prerender` (full build, but past the first failure). Route passing? Move on. Still blocking? Fix.
-- Fix — fetch the docs page linked from the error (`https://nextjs.org/docs/messages/<slug>`), apply the recipe from there.
-- Re-check siblings if the fix touched shared code.
-- Flag the route as build-only-verified when you hand the feature off. Each `◐` route still needs a browser pass before the feature is done.
-
-### loop notes
-
-- The [three blocker classes from background](#background) often get missed when fixing in place. Caching a downstream fetch (`getThing(id)`) doesn't clear an `await params` at the top of the page body — push the param promise into the `<Suspense>`-wrapped child.
-- Ambiguous calls are user check-ins, not agent judgment. When you're not sure which fix fits, the blocking code looks security-sensitive, or the user might want to keep the route blocking on purpose — read [references/per-page-decisions.md](./references/per-page-decisions.md) before editing. Show the route while you ask: the `next-dev-loop` session runs the browser headed, so drive to the page and leave it on screen so the user is looking at the thing they're deciding about, with a screenshot as the fallback when a headed browser isn't possible. "Should this stay blocking?" is much easier to answer while looking at the page than at a file path.
-- Don't narrate the refactor with comments. The only comment the codemod (or you) should leave is `// TODO: Cache Components adoption` on opt-outs, and the user's existing comments. Don't annotate every `<Suspense>` boundary or `"use cache"` call with what it does — the code says that. Drop a comment only when the _why_ isn't clear from the code (e.g. a deliberate Block with a reason).
-
-Keep a todo list of the feature's routes. When every route in the feature is clean, move to step 3.
-
-## step 3: verify the feature
-
-Checklist before checking in with the user:
-
-- `next build` completes without blocking-route errors.
-- No bare TODOs in the feature: `grep -rn "TODO: Cache Components adoption"` finds both the codemod's opt-out comments and the sync-IO unblocks from the pre-step. Any `instant = false` left behind is a deliberate, documented Block — comment rewritten to a reason (see [references/per-page-decisions.md](./references/per-page-decisions.md) → "when to leave a Block in place"). Any `await connection()` left behind has been reviewed and kept on purpose, not left over from the pre-step.
-- Each route visited in the browser: confirm the static shell renders first and every `<Suspense>` fallback resolves to its real content. Capture both states if you can — the fallback (mid-stream) and the final paint — so you have a streaming-experience demo to show the user. Throttle the network in the browser if streaming is too fast to observe.
-
-Then check in with the user. Same rule as the pre-step: speak their language. Don't say "feature-by-feature loop" or other internal labels; talk about the feature you adopted and what the user will see.
-
-- What you did: which routes you touched, and the user-visible result per route (e.g. "the post page now streams the article body behind a skeleton while the layout stays static").
-- What changed: opt-outs removed, fallbacks added, caching boundaries introduced.
-- Show, don't tell. The `next-dev-loop` session runs the browser headed, so drive the route live for the user so they see the static shell → fallback → final content sequence in real time. If you can't drive a live browser, attach the before/after screenshots you captured instead.
-- Give them the click-through: a short table of the feature's routes — the URL to open and what to look for (what renders instantly, which fallbacks appear, what streams in) — so they can verify each one themselves.
-- The question: "Want to open this feature as a PR and move on to the next, or stop here?" Wait for the answer.
-
-**Trivial features can skip the check-in.** If adopting a feature only meant removing its `// TODO: Cache Components adoption` opt-out (no `<Suspense>` added, no `'use cache'` introduced, no render order change), the user sees nothing different. Move on to the next feature without stopping; mention it in passing the next time you do check in.
-
-When the loop has run on every feature — every remaining `instant = false` sits under a reason comment, `grep -rln "TODO: Cache Components adoption" app` returns nothing — point the user at [further reading](#further-reading) if they want to push the experience further, or stop and ship.
-
-### route table glyphs
-
-`ƒ` → `◐` is where adoption usually lands. `◐ (Partial Prerender)` means a static shell prerenders and the request-time content streams in — the goal state for any route that reads `cookies()`, `headers()`, `params`, or `searchParams`. Some routes legitimately stay `ƒ` when they do request-time work through a documented escape hatch (e.g. a layout that uses `await connection()`); the page is no longer _opted out_, it's genuinely dynamic. Don't remove the escape hatch only to chase a `◐`. The inverse holds: `instant = false` does not force a route to be `ƒ`. The glyph reflects what the route does at prerender time, not which validation knobs it exports.
-
-`◐` tells you a shell exists, not what's in it. A `<Suspense>` boundary placed too high (e.g. wrapping the entire page body, or `<Suspense fallback={null}>` around the article content) pushes the visible content out of the static shell into the streamed payload; the build still reports `◐` because _some_ shell prerendered (often only `<html><body>` with framework markup). The route table can't tell you what's in the shell; a browser can. If the shell is empty and everything streams, pull the `<Suspense>` boundary down closer to the actual dynamic read.
-
-## further reading
-
-The work below is optional and lives in the docs — link the user to them and let them decide which to take on next. Don't walk these through inside this skill.
-
-- [Instant navigation](https://nextjs.org/docs/app/guides/instant-navigation) — dev-only validation warnings the overlay raises on client navigation. Same shape as the blocking-prerender errors you cleared in step 2; the guide covers the per-warning details. Recommend it next if the user wants navigations to actually be instant (a passing build doesn't guarantee that — a `<Suspense>` above the shared layout caught the page-load case but doesn't cover client navigation).
-- [`next-partial-prefetching-adoption`](https://github.com/vercel/next.js/tree/canary/skills/next-partial-prefetching-adoption) — the follow-up skill that adopts Partial Prefetching: it audits `<Link prefetch={true}>` calls (driven by the dev overlay's `link-prefetch-partial` warning) with the flag off first, then flips the `partialPrefetching` config. It sequences this the same way this skill sequences Cache Components, but the insights are dev-only, so it's a browser click-through, not a build loop. Recommended after instant navigation, since those fixes feed directly into how much of each route the shell can prefetch. Concepts live in the [Adopting Partial Prefetching guide](https://nextjs.org/docs/app/guides/adopting-partial-prefetching).
-- [Prefetching](https://nextjs.org/docs/app/guides/prefetching) and [Runtime prefetching](https://nextjs.org/docs/app/guides/runtime-prefetching) — broader prefetching reference. Runtime prefetching extends the static shell with per-session content; reach for it when a route's shell is too thin to be useful and Partial Prefetching alone doesn't cover the gap.
-- [Prevent regressions with e2e tests](https://nextjs.org/docs/app/guides/instant-navigation#prevent-regressions-with-e2e-tests) — the `@next/playwright` [`instant()`](https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config/instant#testing-instant-navigation) helper asserts on the UI that's available immediately on navigation, so regressions surface in CI. Recommend it once a route is instant: `next-dev-loop` confirms it _now_; an `instant()` test keeps it that way.
-- [`next-cache-components-optimizer`](https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-optimizer) — a separate skill that grows each route's static shell so more of the page prerenders and less streams in. Pure optimization, not part of adoption.

.github/skills/next-cache-component-adoption/references/per-page-decisions.md

@@ -1,25 +0,0 @@
-# per-page decisions: removing `instant = false`
-
-Read this when a route still blocks after you remove its `instant = false` and the dev overlay's fix card isn't enough on its own. Each section here covers a judgment call the agent shouldn't make alone.
-
-## deciding what to do with a blocking read
-
-Read the full linked page behind the fix card — not only the inline snippet — before editing. The card unblocks the build, but the page covers the details that make the route's navigation actually instant (e.g. where to place a `<Suspense>` boundary). Don't improvise.
-
-If you're unsure which fix fits, the right call usually depends on what this part of the page is _for_, which the code doesn't capture. Ask the user about their goal for it rather than guessing. Frame it as a product/UX question: should this content be there instantly on load, or is it fine for it to stream in a moment later? Should everyone see the same thing (cacheable) or is it per-user / per-request? Tie the technical fix to that answer (cache it, wrap it in `<Suspense>`, or keep it request-time), so they're deciding the experience, not the API.
-
-## security gates and other code you can't infer
-
-If the blocking code looks like it's there for a _reason you can't infer_ — a security gate at the page top (`await verifyAccess()`, an auth redirect, a feature-flag check) where moving it inside `<Suspense>` would change what the code guarantees — stop and ask the user before refactoring. The build error wants `<Suspense>`, but wrapping a gate in `<Suspense>` defeats the gate. Only the person who wrote it knows whether to keep the route blocking (`instant = false` as a documented Block), restructure the page so the gate runs differently, or move the check to [Proxy](https://nextjs.org/docs/app/api-reference/file-conventions/proxy).
-
-If _every_ route under a layout is gated this way, a documented Block on the layout is the correct end state. Moving the gate to [Proxy](https://nextjs.org/docs/app/api-reference/file-conventions/proxy) is the architectural fix, not a Cache Components one, and that's a follow-up rather than something to hold the migration on.
-
-For the broader picture, read the [Authentication guide](https://nextjs.org/docs/app/guides/authentication) (where auth checks belong: Proxy for routing, Data Access Layer for data) and the [Data Access Layer section of Data Security](https://nextjs.org/docs/app/guides/data-security#data-access-layer) (centralized auth checks that compose with `'use cache'`).
-
-If you don't know how to make a piece of code Cache Components–correct without changing what it does, ask.
-
-## when to leave a Block in place
-
-If a route is genuinely meant to block — it's inherently per-request with no useful static shell — or the refactor would be large and the user would rather not take it on now, that's a legitimate outcome. Keep `instant = false`, but confirm it with the user first and turn its `// TODO: Cache Components adoption` comment into a reason, e.g. `// instant = false: kept on purpose — fully request-time dashboard` or `// instant = false: deferred, refactor too large for now`.
-
-A documented, deliberate Block is fine to leave after the migration; an undocumented leftover opt-out is not.

.github/skills/next-cache-component-optimizer/SKILL.md

@@ -1,453 +0,0 @@
----
-name: next-cache-components-optimizer
-description: >
-  Drive a Next.js route to instant navigation by setting up an agentic loop,
-  under Cache Components / PPR, on initial load (hard navigation) and
-  client-side navigation (soft navigation). Encode the goal as a failing
-  @next/playwright instant() e2e and work it to green, one verified route at a
-  time; the shipped test then guards against regression. Use when asked to make
-  a route's navigation instant (its static shell commits immediately), fix a
-  route whose static shell isn't prerendered/served/prefetched, grow a route's
-  static shell or fix its slow first paint, diagnose which Suspense boundary
-  keeps a route out of its static shell, or write the instant() e2e guard for
-  one. Requires Next.js 16.3+ with cacheComponents; directs an upgrade if older.
----
-
-# next-cache-components-optimizer
-
-Set up an agentic optimization loop that drives a Next.js route from "not
-instant" to "instant" and keeps it there. The loop is test-driven: encode the
-goal as a failing `@next/playwright` `instant()` test, work it to green, and
-ship the test as the regression guard. Run it once per target route. Work the
-phases P → G in order; each ends in a gate. Fix recipes live in two lazily-read
-references — `reference/patterns.md` (before→after for each blocker type) and
-`reference/real-app-patterns.md` (parallel routes, auth gates, the empty-shell
-and responsive-skeleton failure modes). Read one only when its phase points
-there.
-
-## What is invariant, and what is yours
-
-One thing here is fixed. The rest is yours. Read this before treating any
-command, platform, or env var below as a requirement.
-
-- **Invariant: the verification loop.** Maximizing the shell is worthless
-  unless you can prove it. The proof is an automated check: under a lock that
-  gates dynamic data, the static shell still commits. RED shows the gap, GREEN
-  shows it closed, the test ships as the regression guard. It must run on a
-  production-like build and must not be able to pass vacuously. Stand the loop
-  up once; every later optimization is then verifiable by construction. The
-  loop is the deliverable, not any one route.
-- **The mechanism: `@next/playwright` `instant()`.** This skill locks with
-  [`instant()`](https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config/instant#testing-instant-navigation):
-  a ruler, not a stopwatch (phase A). It comes from
-  `@next/playwright` (installed alongside `@playwright/test`, on the same
-  release line as `next`), so it isn't tied to any host. Keep it. Timing a
-  navigation by hand is too flaky to trust, and is the failure mode this skill
-  exists to prevent.
-- **Yours: the rig.** How you build, deploy, authenticate, configure
-  Playwright, and loop belongs to your stack, not to this skill. A local
-  `next build && next start`, a CI/staging container, and a per-push preview
-  deploy are equally valid rigs; the verdict comes from the build, never the
-  platform. Phase 0 maps the invariant onto your repo. Read every platform
-  name, env-var spelling, and command below as an example to translate, not a
-  requirement.
-
-## Two navigations, two loading states
-
-A route reaches the user two ways, and both must be instant:
-
-- **Initial load (hard navigation)** commits the route's prerendered static
-  shell; deferred parts stream in behind their loading skeletons (Suspense
-  fallbacks, `loading.tsx`).
-- **Client-side navigation (soft navigation)** commits the destination's
-  prefetched App Shell — the `<Link>` default under Partial Prefetching —
-  re-rendering only the segments that change.
-
-The fix patterns are identical for both; the test differs only in how the
-navigation is driven ("Driving the navigation in tests" below). The two shells
-can differ; guard the one you ship, both when both matter
-(`reference/real-app-patterns.md`).
-
-## Goal
-
-Maximizing the static shell is the optimization objective: the most meaningful
-prerendered content commits immediately, and only genuinely per-request data
-streams in afterward. The shipped test deterministically encodes **present ∧
-instant**; **non-blank** is the additional bar the workflow enforces by
-judgment (D1/D2/E), because an `instant()` pass alone is satisfied by a blank
-`fallback={null}` shell (the empty-shell failure mode,
-`reference/real-app-patterns.md`).
-
-`instant()` is a ruler, not a stopwatch: assert that the shell appears under
-the lock; do not time it. A trustworthy verdict requires a production build
-(phase A).
-
-The GREEN under the lock is the deterministic verdict; each gate keeps it
-trustworthy.
-
-## Reporting to the user
-
-This loop is meant to run unattended — ideally across many navigations in one
-pass — so it doesn't stop to ask after each route. What matters is how you word
-and present the results, not how often you interrupt. The mechanics below — the
-rig, RED, GREEN, the gates — are your scaffolding; the user never needs to hear
-those words.
-
-- **Speak their language.** Describe the gap and the result in terms of what the
-  user sees: "navigating to the dashboard waited on the charts query before
-  anything painted; now the layout and skeletons paint instantly and the charts
-  stream in" — not RED/GREEN, the lock, or the phase letters.
-- **Show, don't tell.** When you report a route, drive the browser (or attach
-  before/after screenshots) so the user watches the shell commit immediately and
-  the data stream in, rather than reading a claim. Identical before and after
-  means the fix did nothing — roll it back.
-- **Present a run as a list of results,** one line per navigation — which route,
-  what's now instant, what streams — not a transcript of the loop.
-- **Only surface a question for a genuine fork:** a fix that would change
-  behavior, a security-sensitive read, or a route that's dynamic by design (a
-  runtime-prefetch candidate, not a shell to grow). A clean instant fix is not a
-  fork — keep going. With no one to ask (an unattended run), don't block: take
-  the safe default and note the assumption — for a cache-freshness choice,
-  defer the read behind `<Suspense>` (always fresh, still instant) rather than
-  guess a `cacheLife`.
-
-## The workflow
-
-```
-- [ ] P  PREREQS      Next.js 16.3+ with cacheComponents: true; upgrade first → below
-- [ ] 0  SETUP        once per repo: discover + write instant-nav.rig.md     → rig-template.md
-- [ ] A  RIG          production build with the testing API exposed          → below
-- [ ] B  BASELINE     unlocked: the marker renders for the test user         → test-template.md
-- [ ] C  RED          locked instant(): the shell does not commit            → test-template.md
-- [ ] C-gate          VERIFY-RED: stop until the RED is trustworthy          → reference/red-test-robustness.md
-- [ ] D  FIX          push each Suspense boundary down to the data it guards → reference/patterns.md
-- [ ]      D1 reuse the route's existing loading UI; do not hand-build skeletons
-- [ ]      D2 the shell matches the real render at every breakpoint  → reference/real-app-patterns.md
-- [ ] E  PARITY       the refactor changed only whether the route is instant
-- [ ] F  DIFFERENTIAL revert only the fix → RED; re-apply → GREEN            → reference/red-test-robustness.md
-- [ ] G  REVIEW       PR checklist (below)
-```
-
-Phases B and C build the test; only the locked test from C ships.
-
----
-
-## P. PREREQUISITES: current Next.js with Cache Components
-
-The workflow depends on framework capabilities that ship with current Next.js:
-
-- **Next.js 16.3+ with `cacheComponents: true`** in `next.config.ts`. Without
-  Cache Components there is no static shell to optimize.
-- **`@next/playwright`** on the same release line as the project's `next`; it
-  provides `instant()`. Verify with `npm ls next @next/playwright` (or the
-  project's package manager) and align them if they differ. The matching
-  testing API is in the `next` runtime, gated by the
-  `experimental.exposeTestingApiInProductionBuild` config flag (phase A).
-
-If the project does not meet these, upgrade first (`npx @next/codemod upgrade`
-automates most of it), then enable Cache Components in `next.config.ts`:
-
-```ts
-export default { cacheComponents: true };
-```
-
-Enabling the flag surfaces the blocking routes to resolve first; the
-[`next-cache-components-adoption`](https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-adoption)
-skill drives that adoption. Reach for this optimizer once the app builds under
-Cache Components.
-
-This gate is deliberate: the skill targets current Next.js, and none of the
-verdicts below are meaningful on older versions.
-
-## 0. SETUP: discover this project's rig, once per repo
-
-The principles in this skill are fixed; the infrastructure they run on is
-yours. On first use in a repository, discover how the project builds, deploys,
-authenticates, and tests (inspect the repository first, and ask the user only
-what it cannot answer), then write the answers to a committed
-`instant-nav.rig.md`. Every later run reads that file instead of
-rediscovering. The six questions (BUILD / EXPOSE / RUN / TEST USER / DRIFT /
-LOOP), the file template, and filled examples (local-only, generic CI +
-container, preview deploy) are in **`rig-template.md`**.
-
-If the repo has no Playwright e2e harness yet, standing up a minimal one
-(`@next/playwright`, a config with `baseURL`, one authenticated path) is part
-of this step; the loop does not assume a pre-existing suite.
-
-## A. RIG: a production build with the testing API exposed
-
-Stand up the rig described by `instant-nav.rig.md`. Two invariants hold on
-every platform:
-
-1. **Never measure on `next dev`.** It does not prefetch, and its lock is
-   unreliable for blocking routes, so a dev `instant()` result is not a valid
-   RED or GREEN.
-2. **The measured build must expose the testing API.** Otherwise `instant()`
-   silently no-ops and the test passes vacuously (see
-   `reference/red-test-robustness.md`). The lock-engagement proof is the phase-C
-   RED itself: the unfixed target route is the known-blocking route, and its
-   RED under the lock shows the lock engages on this build (C-gate); the
-   self-validating variant in `test-template.md` is the in-band guarantee. Wire
-   `experimental.exposeTestingApiInProductionBuild` to a condition that is
-   true for every build you measure and never true in production:
-
-   ```ts
-   experimental: {
-     // Use the condition your platform provides, and record it in the rig file:
-     //   local:       an explicit opt-in, as below
-     //   generic CI:  process.env.DEPLOY_ENV === 'staging'
-     //   Vercel:      process.env.VERCEL_ENV === 'preview'
-     exposeTestingApiInProductionBuild:
-       process.env.EXPOSE_TESTING_API === '1',
-   }
-   ```
-
-The rig is any production-like build that exposes the testing API: a local
-`next build && next start`, a CI/staging container, and a preview deploy are
-all equally valid; the verdict comes from the build, not the platform. See
-`rig-template.md` for filled examples.
-
-For any deployed or remote build, poll the rig's LIVENESS probe to confirm the
-artifact contains `HEAD` before trusting a verdict (a stale deploy reads as a
-false RED or GREEN); a local `next build && next start` needs none. The probe
-mechanism is in `rig-template.md` (question 6).
-
-## B. BASELINE (unlocked): development scaffold, do not ship
-
-Drive the real navigation with no `instant()` lock and assert that the
-destination's `SHELL_MARKER` renders **as the test user**: the account the
-e2e suite authenticates as (in CI, the CI account; locally, your e2e login
-fixture), with its flags, plan, role, and data. This establishes that the
-marker is real and reachable: not flag-gated, not redirected away, not a
-guessed selector. The suite runs as the test account, not the author's session;
-that environment drift (the rig DRIFT list) is a common source of
-untrustworthy REDs. Scaffold and run command: **`test-template.md`**.
-**Delete this baseline before the PR.**
-
-## C. RED (locked) + the VERIFY-RED gate
-
-Wrap the same navigation in `instant()`; assert the shell commits under the
-lock. A RED here is the gap. **This is the test that ships**
-(`test-template.md`).
-
-> **C-gate: do not start optimizing until the RED is verified trustworthy.** A
-> RED that is red for the wrong reason sends you optimizing a route that was
-> never broken.
-
-The question that settles it: **does `SHELL_MARKER` render without the lock,
-as the test user?** Answer it by re-running phase B as the test user, not by
-adding assertions to the shipped test. The two-branch resolution (No → marker
-or environment bug; Yes → genuine gap, proceed to D), the full taxonomy of
-untrustworthy REDs, the checklist, and worked cases are in
-**`reference/red-test-robustness.md`**. Read it now.
-
----
-
-## D. FIX: push each boundary down to the data it guards
-
-**The anti-pattern: one coarse boundary.** A single `<Suspense>` high in the
-tree with a page-level fallback has three costs:
-
-- The layout UI stays out of the static shell: only a throwaway copy of it is
-  prerendered.
-- The entire subtree is replaced when the boundary resolves, which discards
-  client state and shifts layout.
-- The hand-built fallback drifts out of sync as the UI changes, because it
-  duplicates structure that also exists in the resolved tree.
-
-**The fix: hoist the static, push the Suspense down.** Render the layout UI
-once, synchronously, in the shell, and wrap each await in a boundary scoped to
-the single read it guards. Only that leaf streams; the stable ancestors are
-reused as-is.
-
-**Rule:** if an element renders in both the fallback and the resolved tree,
-hoist it above the boundary.
-
-### The most common blocker: a top-level `await` in a layout on a fallback route
-
-```
-app/[locale]/(app)/[tenant]/dashboard/...
-       │ generateStaticParams ✅   │ no generateStaticParams → fallback route
-```
-
-When any dynamic segment in the route lacks `generateStaticParams`, the route
-is a fallback route, and **all** params defer to request time, including the
-enumerated ones. A top-level `await` in a layout (`await params`, a
-request-time session read, an auth gate) then blocks the whole subtree out of
-the static shell, even when it reads a statically known param. Minimal shape: a
-dynamic-segment route with one segment lacking `generateStaticParams`, plus a
-top-level `await` in the layout above it.
-
-### The fix: defer the gate, render children
-
-Render `children` unconditionally; move the top-level `await` into a
-`<Suspense fallback={null}>`-wrapped child. Mechanism and before→after:
-`reference/real-app-patterns.md`, "Deferring an auth gate".
-
-**Fix the page below the shell too, not only the layout.** A page-level
-top-level `await` (commonly `await params`) blocks the same way the layout's
-does, so make the page sync and push its dynamic reads into a
-`<Suspense>`-wrapped leaf as well. `fallback={null}` is correct only when a gate renders nothing on
-success; for data, the fallback must be a real loading skeleton (see D1).
-
-Every other blocker shape — `cookies()`/`headers()`, uncached fetch or database
-reads, `searchParams`, metadata, viewport, non-deterministic values (`Date.now()`,
-`Math.random()`, `crypto.randomUUID()`) — surfaces its own insight when you hit
-it: the build prints a `https://nextjs.org/docs/messages/<slug>` link. The
-default build output is often abbreviated and may carry no usable stack trace;
-add `--debug-prerender` for the full failing frame and to report every blocker
-past the first. Scope the build to the route you're on with
-`next build --debug-build-paths "app/<route>/**"` rather than rebuilding the app.
-Open that page and apply its recipe; don't improvise from the inline message.
-
-The before→after recipe for each shape is in `reference/patterns.md`, which maps it to the insight
-that explains it.
-
-A few things those per-error pages don't stress for the instant-navigation goal:
-
-- **A boundary in the root layout isn't enough for client navigations.** It
-  passes a page-load check but leaves sibling client navigations blocking; put
-  the boundary below the lowest layout the source and destination routes share.
-- **Keep the LCP element** (usually the main heading) out of any boundary, so it
-  paints in the shell instead of waiting on a stream.
-- **A green check isn't always instant.** `export const instant = false` opts
-  the segment out of validation while the navigation still blocks, and a
-  `<Suspense>` above the document `<body>` prerenders an empty shell — neither
-  makes the route instant.
-
-### D1: reuse the route's existing loading UI; do not hand-build skeletons
-
-Before writing any skeleton, search the repository for the loading UI that
-already exists for this route, in order:
-
-1. the route's `loading.tsx`;
-2. an exported `*Skeleton` colocated with the component;
-3. the fallback already inside the component's own `<Suspense>`.
-
-The **divergence point** is the lowest layout shared by the source and
-destination routes: a soft navigation re-renders only the segments below it,
-while an initial load re-runs every layout from the root. (Also called the
-shared boundary.) A `loading.tsx` above the divergence point fills only
-the initial-load shell; it sits above the soft-nav re-render scope. A
-`loading.tsx` at the destination segment is itself the in-tree boundary for a
-soft navigation into that segment and serves both. Reuse whichever boundary
-actually covers the navigation you are shipping; below the divergence point,
-`loading.tsx` and colocated skeletons are interchangeable for that purpose.
-
-If a component has no skeleton, extract its loading markup into a colocated
-skeleton beside it. Do not author a fresh skeleton that mirrors the page
-layout: it duplicates structure, drifts as the page changes, and pulls the
-design back toward a single coarse boundary. Reusing the component's own
-skeleton also keeps the prefetched shell consistent with the loaded UI.
-
-Exception: if the deferred component renders `null` for some users (for
-example, a flag-gated control), `fallback={null}` is correct, since a skeleton
-would flash and then collapse.
-
-### D2: the shell must match the real render at every breakpoint
-
-A skeleton frozen to one breakpoint misaligns on the others. Fix it the same
-way: one responsive component renders both the live UI and the shell (D1
-skeleton in its data slots), so the breakpoint switch happens once. Verify by
-re-asserting the shell marker at two widths
-(`await page.setViewportSize({ width: 1280, height: 800 })`, then
-`{ width: 390, height: 844 }`), or by adding a mobile Playwright project, so
-this gate is as machine-checkable as the others. Detail:
-`reference/real-app-patterns.md`.
-
-> **D-gate: phase D is complete when the locked test from phase C passes GREEN
-> under the lock on the production-build rig**, not when the code compiles. That
-> GREEN is the deterministic stop for the fix loop; proceed to E.
-
-**When the read can't be pushed down** (an ID minted per request, an
-all-dynamic page, a per-request auth/scope read the whole subtree needs), there
-is no shell to grow. Don't force one: opt the route into **runtime prefetching**
-so the prefetch runs the dynamic render ahead of the click and the soft nav
-commits the real content. See [Runtime Prefetching](https://nextjs.org/docs/app/guides/runtime-prefetching)
-for the mechanism (`prefetch = 'allow-runtime'` on the route plus a full
-`<Link prefetch={true}>`) and the [dynamic-data-during-prefetching insight](https://nextjs.org/docs/messages/instant-link-prefetch-partial)
-for adoption. The `instant()`-specific gotchas the docs don't cover:
-
-- **The full prefetch is mandatory.** An auto/PPR prefetch bails before the
-  runtime spawn (`subtreeHasSpeculativePrefetch`); only `prefetch={true}` /
-  `kind: 'full'` reaches it. If you set `prefetch = 'allow-runtime'` and it's
-  still RED, the link is doing an auto prefetch.
-- **All leaf slots must agree.** `allow-runtime` on the content segment but
-  nothing on a sibling `@header`/`@sidebar` leaf leaves the route's runtime entry
-  incomplete, so the lock falls back to the shell. Flip every leaf together.
-- **Prefetch the canonical URL.** A link whose href 307-redirects can't be
-  prefetched — the prefetch receives the redirect, not the tree. Point the link
-  and the prefetch at the final URL.
-- **Don't blanket the full prefetch.** It fetches _all_ the target's dynamic
-  data; issuing it on hover for every link is wasteful. Scope `kind: 'full'` to
-  the runtime-prefetch targets only.
-- **Marker must be a committed node, not RSC bytes.** The content is often a
-  client component, so its text isn't in the prefetch response. Assert a
-  `data-testid` that renders when the client subtree commits.
-
-## E. PARITY: the refactor changed only whether the route is instant
-
-The push-down is a mechanical transform, not a redesign. Afterward the route
-must render the same tree, data, ordering, empty and error states, redirects,
-and interactions as before; the only observable difference is that the shell
-now commits instantly. Verify:
-
-- **Same render output.** The moved `await`s compute and return the same
-  values; after the stream, the route shows the same content as the base
-  branch for the test user.
-- **Side effects still fire.** A deferred `redirect()` or `notFound()` still
-  happens, at request time rather than during prerender. Confirm an
-  unauthorized user is still redirected and a missing record still returns 404.
-- **Both viewports reach the real UI** after the stream (D2).
-- **Client state survives.** Because the layout UI is hoisted into the stable
-  shell rather than swapped on resolve, open menus, scroll position, focus,
-  and input state persist across the stream.
-
-If anything other than whether the route is instant changed, reduce the refactor.
-
-## F. DIFFERENTIAL
-
-Revert only the fix → RED; re-apply → GREEN; link both runs
-(`reference/red-test-robustness.md`). On a deployed rig, confirm each run is live
-(LIVENESS, phase A) before trusting its color.
-
-## G. REVIEW (PR checklist)
-
-A green final state means nothing if the RED was never trustworthy. The
-test-trustworthiness items are the robustness checklist
-(`reference/red-test-robustness.md`); confirm them, then require these
-PR-specific items:
-
-- [ ] **Differential shown**: RED without the fix, GREEN with it, runs linked.
-- [ ] **Parity confirmed (E)**: same content, redirects, and state.
-- [ ] **Existing loading UI reused (D1)**: no new page-mirroring skeleton.
-- [ ] **Shell matches the real render at desktop and mobile widths (D2)**.
-
-**Stop condition for the whole workflow:** the locked test from C is GREEN on
-the rig, the differential (F) holds, and every item above is checked. Until all
-three hold, you are not done.
-
-## Driving the navigation in tests
-
-- **Soft navigation** → drive a real `<Link>` click. **Initial load** → use
-  `page.goto()` inside `instant()` with the `baseURL` option. Do not substitute
-  `goto` for a soft-nav verdict; the two shells can differ
-  (`test-template.md`, `reference/real-app-patterns.md`).
-- With parallel routes, only the slots that change re-render on a soft
-  navigation; client-rendered navigation UI does not re-render at all. Do not
-  chase a slot the navigation never touches
-  (`reference/real-app-patterns.md`).
-
-## Files
-
-- `rig-template.md`: phase 0, the six-question rig discovery, the
-  `instant-nav.rig.md` template, and filled examples (local-only, generic CI,
-  preview deploy).
-- `test-template.md`: the shipped `instant()` specs for both navigation
-  types (phase C), and the delete-before-PR baseline scaffold (phase B).
-- `reference/red-test-robustness.md`: the C-gate and phase F. The taxonomy of
-  untrustworthy REDs, the checklist, the differential recipe, the vacuous-pass
-  failure mode, and worked cases.
-- `reference/real-app-patterns.md`: parallel routes, deferring an auth gate,
-  initial-load vs soft-navigation shells, the empty-shell failure mode, the
-  responsive-skeleton mismatch, edge cases.

.github/skills/next-cache-component-optimizer/reference/patterns.md

@@ -1,355 +0,0 @@
-# Refactor patterns — push dynamic down into the shell
-
-Each pattern is **before → after**: keep as much as possible in the prerendered shell, and wrap only genuinely per-request work in a tight `<Suspense>` (or hoist it into `use cache`). Production shapes — parallel-route slots, deferring an auth gate, client slot-routers — are in `real-app-patterns.md`.
-
----
-
-## 1. Awaiting at the top → move the await into a Suspense child
-
-The most common blocking shape. Awaiting request-time data at the top of a page/layout makes **everything below it** dynamic.
-
-```tsx
-// ❌ before — top-level await of a non-static param + uncached data
-export default async function Page(props: PageProps<"/store/[slug]">) {
-  const { slug } = await props.params;
-  const product = await db.products.findBySlug(slug);
-  return (
-    <article>
-      <h1>{product.name}</h1>
-    </article>
-  );
-}
-```
-
-```tsx
-// ✅ after — pass the params promise down; await inside a Suspense-wrapped child
-import { Suspense } from "react";
-
-export default function Page(props: PageProps<"/store/[slug]">) {
-  return (
-    <Suspense fallback={<p>Loading product…</p>}>
-      <Product params={props.params} />
-    </Suspense>
-  );
-}
-
-async function Product({ params }: { params: Promise<{ slug: string }> }) {
-  const { slug } = await params;
-  const product = await db.products.findBySlug(slug);
-  return (
-    <article>
-      <h1>{product.name}</h1>
-    </article>
-  );
-}
-```
-
-Inline variant when you don't want a separate component — unwrap the promise without awaiting at the top:
-
-```tsx
-export default function Page(props: PageProps<"/store/[category]">) {
-  return (
-    <Suspense fallback={<Grid.Skeleton />}>
-      {props.params.then(({ category }) => (
-        <ProductGrid category={category} />
-      ))}
-    </Suspense>
-  );
-}
-```
-
-**Insight:** [runtime data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-runtime).
-
----
-
-## 2. `cookies()` / `headers()` in a layout → start, don't await; pass down
-
-A layout that awaits request data blocks the layout **and every page under it**.
-
-```tsx
-// ❌ before — whole layout (and all children) becomes dynamic
-export default async function Layout({ children }) {
-  const cookieStore = await cookies();
-  const theme = cookieStore.get("theme")?.value;
-  return <body data-theme={theme}>{children}</body>;
-}
-```
-
-```tsx
-// ✅ after — start the read without awaiting, pass the promise to a Suspense child
-import { cookies } from "next/headers";
-import { Suspense } from "react";
-
-export default function Layout({ children }: { children: React.ReactNode }) {
-  const cookieStore = cookies(); // not awaited → does not block the shell
-  return (
-    <body>
-      <nav>
-        <Suspense fallback={<UserMenu.Skeleton />}>
-          <UserMenu cookiePromise={cookieStore} />
-        </Suspense>
-      </nav>
-      {children}
-    </body>
-  );
-}
-
-async function UserMenu({
-  cookiePromise,
-}: {
-  cookiePromise: ReturnType<typeof cookies>;
-}) {
-  const theme = (await cookiePromise).get("theme")?.value;
-  return <div data-theme={theme}>…</div>;
-}
-```
-
-`{children}` and `<nav>` stay in the shell; only `<UserMenu>` streams.
-
-**Insight:** [runtime data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-runtime).
-
----
-
-## 3. Uncached fetch / DB read → choose `use cache` _or_ `<Suspense>`
-
-Decide per data source. Same-for-everyone & rarely-changing → cache it (it joins the shell). Per-request & must-be-fresh → leave it uncached behind a boundary.
-
-```tsx
-// ❌ before — both block the shell
-const product = await db.products.findBySlug(slug); // rarely changes
-const inventory = await db.inventory.findBySlug(slug); // must be fresh
-```
-
-```tsx
-// ✅ after — cache the stable one (shell), defer the fresh one (streams)
-async function getProduct(slug: string) {
-  "use cache"; // → resolved at prerender, lands in the shell
-  return db.products.findBySlug(slug);
-}
-
-<Suspense fallback={<p>Checking availability…</p>}>
-  <Inventory params={params} /> {/* uncached read stays here, streams in */}
-</Suspense>;
-```
-
-> A bare `'use cache'` applies the `default` `cacheLife` profile. Choose freshness explicitly with `cacheLife('<profile>')` (`default` / `seconds` / `minutes` / `hours` / `days` / `weeks` / `max`) rather than shipping the default lifetime by omission.
->
-> Serverless note: `use cache` is in-memory and does not persist across instances — use [`use cache: remote`](https://nextjs.org/docs/app/api-reference/directives/use-cache-remote) for a durable shell.
-
-**Insight:** [uncached data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-dynamic).
-
----
-
-## 4. Dynamic params → `generateStaticParams` (shell) or `<Suspense>` (stream)
-
-If the set of params is enumerable, prerender them so `await params` resolves into the shell. Otherwise treat params as request-time and wrap consumers in `<Suspense>`.
-
-```tsx
-// ✅ option A — enumerate → params resolve into the shell, no Suspense needed for params
-export function generateStaticParams() {
-  return [{ slug: "shoes" }, { slug: "hats" }];
-}
-export default async function Page({ params }: PageProps<"/store/[slug]">) {
-  const { slug } = await params; // known at build → shell-safe
-  // ...
-}
-```
-
-```tsx
-// ✅ option B — not enumerable → params is request-time; await it inside a boundary (pattern #1)
-```
-
-Root params (the dynamic segments the root layout sits inside, e.g. `app/[lang]/layout.tsx`) are readable from any Server Component via `next/root-params` without prop-drilling — but under Cache Components they must still be enumerated by `generateStaticParams` (at least one value per root param) to land in the shell, the same as any other dynamic param.
-
-**Insight:** [runtime data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-runtime).
-
----
-
-## 5. `searchParams` → always behind `<Suspense>` (on page load)
-
-Search params are never known at build, so awaiting them (or `useSearchParams()`) suspends on a page load. Keep the rest of the page in the shell by isolating the consumer.
-
-```tsx
-// ✅ static content stays in the shell; the search-dependent part streams
-export default function Page(props: PageProps<"/search">) {
-  return (
-    <>
-      <h1>Search</h1> {/* shell */}
-      <Suspense fallback={<Results.Skeleton />}>
-        <Results searchParams={props.searchParams} />
-      </Suspense>
-    </>
-  );
-}
-async function Results({
-  searchParams,
-}: {
-  searchParams: Promise<{ q?: string }>;
-}) {
-  const { q } = await searchParams;
-  return <ResultList query={q} />;
-}
-```
-
-On a **client navigation** the router already has the URL, so a `useSearchParams()` consumer resolves synchronously and can appear in the prefetched shell — but you still need the boundary for the page-load path.
-
-**Insight:** [runtime data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-runtime) (or, via `useSearchParams` in a Client Component, [URL data in a Client Component](https://nextjs.org/docs/messages/blocking-prerender-client-hook)).
-
----
-
-## 6. Non-deterministic values → `connection()` + `<Suspense>`, or cache
-
-`Math.random()`, `Date.now()`, `crypto.randomUUID()` produce different output each run, so Cache Components makes you choose: per-request (defer) or fixed (cache).
-
-```tsx
-// ✅ per-request value: gate on connection() and wrap in Suspense
-import { connection } from "next/server";
-
-async function RequestId() {
-  await connection();
-  return <span>{crypto.randomUUID()}</span>;
-}
-// <Suspense fallback={null}><RequestId /></Suspense>
-```
-
-```tsx
-// ✅ same value for everyone: cache it so it joins the shell
-async function buildId() {
-  "use cache";
-  return Date.now();
-}
-```
-
-**Insight:** [`Date.now()`](https://nextjs.org/docs/messages/blocking-prerender-current-time), [`Math.random()`](https://nextjs.org/docs/messages/blocking-prerender-random), or [`crypto`](https://nextjs.org/docs/messages/blocking-prerender-crypto) while prerendering.
-
----
-
-## 7. Dynamic `generateMetadata` → static export, `use cache`, or a dynamic-marker for runtime data
-
-```tsx
-// ❌ before — reading request data blocks the route's metadata
-export async function generateMetadata() {
-  const c = await cookies();
-  return { title: c.get("title")?.value };
-}
-```
-
-```tsx
-// ✅ option A — static
-export const metadata = { title: "Store" };
-
-// ✅ option B — cache the metadata (depends on external data, not runtime data)
-export async function generateMetadata() {
-  "use cache";
-  return { title: await getTitle() };
-}
-```
-
-```tsx
-// ✅ option C — metadata genuinely needs runtime data (cookies/headers):
-// keep generateMetadata dynamic, and add a dynamic-marker component to the
-// page so the rest of the page still prerenders into the shell.
-import { cookies } from "next/headers";
-import { connection } from "next/server";
-import { Suspense } from "react";
-
-export async function generateMetadata() {
-  const token = (await cookies()).get("token")?.value;
-  return { title: token ? "Personalized" : "Store" };
-}
-
-async function DynamicMarker() {
-  await connection(); // signals intentional dynamic content
-  return null;
-}
-
-export default function Page() {
-  return (
-    <>
-      <article>{/* static content — stays in the shell */}</article>
-      <Suspense>
-        <DynamicMarker />
-      </Suspense>
-    </>
-  );
-}
-```
-
-`generateViewport` is the same, except dynamic viewport blocks the **whole page**. Genuine instant fixes: a static `viewport` export, or `use cache`. The other two are dynamic-acceptance opt-outs, not instant fixes — do not treat them as a way to reach GREEN: `export const instant = false` opts the segment out of validation while the navigation still blocks, and a `<Suspense>` above the document `<body>` makes the whole route dynamic.
-
-**Insight:** [runtime data in `generateMetadata()`](https://nextjs.org/docs/messages/blocking-prerender-metadata-runtime).
-
----
-
-## 8. Keep the LCP element in the shell
-
-Don't bury the main heading (the LCP element) inside a boundary — it can't paint until the boundary resolves.
-
-```tsx
-// ✅ LCP outside the boundary → paints in the shell
-<h1>{product.name}</h1>                 {/* shell (cache the name if needed) */}
-<Suspense fallback={<Reviews.Skeleton />}>
-  <Reviews productId={id} />            {/* streams */}
-</Suspense>
-```
-
----
-
-## 9. Granularity below shared layouts (client-nav correctness)
-
-A single boundary in the **root** layout passes a page-load check but leaves sibling client navigations blocking. Put a boundary **below the shared layout**.
-
-```tsx
-// app/store/layout.tsx — boundary below the /store shared layout covers
-//   client navs like /store/shoes → /store/hats (the root boundary does not)
-export default function StoreLayout({
-  children,
-}: {
-  children: React.ReactNode;
-}) {
-  return (
-    <section>
-      <StoreNav /> {/* shell */}
-      <Suspense fallback={<Page.Skeleton />}>{children}</Suspense>
-    </section>
-  );
-}
-```
-
-Prefer per-component boundaries inside the page (patterns #1–#5) over one big layout boundary — they keep more real content in the shell and stream independently.
-
-**Insight:** the read's own insight surfaces on the client navigation when the boundary is too high — see [where to place the boundary](https://nextjs.org/docs/messages/blocking-prerender-dynamic#choosing-where-to-place-the-boundary).
-
-## 10. Can't push the read down? Runtime-prefetch the whole route
-
-Patterns 1–9 grow a **static shell** by moving dynamic reads behind boundaries. Some routes resist that: an ID minted per request (`createId()`), an auth/scope resolution the whole subtree needs, a page that is _all_ dynamic by nature. The read can't move, so there is no meaningful shell to commit and the soft nav stays RED. The escape hatch is **runtime prefetching** — don't prerender a shell, run the dynamic render _in the prefetch_ so the whole route is warm before the click and the soft nav commits the real content instantly.
-
-It has **two halves — both required**, and route config alone is RED:
-
-```tsx
-// 1. The route opts in — on EVERY leaf (page/default) segment, parallel @slots
-//    included, or instant validation re-triggers on the segments that lack it
-//    (the same all-or-nothing coupling as an `instant = false` opt-out).
-export const prefetch = 'allow-runtime'
-
-// 2. The <Link> asks for a FULL prefetch — that is what spawns the runtime
-//    request. A default/auto prefetch only warms the static shell.
-<Link href={href} prefetch={true}>…</Link>
-//    <Link prefetch> already issues the full prefetch on hover and on viewport
-//    entry, so prefer it. An imperative full prefetch via router.prefetch needs
-//    the non-exported PrefetchKind enum, so it has no clean public form.
-```
-
-Under `instant()` the runtime entry is what commits, so the real content (not a skeleton) shows under the lock — that is the GREEN.
-
-Gotchas (each cost real debugging time):
-
-- **The full prefetch is mandatory.** With App Shells enabled an auto/PPR prefetch bails before the runtime spawn (`subtreeHasSpeculativePrefetch`); only `prefetch={true}` / `kind: 'full'` reaches it. If you set `prefetch = 'allow-runtime'` and it's still RED, the link is doing an auto prefetch.
-- **All leaf slots must agree.** `allow-runtime` on the content segment but `instant = false` (or nothing) on a sibling `@header`/`@sidebar` leaf leaves the route's runtime entry incomplete, so the lock falls back to the shell. Flip every leaf together.
-- **Prefetch the canonical URL.** A link whose href 307-redirects (a `/foo` that canonicalizes to `/`) can't be prefetched — the prefetch receives the redirect, not the tree. Point the link and the prefetch at the final URL.
-- **Don't blanket the full prefetch.** It fetches _all_ the target's dynamic data; issuing it on hover for every link (recents that point at whole chats) is wasteful. Scope `kind: 'full'` to the runtime-prefetch targets only.
-- **Marker must be a committed node, not RSC bytes.** The content is often a client component, so its text isn't in the prefetch response — assert a `data-testid` that renders when the client subtree commits, not a substring of the stream.
-
-Prefer a static shell (patterns 1–9) whenever the read can move: it's cheaper than a runtime prefetch and also covers hard load. Reach for runtime prefetching when the read genuinely can't move, or for a route that's all-dynamic by design.
-
-**Insight:** [dynamic data during prefetching](https://nextjs.org/docs/messages/instant-link-prefetch-partial).

.github/skills/next-cache-component-optimizer/reference/real-app-patterns.md

@@ -1,88 +0,0 @@
-# Real-app patterns
-
-The rest of this skill models a single linear `layout → page` tree. Production App Router routes add **parallel routes, shared layout UI, and auth gates**, which is where most of the real static-shell work happens. These patterns bridge that gap. Read the skill's `SKILL.md` first.
-
-## Parallel routes: each slot is its own boundary
-
-Instant validation treats every parallel-route slot below the shared layout as an **independent** navigation boundary. Consequences:
-
-- **Each `@slot` needs its own `<Suspense>`** around its dynamic reads; a boundary in one slot does not cover another.
-- **An uncovered dynamic read in any slot blocks the whole navigation.** A perfect `@content` does not help if `@sidebar` awaits a session at the top.
-- **A slot that renders `null` (e.g. `default.tsx`) is shell-safe**: it is static and performs no reads. Slots that do not re-render for this navigation cost nothing.
-
-```
-[tenant]/layout.tsx         (shared: already mounted on a soft navigation; not re-rendered)
-  ├ @content  → settings/layout → billing/page     ← guard each slot's dynamic reads…
-  ├ @sidebar  → side nav                            ← …here too (independent boundary)
-  └ @header   → default.tsx → null                  ← free
-```
-
-## Client-rendered slot routing is not part of the soft-navigation re-render
-
-A common pattern: a stable shared layout renders `@header`/`@sidebar` through a **client** component that swaps slot content based on `usePathname()`. On a soft navigation, Next.js only re-renders the **server** segments that changed below the shared layout; a client-component subtree is not part of that re-render. So that navigation UI neither blocks the navigation nor needs a server `<Suspense>` for it; only the server segments that actually change (e.g. `@content`) matter. It does participate in an initial load (see the caveat below).
-
-## "Instant" is not "useful shell": the empty-shell failure mode
-
-Validation checks that a dynamic read is **guarded by a boundary**, not that the fallback is non-empty. A `<Suspense>` with no `fallback` (or `fallback={null}`) passes validation and commits instantly, but renders a **blank** shell. If a layout and its page both `await getSession()` (your auth library's request-time read) at the top under one empty-fallback boundary, the whole frame collapses to nothing while the user waits. "Validates as instant" and "good loading experience" are different goals.
-
-> Give every boundary a real loading skeleton, and place it low so the most real content stays in the shell. A `fallback={null}` directly above `<body>` is a deliberate empty-shell opt-out; an empty fallback lower in the tree is almost always a bug.
-
-## The responsive-skeleton mismatch: the shell must match every breakpoint
-
-A loading skeleton that misaligns with the loaded UI is its own bug, and it usually appears on mobile. A hand-built skeleton encodes one layout; the real component is responsive and changes shape at breakpoints, so a desktop-shaped skeleton no longer lines up once the viewport is small.
-
-A concrete shape: a list-detail view renders a list or tree in a side panel on desktop, but collapses that panel into a single dropdown or drawer on mobile (with its own loading state). A row skeleton built for the desktop panel has nothing to align with on mobile.
-
-The fix is the same push-down as everywhere else: **share the real responsive layout between the live render and the shell render.** One responsive component renders both (its data slots show the reused `*Skeleton` in the shell and real data after the stream), so the breakpoint switch happens once, for both renders, and there is no second desktop-only skeleton to drift.
-
-(Same hoist rule, responsive layout included.) Verify the shell at both desktop and mobile widths against the real render at the same width.
-
-## Deferring an auth gate / top-level `await` in a layout
-
-A top-level `await` in a layout blocks everything below it (the most common blocker; see [Runtime data during prerendering](https://nextjs.org/docs/messages/blocking-prerender-runtime)). Auth gates are the most common real instance:
-
-```tsx
-// ❌ Before: the await + redirect at the top blocks the whole settings frame
-export default async function SettingsLayout({ children }) {
-  const session = await getSession(); // your auth library's request-time read; suspends during prerender → frame can't build
-  if (!session?.user) redirect(getLoginUrl());
-  return <Shell>{children}</Shell>;
-}
-```
-
-```tsx
-// ✅ After: render children unconditionally; move the gate into a Suspense child
-import { Suspense } from "react";
-
-export default function SettingsLayout({ children }) {
-  return (
-    <Shell>
-      <Suspense fallback={null}>
-        <AuthGate />
-      </Suspense>
-      {children}
-    </Shell>
-  );
-}
-
-async function AuthGate() {
-  const session = await getSession(); // the session read suspends during prerender…
-  if (!session?.user) redirect(getLoginUrl()); // …so redirect() never runs at build time
-  return null;
-}
-```
-
-The shell prerenders as if authorized (the session read suspends before `redirect()` is reached, so the redirect only happens at request time), and `{children}` is now in the shell instead of behind the gate. (`fallback={null}` is correct here: `AuthGate` renders nothing on success.)
-
-## Initial-load shell vs soft-navigation shell
-
-The `test-template.md` specs drive a `<Link>` click for soft navigations and `page.goto()` for initial loads. The two shells can differ for the same route:
-
-> **The initial-load shell can show less than the soft-navigation shell when a layout above the shared boundary awaits un-enumerated `params`/`searchParams`.** An initial load re-runs every layout from the root; if a parent layout does `await props.params` and that segment has no `generateStaticParams`, the param suspends on the initial load and its whole subtree drops out of the shell. A soft navigation does not re-render that parent and already has the params. Symptom: an element present after a `<Link>` click is missing after `goto`.
-
-To assert the soft-navigation shell, drive a real `<Link>` click (through menus if necessary). Use `page.goto()` inside `instant()` to assert the initial-load shell, or when no parent above the shared boundary awaits un-enumerated params, in which case the two coincide.
-
-## Edge cases
-
-- **A `React.cache` (or custom memoization) wrapper around `cookies()`/`headers()` still suspends.** Memoizing the call does not make it shell-safe: the underlying request read still returns a pending promise during prerender. Only the **`use cache`** directive, keyed on static or param inputs, puts data in the shell.
-- **Playwright cannot see a `display: contents` or fragment fallback.** Such a fallback reads as hidden, so `instant()` assertions cannot `toBeVisible()` it. Give fallbacks a real wrapper element with a `data-testid`.

.github/skills/next-cache-component-optimizer/reference/red-test-robustness.md

@@ -1,139 +0,0 @@
-# RED-test robustness: verify the RED before optimizing
-
-The C-gate of the workflow. A RED that is red for the wrong reason sends you optimizing a route that
-was never broken: the route becomes instant, the test stays red (or the code is contorted to
-satisfy a broken assertion), and the effort lands on the wrong problem. The prevention is cheap:
-spend a few minutes verifying the RED is trustworthy first.
-
-## The deciding question
-
-> **Does the marker render WITHOUT the lock, as the test user?**
-
-- **No**: the test is red because the marker or page is not there for that user or environment. A
-  marker bug, not an instant-navigation bug. Fix the marker. (This is the most common case.)
-- **Yes**: the marker exists and is reachable; a red under the lock is a genuine "not instant".
-  Optimize the route.
-
-Everything below serves answering that question honestly.
-
-## The robustness checklist (all must hold)
-
-1. **Red on baseline**: fails on the unfixed route.
-2. **Right reason**: without the lock, the marker is visible on the production-build rig (never
-   `next dev`), running as the test user, not only in the author's own logged-in session.
-3. **Differential**: reverting only the fix → RED; re-applying → GREEN; nothing else moves it.
-4. **Non-gameable marker**: a sync element of the static shell, never streamed data.
-5. **Deterministic on a production build**: stable across N runs; never `next dev`.
-6. **Discriminating both ways**: present under the lock on an instant route, absent under the
-   lock on a blocking one.
-7. **Renders for the test user**: under that user's flags, plan, role, and data.
-8. **Conditional redirects accounted for**: assert at the route's real destination for that user.
-9. **Real selector**: a `data-testid` on a known static-shell node, not a guessed `role`/`name`.
-10. **Visible marker**: not `display:none`, off-screen, or inside a hover overlay; for lists,
-    target `.filter({ visible: true }).first()`.
-11. **Fresh build under test**: the deployment being measured contains the latest commit, not a
-    build URL still serving the previous deploy.
-
-## Taxonomy: red for the wrong reason
-
-Any of these makes a RED untrustworthy. None of them is "the navigation isn't instant."
-
-| Wrong reason                 | How it occurs                                                                              | How to rule it out                                                                                |
-| ---------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
-| **Selector matches nothing** | a guessed `getByRole('button', { name: 'Folder' })`                                        | grep the component for the real accessible name; add a `data-testid`                              |
-| **Conditional redirect**     | the route `redirect()`s for the test user (flag/role), so the marker page is never reached | check the page's top-level branches; assert at the real destination, or pin the flag              |
-| **Flag / plan / role gate**  | the author has the flag or plan; the test user does not                                    | run the unlocked baseline as the test user; pin flags via the project's override mechanism        |
-| **Empty state**              | the marker only exists when data does; the CI account is empty                             | pick a marker present in the empty state (a layout element such as the page header), or seed data |
-| **Timeout / flake**          | a slow API or transient infrastructure error                                               | re-run; separate infrastructure flake from a real signal                                          |
-| **Streamed marker**          | the marker is behind `<Suspense>`, so it is never in the shell                             | choose a sync shell element; verify it sits outside every `<Suspense>`                            |
-| **Auth redirect**            | unauthenticated → `/login`                                                                 | confirm login succeeded before the navigation                                                     |
-| **Stale deployment**         | the test ran against the previous build (the URL under test still serves the prior deploy) | poll the deployment for a marker from the latest commit before trusting any verdict               |
-| **Hidden / off-screen**      | the testid is on a hover-overlay or off-screen list item                                   | put the marker on an always-visible node; `.filter({ visible: true }).first()` for lists          |
-
-## Worked cases
-
-These are illustrative failures from real optimization runs; each was red for a wrong reason, and
-none was an instant-navigation problem. One app's drift surface might be dominated by feature flags and
-plans; another's by auth state, an empty database, or locale. The taxonomy lists every wrong
-reason; the rig file's DRIFT list says which rows apply to your app.
-
-- **Guessed selector + empty state**: the marker was a button picked by a guessed accessible name
-  that no element actually had, on a list page whose CI account had no rows. → checks 7, 9. Fix: a
-  `data-testid` on a real static-shell node.
-- **Hidden marker**: the testid sat first on a `hidden sm:block` hover-overlay link, then on an
-  off-screen carousel card; Playwright resolved the element but reported it hidden. → check 10.
-  Fix: an always-visible node; for lists, `.filter({ visible: true }).first()`.
-
-## Differential check (capture in the PR)
-
-The strongest evidence that the RED measured the property:
-
-```
-1. on the fixed branch → GREEN
-2. revert ONLY the fix (the <Suspense> push-down) → RED
-3. re-apply → GREEN
-4. confirm no other change moves it
-```
-
-Link the two runs (or include the toggle diff and results) in the PR description. A reviewer who
-sees the differential knows the test measures the property.
-
-## `instant()` is not a stopwatch
-
-The test does not measure how fast a navigation is. `instant()` gates dynamic data so the content
-of the static shell can be asserted; the signal is presence, not speed. Under the lock, an instant
-route's shell is present, and a blocking route's content never commits, regardless of wait time.
-Therefore:
-
-- The shipped assertion is `await expect(SHELL_MARKER).toBeVisible()` under the lock. Do not add a
-  custom timeout or a `painted` boolean.
-- A custom short timeout (e.g. `3000`) implies a race against a clock that does not exist. It adds
-  nothing to the verdict and invites false REDs on an instant route whose commit lands a microtask
-  late.
-- Do not use `locator.isVisible({ timeout })` as a soft wait: Playwright deprecated and ignores
-  that timeout; the call returns immediately.
-- "Renders for the test user" (checks 7-9) is established at authoring time with the unlocked
-  baseline scaffold, not by a timed assertion in the shipped test.
-
-## `instant()` guards need no retries and no prefetch warming
-
-An `instant()` guard is deterministic. Do not configure retries on one, and do not hover-warm to
-help a prefetch land in time. Under the lock, the router initiates the route prefetch and awaits it
-before committing (even for a `prefetch={false}` link, even for a route already in the prefetch
-cache), so the committed shell does not depend on any prior render, hover, or menu-open prefetch.
-A flaky guard has a real cause: a marker that is not a sync node of the destination's shell, a
-flag/role/empty-state gap for the test user, or a genuinely blocking route. The fix is in the page or
-the marker; a retry masks the regression the guard exists to catch. The only legitimate
-`.hover()`/menu-open is when the trigger element itself is not in the DOM until hovered or opened.
-
-## Silent no-op: the testing API must be exposed in the measured build
-
-`instant()` works by setting a cookie (`next-instant-navigation-testing`) that lock code inside the
-build reads. It does not throw when that lock code is absent; it only throws on nested calls or an
-unknown base URL. If the build was produced without the testing API
-(`experimental.exposeTestingApiInProductionBuild`), the cookie is ignored, the navigation runs
-normally, and the `instant()` test passes vacuously. A green `instant()` test is only meaningful if
-the lock engaged.
-
-Two defenses; use both:
-
-1. **Confirm the API is exposed on the target.** Wire the flag to the platform's preview/staging
-   condition or an explicit environment variable; the rig file records the project's spelling
-   (SKILL.md phases 0 and A). Do not trust a pass from a build where it is not set.
-2. **Make the test self-validating**: for any route with deferred content, also assert that the
-   deferred content is gated under the lock, not only that the shell is present
-   (`test-template.md`, self-validating variant). If the lock did not engage, the content is
-   already present and `toHaveCount(0)` fails.
-
-   The gated half holds under the lock for both navigation types regardless of warm state: the
-   soft-nav client lock gates dynamic-data writes, and on an initial load the server honors the
-   cookie on the document request and suspends dynamic data. A vacuous pass is only possible with
-   a build produced WITHOUT the testing API, which defense #1 above covers.
-
-## Determinism and the rig
-
-- Always measure on a production build, never `next dev`; SKILL.md phase A owns this invariant and
-  its rationale.
-- Run the RED several times; an intermittently red gate is not a gate. If it flakes, determine
-  whether the cause is infrastructure (transient errors) or a real race before trusting either
-  color.

.github/skills/next-cache-component-optimizer/rig-template.md

@@ -1,103 +0,0 @@
-# Rig discovery: generate this project's `instant-nav.rig.md`
-
-The skill's principles are environment-independent. Your build, deploy, auth,
-and test infrastructure are not. This phase converts the principles into THIS
-project's concrete workflow: run discovery once per repo, write the answers to
-a committed `instant-nav.rig.md` (repo root, or next to your e2e config), and
-every later run reads that file instead of rediscovering.
-
-The skill is deliberately opinionated about **what** the rig must provide, and
-deliberately unopinionated about **how** your stack provides it.
-
-## How to discover
-
-Inspect before asking. Most answers are already in the repo:
-
-- `package.json` scripts (`build`, `start`, `test:e2e`)
-- the e2e config (`playwright.config.*`: `baseURL`, `webServer`, projects)
-- CI config (`.github/workflows/`, `vercel.json`, GitLab/Circle files,
-  Dockerfiles)
-- `next.config.*` (existing `experimental` flags)
-- existing e2e auth helpers (grep for `login`, `storageState`, `session`)
-
-Ask the user only what the repo can't answer. Typically that means: which
-deploy target counts as "preview", which account the suite runs as in CI, and
-whether an agent is allowed to push and wait on CI unattended.
-
-## The six questions (all must have answers), plus two derived fields
-
-The six questions below must all have answers. The rig file template adds two
-more fields the discovery feeds rather than asks directly: **LIVENESS** (the
-SHA-echoing probe, derived from the LOOP answer) and **WALLS** (project-specific
-build/run obstacles, accumulated as you first hit them).
-
-1. **BUILD**: how is a production build of this app produced and served?
-   A per-push preview deploy, a staging container, or bare
-   `next build && next start`. Anything but `next dev`.
-2. **EXPOSE**: what condition turns on
-   `experimental.exposeTestingApiInProductionBuild` for every measured build,
-   and never for real production? Spellings: an explicit
-   `EXPOSE_TESTING_API=1` for local production builds; `process.env.DEPLOY_ENV
-=== 'staging'` for a generic CI/staging env var; `process.env.VERCEL_ENV ===
-'preview'` on Vercel.
-3. **RUN**: how is the Playwright suite invoked, and against which
-   `BASE_URL`?
-4. **TEST USER**: which account does the suite run as, and how does login
-   happen (helper, `storageState`, API token)? What flags / plan / role / data
-   does that account have?
-5. **DRIFT**: enumerate everything that can differ between the author's own
-   session and the test user's environment (feature flags, plans and
-   entitlements, roles, seeded vs empty data, locale, A/B buckets). Every item
-   is a way a RED can become untrustworthy; this list feeds the C-gate
-   (`reference/red-test-robustness.md`).
-6. **LOOP**: the unattended iteration for your rig. Push → build → e2e
-   against the artifact → read the failure → fix → push (CI), or build → start
-   → e2e (local). Note anything an agent cannot do alone (deploy approvals,
-   secrets, protected branches). Include the **liveness probe**: the endpoint
-   or response header that echoes the deployed commit SHA (e.g. a `/healthz`
-   route or an `x-deployed-sha` header), so a CI run can confirm the build
-   under test matches `HEAD` before trusting a verdict (SKILL.md phase A). If
-   the platform exposes no SHA-echoing endpoint or header, add one: surface a
-   build-time commit var (`VERCEL_GIT_COMMIT_SHA`, a CI commit variable) on a
-   `/healthz` route or a response header, or fall back to polling the deploy
-   platform's API for the deployment whose `commitSha === HEAD`. Record the
-   chosen mechanism. For a local `build && start` rig the artifact is the one
-   freshly built, so no probe is needed.
-
-## The file: copy, fill, commit as `instant-nav.rig.md`
-
-```md
-# instant-nav rig: <project>
-
-- BUILD: <command / platform that produces the measured production build>
-- EXPOSE: <the condition wired to exposeTestingApiInProductionBuild>
-- RUN: <e2e command> against <how BASE_URL is obtained>
-- TEST USER: <account> via <login mechanism>; flags/plan/role/data: <...>
-- DRIFT: <the enumerated drift surface>
-- LOOP: <push → CI → e2e, or local build → start → test>; agent limits: <...>
-- LIVENESS: <endpoint/header echoing the deployed SHA; n/a for local build && start>
-- WALLS: <project-specific build/run obstacles + their workarounds>
-```
-
-Real apps rarely build for production cleanly on the first attempt: missing
-secrets, server-only imports that fail prerender, ports held by respawning
-servers. Record each wall and its workaround the first time you hit it. `WALLS`
-accumulates the project-specific build/run obstacles that the other fields
-cannot capture.
-
-## Filled examples
-
-**No CI / local-only.** BUILD: `EXPOSE_TESTING_API=1 next build && next
-start`. EXPOSE: that env var. RUN: `BASE_URL=http://localhost:3000 playwright
-test`. LOOP: build → start → test on one machine; fully agent-drivable, with
-nothing to push, no secrets, and no deploy wait.
-
-**Generic CI + container.** BUILD: the pipeline builds an image and deploys it
-to a staging namespace. EXPOSE: `process.env.DEPLOY_ENV === 'staging'`. RUN: a
-CI job runs Playwright against the staging URL. LOOP: push → pipeline → e2e;
-fully agent-drivable once the pipeline is wired.
-
-**Vercel preview deploys.** BUILD: every push builds a preview. EXPOSE:
-`process.env.VERCEL_ENV === 'preview'`. RUN: `playwright test` with
-`BASE_URL=<preview URL>`. LOOP: push → preview → e2e; fully agent-drivable
-once the preview deploy and `VERCEL_ENV` gating are in place.

.github/skills/next-cache-component-optimizer/test-template.md

@@ -1,165 +0,0 @@
-# Test template: the instant() guard
-
-Ship one test per navigation type you are guarding: under `instant()`, assert that the
-destination's static shell appears. `instant()` gates dynamic data, so a correctly instant route
-commits its shell under the lock and a blocking route does not. `instant()` is a ruler, not a
-stopwatch: do not add custom timeouts or timing races (see `reference/red-test-robustness.md`).
-Whether the marker is the right one (rendering for the test user, not flag-gated, not redirected
-away, not guessed) is established at authoring time with the unlocked baseline scaffold below
-(phase B, the C-gate), not by additional assertions in the shipped test.
-
-All identifiers in angle brackets (`<b>`, `<Trigger>`) and the `../helpers` import are placeholders;
-substitute your project's e2e auth helper, URL helper, and real testids/trigger before running.
-
-## Soft navigation (client-side navigation)
-
-Drive a real `<Link>` click. The committed shell is the destination's prefetched App Shell.
-Under the lock the router initiates and awaits the route prefetch itself, so no manual warming is
-needed; if the shell is intermittently absent, treat it as a real blocker or marker bug (C-gate),
-never as a warming race. Do not add waits or hovers.
-
-```ts
-import { instant } from "@next/playwright";
-import { expect, test } from "@playwright/test";
-// Use the auth/setup helpers your e2e suite already has. Run as the test user
-// (defined in SKILL.md phase B).
-import { logIntoTestAccount, testUrl } from "../helpers";
-
-// A SYNC element of the destination's static shell (header, action button,
-// column header), not data that streams in, and one that renders for the
-// test user (not gated by a flag, plan, role, or empty state). Prefer a
-// data-testid on a known static node over a guessed role/name.
-const SHELL_MARKER = '[data-testid="<b>-shell-marker"]';
-
-test.describe("instant nav: A -> B", () => {
-  test.beforeEach(async ({ page, browser }) => {
-    await logIntoTestAccount(page, browser);
-  });
-
-  test("B shell commits under instant()", async ({ page }) => {
-    await page.goto(testUrl("/"));
-    const trigger = page.getByRole("link", { name: "<Trigger>", exact: true });
-    await expect(trigger).toBeVisible({ timeout: 20000 });
-
-    await instant(page, async () => {
-      await trigger.click();
-      // static shell asserted under the lock; no timeout
-      await expect(page.locator(SHELL_MARKER)).toBeVisible();
-    });
-  });
-});
-```
-
-The trigger selector follows the same rule as `SHELL_MARKER`: prefer a `data-testid` on the real
-`<Link>` (`page.getByTestId('<trigger>-link')`) over a guessed accessible name. `getByRole({ name })`
-is shown only for brevity; like the marker, the trigger must reliably resolve for the test user.
-
-## Initial load (hard navigation)
-
-Drive `page.goto()` inside `instant()` with the `baseURL` option. The served document is the
-route's prerendered static shell. `baseURL` is required because `page` is still `about:blank` when
-`instant()` runs (`resolveURL` falls back to `page.url()` only when no `baseURL` is passed).
-Establish the session WITHOUT navigating `page` (inject `storageState`, or log in on a separate
-context/page). A login helper that navigates `page` itself defeats the measurement for a different
-reason: that navigation completes before `instant()` acquires the lock, so it runs unmeasured. The
-session must be pre-established either way; otherwise an authenticated route redirects to login
-and the RED is false.
-
-If the project's only login helper navigates `page`, the agent must use a
-storageState/separate-context path here instead, a session-injection call that
-does NOT call `page.goto`:
-
-```ts
-test.describe("instant initial load: B", () => {
-  test.beforeEach(async ({ page }) => {
-    await injectTestUserSession(page); // storageState only; must NOT call page.goto
-  });
-
-  test("B shell is served", async ({ page }) => {
-    const url = testUrl("/<b>");
-    await instant(
-      page,
-      async () => {
-        await page.goto(url);
-        await expect(page.locator(SHELL_MARKER)).toBeVisible();
-      },
-      { baseURL: new URL(url).origin },
-    );
-  });
-});
-```
-
-## Self-validating variant (recommended for routes with deferred content)
-
-Also assert that the deferred content is gated under the lock and streams after release. This
-makes a vacuous pass impossible: if the lock did not engage (testing API missing from the build),
-the content is already present and `toHaveCount(0)` fails (see `reference/red-test-robustness.md`).
-
-`SHELL_MARKER` is the shell node; `[data-testid="<b>-content"]` is the deferred data it guards.
-
-```ts
-// soft navigation
-await instant(page, async () => {
-  await trigger.click();
-  await expect(page.locator(SHELL_MARKER)).toBeVisible(); // shell present
-  await expect(page.getByTestId("<b>-content")).toHaveCount(0); // deferred data gated
-});
-await expect(page.getByTestId("<b>-content")).toBeVisible(); // streams after release
-```
-
-The two **gated-half** assertions (shell visible, deferred content `toHaveCount(0)`) apply to the
-initial-load `page.goto()` form too. The cookie gates the deferred content identically for both:
-on a soft navigation the client lock gates dynamic-data writes; on an initial load the server
-honors the cookie on the document request (set via `addCookies()` before navigation, scoped by
-`baseURL`) and suspends dynamic data, independent of whether the route was previously rendered or
-cached. So the initial-load `toHaveCount(0)` gated half is as valid as the soft-nav one; it needs
-no fresh browser context and no cache-busting query param.
-
-The **post-release** assertion (`getByTestId('<b>-content').toBeVisible()` after the `instant()`
-block) is soft-nav only. On an initial load the document was already emitted under the lock, so
-nothing streams in after release; drop that assertion from the initial-load test, or
-`page.reload()` first to fetch an unlocked document. The mechanism is in
-`reference/red-test-robustness.md`.
-
-## Baseline scaffold: do not ship
-
-Before optimizing, confirm the target exists with an unlocked check (no `instant()`). It
-disambiguates "not instant" from "marker absent for this user or environment". Run it as the test
-user; mismatch against the rig DRIFT list is what the C-gate catches
-(`reference/red-test-robustness.md`). Confirm the marker is real and reachable, then delete the
-scaffold before the PR.
-
-**The baseline must mirror the navigation type of the test you are shipping.** Drive a `<Link>`
-click when guarding the soft-nav shell; drive `page.goto()` when guarding the initial-load shell.
-The two shells can differ (`reference/real-app-patterns.md`): a click-driven baseline run against a
-shipped `goto` test would confirm a marker that the `goto` path never shows, which produces exactly
-the false RED the C-gate exists to prevent.
-
-```ts
-// soft-nav baseline: mirror the soft-nav instant() test
-test("dev-only: navigating to <b> renders its shell (no lock)", async ({
-  page,
-}) => {
-  await page.goto(testUrl("/"));
-  const trigger = page.getByRole("link", { name: "<Trigger>", exact: true });
-  await expect(trigger).toBeVisible({ timeout: 20000 });
-  await trigger.click();
-  await expect(page).toHaveURL(/\/<b>(\?|$)/); // confirm the real destination (no redirect away)
-  await expect(page.locator(SHELL_MARKER)).toBeVisible({ timeout: 15000 });
-});
-```
-
-```ts
-// initial-load baseline: mirror the initial-load instant() test (session pre-established)
-test("dev-only: <b> shell is served (no lock)", async ({ page }) => {
-  await page.goto(testUrl("/<b>"));
-  await expect(page.locator(SHELL_MARKER)).toBeVisible({ timeout: 15000 });
-});
-```
-
-Notes:
-
-- Pick `SHELL_MARKER` as a sync element of the destination's static shell, never streamed data.
-  Use a `data-testid` on a known static node rather than a guessed role/name.
-- Do not put a custom timeout, a `painted` boolean, or `isVisible({ timeout })` in the shipped
-  assertion, and do not add retries or hover-warming; see `reference/red-test-robustness.md`.

.github/skills/sanity-best-practices/SKILL.md

@@ -1,81 +0,0 @@
----
-name: sanity-best-practices
-description: Sanity development best practices for schema design, GROQ queries, TypeGen, Visual Editing, images, Portable Text, Studio structure, localization, migrations, Sanity Functions, Blueprints, and framework integrations such as Next.js, Nuxt, Astro, Remix, SvelteKit, Angular, Hydrogen, and the App SDK. Use this skill whenever working with Sanity schemas, defineType or defineField, GROQ or defineQuery, content modeling, Presentation or preview setups, Sanity-powered frontend integrations, Sanity Functions, documentEventHandler, defineDocumentFunction, defineMediaLibraryAssetFunction, @sanity/functions, @sanity/blueprints, sanity.blueprint.ts, event-driven content automation, or when reviewing and fixing a Sanity codebase.
----
-
-# Sanity Best Practices
-
-Comprehensive best practices and integration guides for Sanity development, maintained by Sanity. Use the quick reference below to load only the one or two topic files that match the task.
-
-## When to Apply
-
-Reference these guidelines when:
-
-- Setting up a new Sanity project or onboarding
-- Integrating Sanity with a frontend framework (Next.js, Nuxt, Astro, Remix, SvelteKit, Hydrogen)
-- Writing GROQ queries or optimizing performance
-- Designing content schemas
-- Implementing Visual Editing and live preview
-- Working with images, Portable Text, or page builders
-- Configuring Sanity Studio structure
-- Setting up TypeGen for type safety
-- Implementing localization
-- Migrating content from other systems
-- Building custom apps with the Sanity App SDK
-- Managing infrastructure with Blueprints
-- Automating content workflows with Sanity Functions
-
-## Global Rules
-
-- Let Sanity generate `_id` values for ordinary documents. Do not create deterministic UUIDs, slug-derived IDs, or legacy-system IDs when creating documents.
-- Model relationships with `reference` fields, then resolve related documents with GROQ lookups, source-key fields, or returned `_id` values from created documents.
-- Use explicit document IDs mainly for singleton documents controlled by Studio Structure, including localized singletons such as `homePage-en`.
-
-## Quick Reference
-
-### Integration Guides
-
-- `get-started` - Interactive onboarding for new Sanity projects
-- `nextjs` - Next.js App Router, Live Content API, standalone Studio
-- `nuxt` - Nuxt integration with @nuxtjs/sanity
-- `angular` - Angular integration with @sanity/client, signals, resource API
-- `astro` - Astro integration with @sanity/astro
-- `remix` - React Router / Remix integration
-- `svelte` - SvelteKit integration with @sanity/svelte-loader
-- `hydrogen` - Shopify Hydrogen with Sanity
-- `project-structure` - Standalone Studio and monorepo patterns
-- `app-sdk` - Custom applications with Sanity App SDK
-- `blueprints` - Infrastructure as Code: blueprint files, stacks, plan/deploy workflow, error recovery, CI deploys
-- `functions` - Automating content workflows with Sanity Functions
-
-### Topic Guides
-
-- `groq` - GROQ query patterns, type safety, performance optimization
-- `schema` - Schema design, field definitions, validation, deprecation patterns
-- `visual-editing` - Presentation Tool, Stega, overlays, live preview
-- `page-builder` - Page Builder arrays, block components, live editing
-- `portable-text` - Rich text rendering and custom components
-- `image` - Image schema, URL builder, hotspots, LQIP, Next.js Image
-- `studio-structure` - Desk structure, singletons, navigation
-- `typegen` - TypeGen configuration, workflow, type utilities
-- `seo` - Metadata, sitemaps, Open Graph, JSON-LD
-- `localization` - i18n patterns, document vs field-level, locale management
-- `migration` - Content import overview (see also `migration-html-import`)
-- `migration-html-import` - HTML to Portable Text with @portabletext/block-tools
-
-## How to Use
-
-Start with the single framework or topic guide that best matches the request, then read additional references only when the task crosses concerns. Use these reference files for detailed explanations and code examples:
-
-```
-references/groq.md
-references/schema.md
-references/nextjs.md
-```
-
-Each reference file contains:
-
-- Comprehensive topic or integration coverage
-- Incorrect and correct code examples
-- Decision matrices and workflow guidance
-- Framework-specific patterns where applicable

.github/skills/sanity-best-practices/references/angular.md

@@ -1,576 +0,0 @@
----
-title: Angular & Sanity Integration Rules
-description: Integration guide for Angular, including @sanity/client setup, data fetching with signals and resource API, Portable Text rendering, and image optimization.
----
-
-# Angular & Sanity Integration Rules
-
-Jump to the section that matches your Angular version or integration task instead of reading this guide straight through.
-
-## Table of Contents
-
-- Setup and configuration
-- Client setup (service pattern)
-- Data fetching patterns
-- Routing
-- Portable Text rendering
-- Image optimization
-- Modern Angular features
-- SSR and prerendering
-- Visual Editing
-- Error handling
-
-## 1. Setup & Configuration
-
-Use the official template `sanity-template-angular-clean` as a starting point. It provides a monorepo structure:
-
-```
-project/
-├── angular-app/    # Angular 19+ frontend
-└── studio/         # Sanity Studio
-```
-
-Install dependencies in the Angular app:
-
-```bash
-npm install @sanity/client @sanity/image-url @portabletext/to-html
-```
-
-Configure environment files for Sanity credentials:
-
-```typescript
-// environments/environment.ts
-export const environment = {
-  production: false,
-  sanity: {
-    projectId: "your-project-id",
-    dataset: "production",
-    apiVersion: "2025-05-01",
-  },
-};
-```
-
-```typescript
-// environments/environment.production.ts
-export const environment = {
-  production: true,
-  sanity: {
-    projectId: "your-project-id",
-    dataset: "production",
-    apiVersion: "2025-05-01",
-  },
-};
-```
-
-> There is no Angular-specific Sanity SDK. Use `@sanity/client` directly, wrapped in an Angular service.
-
-### TypeGen in a Monorepo
-
-Sanity TypeGen generates TypeScript types from your schema and GROQ queries. In the Angular monorepo template, TypeGen runs from the Studio side but scans your Angular app's source files. Ensure `studio/sanity.cli.ts` points at the Angular app:
-
-```typescript
-// studio/sanity.cli.ts
-import { defineCliConfig } from "sanity/cli";
-
-export default defineCliConfig({
-  typegen: {
-    enabled: true,
-    path: "../angular-app/src/**/*.ts",
-    generates: "../angular-app/sanity.types.ts",
-  },
-});
-```
-
-The remaining defaults (`overloadClientMethods: true`, `schema: "schema.json"`) work as-is. Include the generated types file in `angular-app/tsconfig.json` (usually covered by `"include": ["src/**/*.ts", "sanity.types.ts"]`). See `typegen.md` for the full TypeGen workflow, git strategy, and configuration options.
-
-## 2. Client Setup (Service Pattern)
-
-Create an injectable service wrapping `@sanity/client` and `@sanity/image-url`:
-
-```typescript
-import { Injectable } from '@angular/core'
-import { createClient, type ClientReturn, type QueryParams, type SanityClient } from '@sanity/client'
-import imageUrlBuilder, { type ImageUrlBuilder } from '@sanity/image-url'
-import type { SanityImageSource } from '@sanity/image-url/lib/types/types'
-import { environment } from '../environments/environment'
-
-@Injectable({ providedIn: 'root' })
-export class SanityService {
-  private client: SanityClient
-  private builder: ImageUrlBuilder
-
-  constructor() {
-    this.client = createClient({
-      projectId: environment.sanity.projectId,
-      dataset: environment.sanity.dataset,
-      apiVersion: environment.sanity.apiVersion,
-      useCdn: true,
-    })
-    this.builder = imageUrlBuilder(this.client)
-  }
-
-  // ClientReturn resolves TypeGen's declaration-merged overloads for defineQuery strings
-  fetch<Query extends string>(query: Query, params?: QueryParams): Promise<ClientReturn<Query>> {
-    return this.client.fetch(query, params)
-  }
-
-  getImageUrlBuilder(source: SanityImageSource) {
-    return this.builder.image(source)
-  }
-}
-```
-
-For preview/draft content, create a second client instance with a token and `useCdn: false`. Never expose tokens in client-side bundles — use server-side rendering or a proxy endpoint for authenticated requests.
-
-## 3. Data Fetching Patterns
-
-### A. `resource` API (Angular 19+, Recommended)
-
-The `resource` API works natively with promises and integrates with Angular signals:
-
-```typescript
-import { Component, input, resource, inject } from '@angular/core'
-import { defineQuery } from 'groq'
-import { SanityService } from '../sanity.service'
-
-const POST_QUERY = defineQuery(`*[_type == "post" && slug.current == $slug][0]{
-  title, body, mainImage, publishedAt
-}`)
-
-@Component({
-  selector: 'app-post',
-  standalone: true,
-  template: `
-    @if (post.value(); as p) {
-      <h1>{{ p.title }}</h1>
-      <time>{{ p.publishedAt | date }}</time>
-    } @else if (post.isLoading()) {
-      <p>Loading…</p>
-    } @else if (post.error()) {
-      <p>Error loading post</p>
-    }
-  `,
-})
-export default class PostComponent {
-  slug = input.required<string>()
-  private sanity = inject(SanityService)
-
-  post = resource({
-    params: () => ({ slug: this.slug() }),
-    loader: ({ params }) => this.sanity.fetch(POST_QUERY, params),
-  })
-}
-```
-
-The `resource` automatically re-fetches when `slug` changes and exposes `value()`, `isLoading()`, and `error()` signals.
-
-> **TypeGen:** Wrapping queries in `defineQuery` enables Sanity TypeGen to infer return types automatically — no manual type imports needed. See `typegen.md` for the full workflow.
-
-### B. `rxResource` (Observable-based)
-
-For teams using RxJS patterns or needing operators like `retry` and `debounceTime`:
-
-```typescript
-import { Component, input, inject } from '@angular/core'
-import { rxResource } from '@angular/core/rxjs-interop'
-import { defineQuery } from 'groq'
-import { from } from 'rxjs'
-import { SanityService } from '../sanity.service'
-
-const POST_QUERY = defineQuery(`*[_type == "post" && slug.current == $slug][0]`)
-
-@Component({ /* ... */ })
-export default class PostComponent {
-  slug = input.required<string>()
-  private sanity = inject(SanityService)
-
-  post = rxResource({
-    params: () => ({ slug: this.slug() }),
-    loader: ({ params }) => from(this.sanity.fetch(POST_QUERY, params)),
-  })
-}
-```
-
-### C. `toSignal` (Angular 17–18)
-
-For apps not yet on Angular 19, convert observables to signals:
-
-```typescript
-import { Component, inject } from '@angular/core'
-import { toSignal } from '@angular/core/rxjs-interop'
-import { defineQuery } from 'groq'
-import { from } from 'rxjs'
-import { SanityService } from '../sanity.service'
-
-const POSTS_QUERY = defineQuery(`*[_type == "post"] | order(publishedAt desc)`)
-
-@Component({ /* ... */ })
-export class HomeComponent {
-  private sanity = inject(SanityService)
-  posts = toSignal(from(this.sanity.fetch(POSTS_QUERY)), { initialValue: [] })
-}
-```
-
-> **Note:** `toSignal` does not re-fetch on parameter changes. For dynamic queries, use `resource` or `rxResource`.
-
-### Choosing a pattern
-
-| Pattern      | Angular Version | Reactivity                  | Best For                      |
-| ------------ | --------------- | --------------------------- | ----------------------------- |
-| `resource`   | 19+             | Signal-based, auto re-fetch | New projects, dynamic queries |
-| `rxResource` | 19+             | RxJS + signals              | Teams using RxJS operators    |
-| `toSignal`   | 17+             | One-shot conversion         | Static queries, legacy apps   |
-
-## 4. Routing
-
-Use lazy-loaded routes with `withComponentInputBinding()` so route params bind directly to component inputs:
-
-```typescript
-// app.config.ts
-import { provideRouter, withComponentInputBinding } from "@angular/router";
-import { routes } from "./app.routes";
-
-export const appConfig = {
-  providers: [provideRouter(routes, withComponentInputBinding())],
-};
-```
-
-```typescript
-// app.routes.ts
-import { Routes } from "@angular/router";
-
-export const routes: Routes = [
-  {
-    path: "",
-    loadComponent: () => import("./home/home.component"),
-    pathMatch: "full",
-  },
-  {
-    path: "post/:slug",
-    loadComponent: () => import("./post/post.component"),
-  },
-];
-```
-
-With `withComponentInputBinding()`, the `:slug` route param is automatically bound to `slug = input.required<string>()` on the component — no need to inject `ActivatedRoute`.
-
-## 5. Portable Text Rendering
-
-### A. `@portabletext/to-html` with Angular Pipe (Recommended)
-
-```typescript
-import { Pipe, PipeTransform, inject } from '@angular/core'
-import { toHTML, type PortableTextComponents } from '@portabletext/to-html'
-import type { PortableTextBlock } from '@portabletext/types'
-import { SanityService } from '../sanity.service'
-
-@Pipe({ name: 'portableTextToHTML', standalone: true })
-export class PortableTextToHTMLPipe implements PipeTransform {
-  private sanity = inject(SanityService)
-
-  private components: PortableTextComponents = {
-    types: {
-      image: ({ value }) => {
-        const url = this.sanity.getImageUrlBuilder(value).width(800).auto('format').url()
-        return `<img src="${url}" alt="${value.alt || ''}" loading="lazy" />`
-      },
-    },
-    marks: {
-      link: ({ children, value }) =>
-        `<a href="${value.href}" rel="noopener noreferrer">${children}</a>`,
-    },
-  }
-
-  transform(value: PortableTextBlock[] | undefined): string {
-    if (!value) return ''
-    return toHTML(value, { components: this.components })
-  }
-}
-```
-
-Usage in templates:
-
-```html
-<div [innerHTML]="post.body | portableTextToHTML"></div>
-```
-
-### B. `@limitless-angular/sanity` (Community, Component-based)
-
-For full Angular component control over each block type, the community library `@limitless-angular/sanity` provides a component-based Portable Text renderer. This is useful when you need Angular-specific interactivity within rich text blocks.
-
-See `portable-text.md` for Portable Text schema design and serialization rules.
-
-## 6. Image Optimization
-
-Create a pipe wrapping `@sanity/image-url`:
-
-```typescript
-import { Pipe, PipeTransform, inject } from '@angular/core'
-import type { SanityImageSource } from '@sanity/image-url/lib/types/types'
-import { SanityService } from '../sanity.service'
-
-@Pipe({ name: 'sanityImage', standalone: true })
-export class SanityImagePipe implements PipeTransform {
-  private sanity = inject(SanityService)
-
-  transform(value: SanityImageSource | undefined, width?: number): string | null {
-    if (!value) return null
-    const builder = this.sanity.getImageUrlBuilder(value)
-    if (width) return builder.width(width).auto('format').url()
-    return builder.auto('format').url()
-  }
-}
-```
-
-Combine with Angular's `NgOptimizedImage` for LCP images:
-
-```html
-<!-- Priority image with NgOptimizedImage -->
-<img
-  [ngSrc]="post.mainImage | sanityImage: 1200"
-  width="1200"
-  height="630"
-  priority
-/>
-
-<!-- Lazy-loaded image -->
-<img
-  [src]="post.mainImage | sanityImage: 600"
-  [alt]="post.mainImage.alt"
-  loading="lazy"
-/>
-```
-
-❌ **Bad:** Fetching full-size images without width constraints.
-
-```html
-<img [src]="post.mainImage | sanityImage" />
-```
-
-✅ **Good:** Specifying width and using `auto('format')` for WebP/AVIF delivery.
-
-```html
-<img [src]="post.mainImage | sanityImage: 800" loading="lazy" />
-```
-
-### LQIP with `NgOptimizedImage`
-
-Sanity provides a base64 LQIP (Low Quality Image Placeholder) per image asset — but you must query it explicitly:
-
-```groq
-mainImage {
-  // @sanity/image-url needs these to build URLs with hotspot/crop support
-  asset,
-  hotspot,
-  crop,
-  alt,
-  // NgOptimizedImage needs these for placeholder and layout
-  "lqip": asset->metadata.lqip,
-  "width": asset->metadata.dimensions.width,
-  "height": asset->metadata.dimensions.height
-}
-```
-
-Feed the LQIP directly into `NgOptimizedImage`'s `placeholder` attribute:
-
-```html
-<img
-  [ngSrc]="post.mainImage | sanityImage: 1200"
-  [width]="post.mainImage.width"
-  [height]="post.mainImage.height"
-  [placeholder]="post.mainImage.lqip"
-  [alt]="post.mainImage.alt"
-  priority
-/>
-```
-
-Angular applies a CSS blur to the LQIP and crossfades to the full image on load. No extra libraries needed.
-
-> **Note:** LQIP strings are small (~200 bytes) so they're safe to inline in SSR HTML and `TransferState`. See `image.md` for the full image query patterns.
-
-See `image.md` for image field schema patterns and hotspot/crop configuration.
-
-## 7. Modern Angular Features
-
-When building with Sanity, leverage these Angular 19+ features:
-
-- **Standalone components** — Default in Angular 19. No `NgModule` boilerplate needed.
-- **Signals and `resource`** — Preferred over RxJS for data fetching. Simpler, less boilerplate.
-- **New control flow** — Use `@if`, `@for`, `@switch` with `@empty` for cleaner templates:
-
-```html
-@for (post of posts.value(); track post._id) {
-<app-post-card [post]="post" />
-} @empty {
-<p>No posts found.</p>
-}
-```
-
-- **`@defer` blocks** — Lazy-load below-fold content:
-
-```html
-@defer (on viewport) {
-<app-comments [postId]="post._id" />
-} @placeholder {
-<p>Scroll to see comments…</p>
-}
-```
-
-- **`inject()` function** — Preferred over constructor injection for cleaner code.
-- **Zoneless change detection** — Experimental in Angular 19. Works well with signals-based data fetching since signals automatically notify the framework of changes.
-
-## 8. SSR & Prerendering
-
-Angular 17+ includes built-in SSR support (replacing Angular Universal):
-
-```typescript
-// app.config.server.ts
-import { provideClientHydration } from "@angular/platform-browser";
-import { provideServerRendering } from "@angular/platform-server";
-
-export const serverConfig = {
-  providers: [provideServerRendering(), provideClientHydration()],
-};
-```
-
-Key considerations for Sanity + Angular SSR:
-
-| Feature                 | Details                                                                                                                               |
-| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| **Hydration**           | `provideClientHydration()` preserves server-rendered DOM. The client reuses it instead of re-rendering.                               |
-| **HTTP Transfer Cache** | Only works with Angular's `HttpClient`. Since `@sanity/client` uses its own HTTP transport, use `TransferState` manually (see below). |
-| **Prerendering**        | Use `getPrerenderParams` in route config to generate static pages at build time.                                                      |
-
-### Transfer State for `@sanity/client`
-
-Angular's built-in HTTP Transfer Cache does not cover `@sanity/client` requests. Without manual transfer, the client re-fetches every query during hydration. Add `TransferState` to the service from Section 2:
-
-```typescript
-+ async function hashQuery(query: string, params?: QueryParams): Promise<string> {
-+   const input = query + JSON.stringify(params ?? {})
-+   const buffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(input))
-+   return Array.from(new Uint8Array(buffer), b => b.toString(16).padStart(2, '0')).join('')
-+ }
-
-import { Injectable, inject } from '@angular/core'
-+ import { isPlatformBrowser, isPlatformServer } from '@angular/common'
-+ import { PLATFORM_ID, makeStateKey, TransferState } from '@angular/core'
-import { createClient, type ClientReturn, type QueryParams, type SanityClient } from '@sanity/client'
-
-export class SanityService {
-  private client: SanityClient
-+  private transferState = inject(TransferState)
-+  private platformId = inject(PLATFORM_ID)
-
-  async fetch<Query extends string>(query: Query, params?: QueryParams): Promise<ClientReturn<Query>> {
-+    const key = makeStateKey<ClientReturn<Query>>(await hashQuery(query, params))
-+
-+    if (isPlatformBrowser(this.platformId)) {
-+      const cached = this.transferState.get(key, null)
-+      if (cached !== null) {
-+        this.transferState.remove(key)
-+        return cached
-+      }
-+    }
-+
-    const result = await this.client.fetch(query, params)
-+
-+    if (isPlatformServer(this.platformId)) {
-+      this.transferState.set(key, result)
-+    }
-+
-    return result
-  }
-}
-```
-
-The `hashQuery` helper keeps `TransferState` keys short (SHA-256 hex) instead of embedding raw GROQ strings in the serialized HTML.
-
-Prerendering dynamic routes:
-
-```typescript
-// app.routes.server.ts
-import { RenderMode, ServerRoute } from "@angular/ssr";
-
-export const serverRoutes: ServerRoute[] = [
-  {
-    path: "post/:slug",
-    renderMode: RenderMode.Prerender,
-    async getPrerenderParams() {
-      // Fetch all slugs from Sanity at build time
-      const client = createClient({
-        projectId: "...",
-        dataset: "...",
-        apiVersion: "...",
-        useCdn: true,
-      });
-      const slugs = await client.fetch<string[]>(
-        `*[_type == "post"].slug.current`,
-      );
-      return slugs.map((slug) => ({ slug }));
-    },
-  },
-  { path: "**", renderMode: RenderMode.Server },
-];
-```
-
-❌ **Bad:** Using `isPlatformBrowser()` in templates to conditionally render content — causes hydration mismatch.
-
-✅ **Good:** Using `@defer` or `afterNextRender()` for browser-only code.
-
-## 9. Visual Editing
-
-> **Important:** Angular does not have official Sanity Visual Editing support. There is no `@sanity/visual-editing` integration, no Stega encoding, and no click-to-edit overlay for Angular applications. This is unlike Next.js, Nuxt, and SvelteKit which have first-party support.
-
-### Preview Mode (Basic)
-
-For draft content preview, create a separate preview client with an API token:
-
-```typescript
-@Injectable({ providedIn: 'root' })
-export class SanityService {
-  private client: SanityClient
-  private previewClient: SanityClient
-
-  constructor() {
-    this.client = createClient({
-      projectId: environment.sanity.projectId,
-      dataset: environment.sanity.dataset,
-      apiVersion: environment.sanity.apiVersion,
-      useCdn: true,
-    })
-
-    this.previewClient = this.client.withConfig({
-      useCdn: false,
-      token: environment.sanity.previewToken, // Server-side only!
-      perspective: 'drafts',
-    })
-  }
-
-  fetch<Query extends string>(query: Query, params?: QueryParams, preview = false): Promise<ClientReturn<Query>> {
-    const client = preview ? this.previewClient : this.client
-    return client.fetch(query, params)
-  }
-}
-```
-
-> **Security:** Never expose the preview token in client-side bundles. Use this pattern only with SSR where the token stays on the server, or proxy preview requests through a backend API.
-
-### Community Visual Editing
-
-The community library `@limitless-angular/sanity` provides experimental Visual Editing support for Angular, including overlay click-to-edit functionality. Check its documentation for current status and limitations.
-
-## 10. Error Handling
-
-Common errors when integrating Angular with Sanity:
-
-| Error               | Cause                                   | Solution                                                                                              |
-| ------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------- |
-| `401 Unauthorized`  | Invalid or missing API token            | Verify token in [Sanity Manage](https://www.sanity.io/manage). Ensure it has correct permissions.     |
-| `403 Forbidden`     | CORS origin not allowed                 | Add your Angular dev/production URL to CORS origins in [Sanity Manage](https://www.sanity.io/manage). |
-| `422 Invalid query` | GROQ syntax error                       | Test queries in Vision plugin or Sanity's GROQ playground. See `groq.md`.                             |
-| Hydration mismatch  | Conditional rendering based on platform | Use `@defer` or `afterNextRender()` instead of `isPlatformBrowser()` checks.                          |
-| Empty response      | Missing dataset or wrong `apiVersion`   | Verify environment config. Use a date-based `apiVersion` (e.g., `'2025-05-01'`).                      |
-| Images not loading  | Missing `@sanity/image-url` setup       | Ensure `getImageUrlBuilder` is called with a valid image reference. See `image.md`.                   |
-
-For GROQ query patterns and best practices, see `groq.md`. For schema design, see `schema.md`.

.github/skills/sanity-best-practices/references/app-sdk.md

@@ -1,462 +0,0 @@
----
-title: Sanity App SDK
-description: Rules for building custom applications with the Sanity App SDK, including React hooks, document handles, real-time patterns, and Suspense best practices.
----
-
-# Sanity App SDK
-
-Build custom React applications that interact with Sanity content in real-time.
-
-## Tech Stack
-
-- **Framework:** React 19+, TypeScript
-- **Packages:** `@sanity/sdk`, `@sanity/sdk-react`
-- **Optional UI:** `@sanity/ui`, `styled-components`
-- **Runtime:** Node.js 20+
-
-## Commands
-
-```bash
-# Basic quickstart
-npx sanity@latest init --template app-quickstart --organization <your-org-id> --output-path . --typescript --skip-mcp
-
-# With Sanity UI components
-npx sanity@latest init --template app-sanity-ui --organization <your-org-id> --output-path . --typescript --skip-mcp
-
-# Start development server
-npm run dev
-
-# Deploy to Sanity
-npx sanity@latest deploy
-
-# Install Sanity UI
-npm install @sanity/ui styled-components
-```
-
-## Project Structure
-
-```
-my-app/
-├── sanity.cli.ts        # CLI config (org ID, entry point)
-├── src/
-│   ├── App.tsx          # Root component with SanityApp provider
-│   ├── App.css          # Global styles
-│   └── components/      # Your components
-├── package.json
-└── tsconfig.json
-```
-
-## Boundaries
-
-- **Always:** Wrap data-fetching components in `<Suspense>`, use `documentId` as React `key`, read/write directly to Content Lake (not local state)
-- **Always:** Use `useDocuments` for lists, `useDocumentProjection` for display, `useDocument` + `useEditDocument` for editing
-- **Ask first:** Before using `useQuery` with raw GROQ (prefer `useDocuments` + `useDocumentProjection`)
-- **Ask first:** Before adding multiple data-fetching hooks in a single component
-- **Never:** Use `useState` for form values that should sync with Content Lake
-- **Never:** Use array index as React `key` for document lists (breaks real-time updates)
-- **Never:** Forget the `fallback` prop on `<SanityApp>` and `<Suspense>` boundaries
-
----
-
-## Configuration
-
-### CLI Config (`sanity.cli.ts`)
-
-```typescript
-import { defineCliConfig } from "sanity/cli";
-
-export default defineCliConfig({
-  app: {
-    organizationId: "your-org-id",
-    entry: "./src/App.tsx",
-  },
-});
-```
-
-### App Root (`src/App.tsx`)
-
-```typescript
-import { SanityApp, type SanityConfig } from '@sanity/sdk-react'
-
-export default function App() {
-  const config: SanityConfig[] = [
-    {
-      projectId: 'your-project-id',
-      dataset: 'production',
-    },
-  ]
-
-  return (
-    <SanityApp config={config} fallback={<div>Loading...</div>}>
-      <YourComponents />
-    </SanityApp>
-  )
-}
-```
-
-### With Sanity UI
-
-```typescript
-import { SanityApp, type SanityConfig } from '@sanity/sdk-react'
-import { ThemeProvider } from '@sanity/ui'
-import { buildTheme } from '@sanity/ui/theme'
-
-const theme = buildTheme()
-
-export default function App() {
-  const config: SanityConfig[] = [
-    { projectId: 'your-project-id', dataset: 'production' },
-  ]
-
-  return (
-    <ThemeProvider theme={theme}>
-      <SanityApp config={config} fallback={<div>Loading...</div>}>
-        <YourComponents />
-      </SanityApp>
-    </ThemeProvider>
-  )
-}
-```
-
-### Environment Variables
-
-Prefix with `SANITY_APP_` for automatic bundling:
-
-```bash
-SANITY_APP_PROJECT_ID=abc123
-SANITY_APP_DATASET=production
-```
-
-Access: `process.env.SANITY_APP_PROJECT_ID`
-
----
-
-## Document Handles
-
-Lightweight references to documents. Fetch handles first, then load content as needed.
-
-```typescript
-interface DocumentHandle {
-  documentId: string;
-  documentType: string;
-  projectId?: string;
-  dataset?: string;
-}
-```
-
-### Creating Handles
-
-```typescript
-// Best: From useDocuments hook
-const { data: handles } = useDocuments({ documentType: 'article' })
-
-// Good: With helper (preserves literal types for TypeGen)
-import { createDocumentHandle } from '@sanity/sdk'
-const handle = createDocumentHandle({
-  documentId: 'my-doc-id',
-  documentType: 'article',
-})
-
-// Good: With as const (preserves literal types)
-const handle = {
-  documentId: 'my-doc-id',
-  documentType: 'article',
-} as const
-```
-
----
-
-## Hook Selection
-
-| Hook                    | Use Case                             | Returns                |
-| ----------------------- | ------------------------------------ | ---------------------- |
-| `useDocuments`          | List of documents (infinite scroll)  | Document handles       |
-| `usePaginatedDocuments` | Paginated lists with page controls   | Document handles       |
-| `useDocument`           | Single document, real-time editing   | Full document or field |
-| `useDocumentProjection` | Specific fields, display only        | Projected data         |
-| `useQuery`              | Complex GROQ queries (use sparingly) | Raw query results      |
-
----
-
-## Code Patterns
-
-### Fetching a Document List
-
-```typescript
-// Good: Fetch handles, render items with Suspense
-import { Suspense } from 'react'
-import { useDocuments } from '@sanity/sdk-react'
-
-function ArticleList() {
-  const { data, hasMore, loadMore, isPending } = useDocuments({
-    documentType: 'article',
-    batchSize: 10,
-    orderings: [{ field: '_updatedAt', direction: 'desc' }],
-  })
-
-  return (
-    <>
-      <ul>
-        {data.map((handle) => (
-          <Suspense key={handle.documentId} fallback={<li>Loading...</li>}>
-            <ArticleItem {...handle} />
-          </Suspense>
-        ))}
-      </ul>
-      {hasMore && (
-        <button onClick={loadMore} disabled={isPending}>
-          Load More
-        </button>
-      )}
-    </>
-  )
-}
-```
-
-```typescript
-// Bad: Over-fetching with raw GROQ, no pagination
-function BadArticleList() {
-  const { data } = useQuery(`*[_type == "article"]`)
-  return data?.map((doc, i) => <li key={i}>{doc.title}</li>)
-}
-```
-
-### Projecting Content from a Handle
-
-```typescript
-// Good: Project only needed fields
-import { useDocumentProjection, type DocumentHandle } from '@sanity/sdk-react'
-
-function ArticleItem(handle: DocumentHandle) {
-  const { data } = useDocumentProjection({
-    ...handle,
-    projection: `{
-      title,
-      "authorName": author->name,
-      "imageUrl": image.asset->url
-    }`,
-  })
-
-  if (!data) return null
-
-  return (
-    <li>
-      <h2>{data.title}</h2>
-      <p>By {data.authorName}</p>
-    </li>
-  )
-}
-```
-
-### Real-time Editing
-
-```typescript
-// Good: Read and write directly to Content Lake
-import { useDocument, useEditDocument, type DocumentHandle } from '@sanity/sdk-react'
-
-function TitleInput(handle: DocumentHandle) {
-  const { data: title } = useDocument({ ...handle, path: 'title' })
-  const editTitle = useEditDocument({ ...handle, path: 'title' })
-
-  return (
-    <input
-      type="text"
-      value={title ?? ''}
-      onChange={(e) => editTitle(e.currentTarget.value)}
-    />
-  )
-}
-```
-
-```typescript
-// Bad: Local state with submit button - causes stale data
-function BadTitleForm(handle: DocumentHandle) {
-  const [value, setValue] = useState('')
-  const editTitle = useEditDocument({ ...handle, path: 'title' })
-
-  function handleSubmit(e: FormEvent) {
-    e.preventDefault()
-    editTitle(value) // Only writes on submit!
-  }
-
-  return (
-    <form onSubmit={handleSubmit}>
-      <input value={value} onChange={(e) => setValue(e.target.value)} />
-      <button type="submit">Save</button>
-    </form>
-  )
-}
-```
-
-### Document Actions
-
-```typescript
-import {
-  useApplyDocumentActions,
-  publishDocument,
-  unpublishDocument,
-  deleteDocument,
-} from '@sanity/sdk-react'
-
-function DocumentActions({ handle }: { handle: DocumentHandle }) {
-  const apply = useApplyDocumentActions()
-
-  return (
-    <div>
-      <button onClick={() => apply(publishDocument(handle))}>Publish</button>
-      <button onClick={() => apply(unpublishDocument(handle))}>Unpublish</button>
-      <button onClick={() => apply(deleteDocument(handle))}>Delete</button>
-    </div>
-  )
-}
-```
-
----
-
-## Suspense Patterns
-
-The App SDK uses React Suspense. Every data-fetching component must be wrapped.
-
-### One Hook Per Component
-
-```typescript
-// Good: Separate fetchers into separate components
-function EventsAndVenues() {
-  return (
-    <>
-      <Suspense fallback="Loading events...">
-        <EventsList />
-      </Suspense>
-      <Suspense fallback="Loading venues...">
-        <VenuesList />
-      </Suspense>
-    </>
-  )
-}
-
-function EventsList() {
-  const { data } = useDocuments({ documentType: 'event' })
-  return <List items={data} />
-}
-
-function VenuesList() {
-  const { data } = useDocuments({ documentType: 'venue' })
-  return <List items={data} />
-}
-```
-
-```typescript
-// Bad: Multiple fetchers in one component
-function BadComponent() {
-  const { data: events } = useDocuments({ documentType: "event" });
-  const { data: venues } = useDocuments({ documentType: "venue" });
-  // Both trigger Suspense together, causing unnecessary re-renders
-}
-```
-
-### Prevent Layout Shift
-
-```typescript
-// Good: Fallback matches final component dimensions
-const BUTTON_TEXT = 'Open in Studio'
-
-export function OpenInStudio({ handle }: { handle: DocumentHandle }) {
-  return (
-    <Suspense fallback={<Button text={BUTTON_TEXT} disabled />}>
-      <OpenInStudioButton handle={handle} />
-    </Suspense>
-  )
-}
-
-function OpenInStudioButton({ handle }: { handle: DocumentHandle }) {
-  const { navigateToStudioDocument } = useNavigateToStudioDocument(handle)
-  return <Button onClick={navigateToStudioDocument} text={BUTTON_TEXT} />
-}
-```
-
----
-
-## Event Handling
-
-```typescript
-import { DocumentEvent, useDocumentEvent } from "@sanity/sdk-react";
-
-function DocumentWatcher(handle: DocumentHandle) {
-  useDocumentEvent({
-    ...handle,
-    onEvent: (event) => {
-      switch (event.type) {
-        case "edited":
-          console.log("Edited:", event.documentId);
-          break;
-        case "published":
-          console.log("Published:", event.documentId);
-          break;
-        case "deleted":
-          console.log("Deleted:", event.documentId);
-          break;
-      }
-    },
-  });
-
-  return null;
-}
-```
-
----
-
-## Multi-Project Apps
-
-```typescript
-const config: SanityConfig[] = [
-  { projectId: "project-1", dataset: "production" },
-  { projectId: "project-2", dataset: "staging" },
-];
-
-// Handles include project/dataset info
-const handle: DocumentHandle = {
-  documentId: "doc-123",
-  documentType: "article",
-  projectId: "project-1",
-  dataset: "production",
-};
-```
-
----
-
-## Lazy Loading with Refs
-
-```typescript
-function LazyContent(handle: DocumentHandle) {
-  const ref = useRef(null)
-
-  const { data } = useDocumentProjection({
-    ...handle,
-    ref, // Only loads when element enters viewport
-    projection: '{ title, body }',
-  })
-
-  return <div ref={ref}>{data?.title}</div>
-}
-```
-
----
-
-## What's NOT Included
-
-The App SDK provides hooks and data stores. You bring:
-
-- UI components (use Sanity UI or your own)
-- Router
-- Form validation
-- Schema validation
-
----
-
-## Troubleshooting
-
-| Issue             | Solution                                              |
-| ----------------- | ----------------------------------------------------- |
-| Safari dev issues | Use Chrome or Firefox during development              |
-| Port 3333 in use  | `npm run dev -- --port 3334`                          |
-| Auth errors       | `npx sanity@latest logout && npx sanity@latest login` |

.github/skills/sanity-best-practices/references/astro.md

@@ -1,174 +0,0 @@
----
-title: Astro & Sanity Integration Rules
-description: Integration guide for Astro, including @sanity/astro, visual editing, and data fetching.
----
-
-# Astro & Sanity Integration Rules
-
-## 1. Setup & Configuration
-
-### Scaffold a new Astro app
-
-```bash
-npm create astro@latest my-app -- --template with-tailwindcss --install --git --yes
-cd my-app
-```
-
-`--yes` accepts defaults non-interactively. `--install` runs `npm install` for you, `--git` initializes a repo.
-
-### Installation
-
-Add the `@sanity/astro` integration and the renderer/helper packages used by the examples below.
-
-```bash
-npx astro add @sanity/astro
-npm install astro-portabletext @sanity/image-url groq
-```
-
-`@sanity/astro` provides the `sanity:client` virtual module. `astro-portabletext` renders Portable Text. `@sanity/image-url` builds image URLs. `groq` exports `defineQuery` for typed queries.
-
-### Configuration (`astro.config.mjs`)
-
-Use the official `@sanity/astro` integration. `astro.config.mjs` runs at config time before Astro's env loading, so `import.meta.env.PUBLIC_*` is not available there — use Vite's `loadEnv` to read the same `PUBLIC_` variables your pages will use.
-
-```javascript
-import sanity from "@sanity/astro";
-import { defineConfig } from "astro/config";
-import { loadEnv } from "vite";
-
-const { PUBLIC_SANITY_PROJECT_ID, PUBLIC_SANITY_DATASET } = loadEnv(
-  process.env.NODE_ENV ?? "development",
-  process.cwd(),
-  "",
-);
-
-export default defineConfig({
-  integrations: [
-    sanity({
-      projectId: PUBLIC_SANITY_PROJECT_ID,
-      dataset: PUBLIC_SANITY_DATASET,
-      useCdn: false, // False for static builds
-      studioBasePath: "/admin", // Optional — only if embedding the Studio
-    }),
-  ],
-});
-```
-
-Inside `.astro` files and components you can keep using `import.meta.env.PUBLIC_SANITY_*` directly; the `loadEnv` shim above is config-only.
-
-### Client Type Safety
-
-Enable types in `tsconfig.json`.
-
-```json
-{
-  "compilerOptions": {
-    "types": ["@sanity/astro/module"]
-  }
-}
-```
-
-## 2. Data Fetching
-
-### Basic Fetching
-
-Use `sanityClient` from `sanity:client` in the frontmatter of your `.astro` files.
-
-```astro
----
-import { sanityClient } from "sanity:client";
-import { defineQuery } from "groq";
-
-const POSTS_QUERY = defineQuery(`*[_type == "post"]{title, slug}`);
-const posts = await sanityClient.fetch(POSTS_QUERY);
----
-<ul>
-  {posts.map(post => <li>{post.title}</li>)}
-</ul>
-```
-
-### Helper Functions
-
-It's best practice to abstract queries into a utility file (e.g., `src/utils/sanity.ts`).
-
-```typescript
-import { defineQuery } from "groq";
-import { sanityClient } from "sanity:client";
-
-const POSTS_QUERY = defineQuery(`*[_type == "post" && defined(slug.current)]`);
-
-export async function getPosts() {
-  return await sanityClient.fetch(POSTS_QUERY);
-}
-```
-
-### Dynamic Routes (`[slug].astro`)
-
-Astro hoists `getStaticPaths()` into a separate module context. Module-scope `const` declarations in the frontmatter are NOT accessible inside it — referencing them throws `ReferenceError: <NAME> is not defined` at request time. Define queries used by `getStaticPaths` inside the function, or import them from a utility module.
-
-```astro
----
-import { sanityClient } from "sanity:client";
-import { defineQuery } from "groq";
-import { PortableText } from "astro-portabletext";
-
-// Module-scope queries are fine for module-scope code…
-const POST_QUERY = defineQuery(`*[_type == "post" && slug.current == $slug][0]{ title, body }`);
-
-// …but anything used inside getStaticPaths must live inside it.
-export async function getStaticPaths() {
-  const SLUGS_QUERY = defineQuery(
-    `*[_type == "post" && defined(slug.current)]{ "params": { "slug": slug.current } }`
-  );
-  return await sanityClient.fetch(SLUGS_QUERY);
-}
-
-const { slug } = Astro.params;
-const post = await sanityClient.fetch(POST_QUERY, { slug });
----
-<article>
-  <h1>{post?.title}</h1>
-  {post?.body && <PortableText value={post.body} />}
-</article>
-```
-
-## 3. Portable Text
-
-Use `astro-portabletext` for rendering rich text.
-
-```astro
----
-import { PortableText } from "astro-portabletext";
-const { body } = Astro.props;
----
-<div class="prose">
-  <PortableText value={body} />
-</div>
-```
-
-## 4. Image Handling
-
-Use `@sanity/image-url` to generate optimized image URLs.
-
-```typescript
-import imageUrlBuilder from "@sanity/image-url";
-import { sanityClient } from "sanity:client";
-
-const builder = imageUrlBuilder(sanityClient);
-
-export function urlFor(source) {
-  return builder.image(source);
-}
-```
-
-## 5. Visual Editing (Live Preview)
-
-Astro handles visual editing slightly differently depending on if you are using Hybrid or Static mode.
-
-### Setup
-
-Ensure `stega` is enabled in your client configuration if you want clickable overlays.
-
-For real-time updates in the presentation tool, you typically need a React component wrapper (since Astro components don't re-render on the client) or use the View Transitions API with a loader.
-
-_Note: The `@sanity/astro` integration is evolving. Check the latest docs for "Visual Editing" support._

.github/skills/sanity-best-practices/references/blueprints.md

@@ -1,280 +0,0 @@
----
-title: Sanity Blueprints
-description: Rules for Sanity Blueprints, the Infrastructure as Code solution for managing Sanity resources declaratively. Covers blueprint files, stacks and scope, the plan/deploy workflow, deletion policies, error recovery, and CI deployment.
----
-
-# Sanity Blueprints
-
-Sanity's Infrastructure as Code (IaC) solution. Define resources declaratively in `sanity.blueprint.ts`, track the file in version control, preview changes with `plan`, apply them with `deploy`. Blueprints is the only way to deploy Sanity Functions.
-
-The CLI is built for unattended use: every command accepts `--json`, all IDs can be supplied via flags or environment variables, and `--help` on any command is the authoritative reference. Always run via `npx sanity@latest blueprints <command>`.
-
-## Mental Model
-
-```
-Blueprint file (code, intent) → Stack (deployed state) → Resources (real infrastructure)
-```
-
-| Concept            | What it is                                                                                                                                   |
-| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Blueprint file** | `sanity.blueprint.ts`, the declarative manifest of desired resources. The source of truth: if it's not in the file, it's not deployed        |
-| **Resource**       | One managed thing (function, CORS origin, webhook, role, robot token, dataset). Identified by a unique `name`                                |
-| **Definer**        | Typed helper from `@sanity/blueprints` (e.g. `defineCorsOrigin`) that declares a resource and validates input as you write                   |
-| **Stack**          | The deployed counterpart of the file: the live resources on Sanity's side. One file can deploy to many Stacks (e.g. `staging`, `production`) |
-| **Config file**    | `.sanity/blueprint.config.json`, links the local file to a Stack and records scope. Gitignored by `init` automatically; not secret           |
-| **Scope**          | `project` or `organization`. Determines which resource types a Stack can manage                                                              |
-
-### Key behaviors
-
-- Resources are matched **by `name`** between file and Stack. `plan` buckets every resource as create, update, no-op, or destroy.
-- **There is no rename.** Changing a resource's `name` destroys the old resource and creates a new one under the new name.
-- **Removal is destruction.** Deleting a resource from the file destroys it on the next deploy (subject to its deletion policy). `blueprints destroy` is equivalent to deploying an empty file.
-- Deploys apply in dependency order. On partial failure, completed changes are rolled back best-effort in reverse order. Rollback is **not atomic**; some actions may be irreversible.
-
-## Three different "deploy" commands
-
-Do not confuse these:
-
-| Command                    | What it deploys                                           |
-| -------------------------- | --------------------------------------------------------- |
-| `sanity blueprints deploy` | Infrastructure resources defined in `sanity.blueprint.ts` |
-| `sanity schema deploy`     | Studio schema to Content Lake (for MCP and editor access) |
-| `sanity deploy`            | The Studio application to Sanity hosting                  |
-
-## The Blueprint File
-
-`sanity.blueprint.ts` default-exports a `defineBlueprint` call. TypeScript is idiomatic (definers validate inline and provide editor help); `.js` and hand-written `.json` also work but new files should use TypeScript.
-
-```typescript
-import {
-  defineBlueprint,
-  defineCorsOrigin,
-  defineDocumentFunction,
-} from "@sanity/blueprints";
-
-export default defineBlueprint({
-  values: {
-    corsOrigin: "https://studio.example.com",
-  },
-  resources: [
-    defineCorsOrigin({
-      name: "studio-cors",
-      origin: "$.values.corsOrigin",
-    }),
-    defineDocumentFunction({
-      name: "first-published",
-      event: {
-        on: ["create", "update"],
-        filter: "_type == 'post' && !defined(firstPublished)",
-      },
-    }),
-  ],
-});
-```
-
-- `resources` is an array of definer outputs. Every resource requires a unique `name`.
-- `values` holds reusable file-level constants (always strings), referenced as `$.values.<key>`.
-- Resource-type-specific fields are documented in the typed reference: https://reference.sanity.io/_sanity/blueprints/
-
-### Discovering available resources
-
-The definers exported by `@sanity/blueprints` are the canonical list of what Blueprints can manage. Discover them by inspecting the package's exports (every `define*` function is a resource definer) and reading their TSDoc for fields, defaults, and examples, or browse the typed reference at https://reference.sanity.io/_sanity/blueprints/. Do not rely on a memorized list; new definers ship additively.
-
-When the Stack is organization-scoped, project-contained resources (CORS origins, webhooks, datasets, functions) must set their `project` field explicitly.
-
-For the semantics of an individual resource type (what a CORS origin, webhook, or role does and which values make sense), consult that feature's own Sanity documentation. This reference covers how Blueprints manages resources, not the resources themselves.
-
-## References and the Resource Graph
-
-Resources reference values and each other with `$` string paths:
-
-| Syntax                  | Resolves                                       | When                                      |
-| ----------------------- | ---------------------------------------------- | ----------------------------------------- |
-| `$.values.<key>`        | A constant from the `values` block             | At file evaluation                        |
-| `$.resources.<name>`    | Another resource in the file                   | At deploy time; creates a dependency edge |
-| `$.resources.<name>.id` | The generated ID of that resource, as a string | At deploy time                            |
-
-Blueprints builds the dependency graph from these references and orders work so dependencies are created first. Unresolved references and cycles fail validation before anything is deployed. To force ordering without a data reference, use `lifecycle: {dependsOn: '$.resources.<name>'}`.
-
-### Referencing an existing project
-
-The recommended pattern is an environment variable surfaced through `values`:
-
-```typescript
-import "dotenv/config";
-
-// the CLI does not read .env files itself
-
-export default defineBlueprint({
-  values: {
-    projectId: process.env.SANITY_PROJECT_ID ?? "",
-  },
-  resources: [
-    defineCorsOrigin({
-      name: "app-cors",
-      project: "$.values.projectId",
-      origin: "https://www.example.com",
-    }),
-  ],
-});
-```
-
-## Deletion Policies
-
-Set `lifecycle.deletionPolicy` on a resource to control what removal means:
-
-| Policy    | Removed from file    | Stack destroyed               | Notes                                        |
-| --------- | -------------------- | ----------------------------- | -------------------------------------------- |
-| `allow`   | Resource destroyed   | Resource destroyed            | Default for stateless resources              |
-| `retain`  | **Deployment fails** | Resource detached, kept alive | Default for stateful resources like datasets |
-| `replace` | Resource destroyed   | Resource destroyed            | Updates become destroy + recreate            |
-| `protect` | **Deployment fails** | **Deployment fails**          | Resource is never updated or destroyed       |
-
-Use `protect` for production-critical stateful resources:
-
-```typescript
-defineDataset({
-  name: "production",
-  lifecycle: { deletionPolicy: "protect" },
-});
-```
-
-A deletion-policy violation is a pre-deploy validation failure, not a partial deploy: fix the file (or consciously change the policy) and re-run `plan`.
-
-## Stacks, Environments, and Scope
-
-One blueprint file deploys to many Stacks. The `--stack <name-or-id>` flag (on `deploy`, `plan`, `info`, `logs`) selects the target; without it, the Stack recorded in `.sanity/blueprint.config.json` is used.
-
-- **Only `init` creates Stacks.** `--stack` never creates a Stack on a miss, so CI cannot accidentally provision infrastructure. Re-run `blueprints init .` to add another Stack for the same file.
-- Accounts are currently limited to **three Stacks per project scope**.
-- For per-environment differences, read an environment variable inside the file (e.g. `process.env.SANITY_ENV`) and deploy with the env var and `--stack` together. `SANITY_ENV` is a convention your file reads, not a CLI feature.
-
-### Project vs organization scope
-
-|                           | Project scope | Organization scope                                               |
-| ------------------------- | ------------- | ---------------------------------------------------------------- |
-| Stored in config as       | `projectId`   | `organizationId`                                                 |
-| Resources default to      | The project   | Nothing; each project-contained resource must name its `project` |
-| Org-scoped resource types | Not available | Available                                                        |
-
-Organization scope is recommended for anything beyond a single-project experiment. Convert an existing Stack with `blueprints promote` (safe, idempotent, additive, but **one-way**; requires `organization-update` admin permission).
-
-## CLI Commands
-
-```bash
-npx sanity@latest blueprints <command>
-```
-
-| Command             | Purpose                                                                                      |
-| ------------------- | -------------------------------------------------------------------------------------------- |
-| `init [dir]`        | Create a blueprint file and provision a remote Stack. The only command that creates Stacks   |
-| `plan`              | Preview the diff against the Stack. Read-only, always safe                                   |
-| `deploy`            | Apply the file to the Stack (`-m` message, `--no-wait` to queue and return)                  |
-| `info`              | Show Stack status and deployed resources. Remote read; works without local files             |
-| `stacks`            | List Stacks (`--include-projects` with `--organization-id` for org-wide audit)               |
-| `config`            | View or edit `.sanity/blueprint.config.json` (`--edit` with ID flags for scripting)          |
-| `logs`              | Deployment logs (`--watch`, `--limit 1-500`, `--since`/`--before` ISO timestamps)            |
-| `promote`           | Convert a Stack from project to organization scope. One-way (`--force` to skip confirmation) |
-| `destroy`           | Destroy the Stack and its resources (`--force` to skip confirmation). Local files remain     |
-| `doctor`            | Diagnose local/remote configuration issues (`--fix` to resolve interactively)                |
-| `mint-deploy-token` | Mint a long-lived robot token for CI deploys (`--print` for shell pipelines)                 |
-
-Running `npx sanity@latest blueprints --help` will show the latest available commands.  
-Use `npx sanity@latest blueprints <command> --help` to see options and examples for a specific command.
-
-Function scaffolding, local testing, secrets, and function logs live under `npx sanity@latest functions <command>` (`add`, `dev`, `test`, `env add|list|remove`, `logs`). See the `functions` reference.
-
-### Standard workflow
-
-```bash
-npx sanity@latest blueprints init .   # once: create file + Stack
-# edit sanity.blueprint.ts
-npx sanity@latest blueprints plan     # preview the diff, catch validation errors safely
-npx sanity@latest blueprints deploy   # apply
-npx sanity@latest blueprints info     # verify deployed state
-```
-
-Always run `plan` before `deploy`. It is read-only and surfaces validation errors, reference problems, scope mismatches, and deletion-policy violations without touching anything.
-
-### Exit codes
-
-`deploy` and `destroy` return: **`0`** succeeded, **`2`** failed, **`75`** accepted but completion could not be confirmed.
-
-**✅ Correct — treat exit 75 as unknown, then verify:**
-
-```bash
-npx sanity@latest blueprints deploy || status=$?
-if [ "${status:-0}" -eq 75 ]; then
-  npx sanity@latest blueprints info --json   # confirm actual Stack state
-fi
-```
-
-**❌ Incorrect — treating any nonzero exit as failure and retrying.** Exit 75 means the deployment was accepted; blindly redeploying can queue duplicate operations (deploy also refuses to start while another operation is in progress).
-
-### Scope resolution and environment variables
-
-For `organizationId`, `projectId`, and `stackId`, the first source that resolves wins: CLI flags → environment variables → the blueprint file module → the local config file.
-
-| Variable                                       | Purpose                                                    |
-| ---------------------------------------------- | ---------------------------------------------------------- |
-| `SANITY_AUTH_TOKEN`                            | Auth token (in CI, the minted deploy token)                |
-| `SANITY_ORGANIZATION_ID` / `SANITY_PROJECT_ID` | Scope                                                      |
-| `SANITY_BLUEPRINT_STACK_ID`                    | Target Stack                                               |
-| `SANITY_BLUEPRINT_PATH`                        | Path to the blueprint file or its directory                |
-| `SANITY_ASSET_TIMEOUT`                         | Seconds to wait for resource asset processing (default 60) |
-
-The CLI does not load `.env` files. Export variables in the shell or import `dotenv/config` inside the blueprint file.
-
-## Errors and Recovery
-
-Errors include a name, a human-readable message, and the **resource path**, which maps to a specific resource in your file. Five failure kinds:
-
-| Failure                                                                           | Caught        | What to do                                                 |
-| --------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------- |
-| Validation error (missing/invalid field, malformed file)                          | Before deploy | Fix the file at the reported resource path                 |
-| Unresolved reference or dependency cycle                                          | Before deploy | Fix the `$.resources.<name>` reference or break the cycle  |
-| Scope mismatch (org-scoped resource on project Stack, or no resolvable `project`) | Before deploy | Set the resource's `project` field, or `promote` the Stack |
-| Deletion-policy violation (change would remove a `retain`/`protect` resource)     | Before deploy | Restore the resource, or deliberately relax its policy     |
-| Execution failure (underlying service rejected the change)                        | During deploy | Read `blueprints logs`, fix the cause, redeploy            |
-
-Recovery procedure after any failure:
-
-1. Read the error message and resource path (`blueprints logs` re-reads failure output).
-2. Fix the blueprint file (or the external condition).
-3. Run `blueprints plan` to confirm the corrected diff.
-4. Run `blueprints deploy` again.
-
-Retrying without changing anything only makes sense for transient execution failures; the first four failure kinds are deterministic and will fail identically until the file changes. If local and remote state seem inconsistent, run `blueprints doctor` (and `doctor --fix`) before attempting anything destructive. After a partial-deploy rollback, `blueprints info` shows what is actually live; resources owned by other Stacks are never touched by rollback.
-
-## CI/CD
-
-Recommended workflow: `plan` on pull requests, `deploy` on merge to main. Official GitHub Actions: https://github.com/sanity-io/blueprints-actions
-
-```bash
-# one-time, by a human with access:
-npx sanity@latest blueprints mint-deploy-token --label "ci-deploy" --print
-```
-
-The minted robot token has exactly the role needed to plan, deploy, and destroy (`blueprints-deployer` for project scope, `blueprints-deployer-robot` for organization scope) and is revocable under Robots in Sanity Manage. Store it as a CI secret, then in the pipeline:
-
-```bash
-export SANITY_AUTH_TOKEN=<the minted token>
-export SANITY_ORGANIZATION_ID=<orgId>        # or SANITY_PROJECT_ID
-export SANITY_BLUEPRINT_STACK_ID=<stackId>
-npx sanity@latest blueprints deploy --json --message "CI deploy"
-```
-
-**✅ Correct — secrets via server-side function env vars:**
-
-```bash
-npx sanity@latest functions env add my-function API_KEY sk-...
-```
-
-**❌ Incorrect — secrets in the blueprint file's `env` block, which is committed to git:**
-
-```typescript
-defineDocumentFunction({
-  name: "my-function",
-  env: { API_KEY: "sk-..." }, // committed to version control!
-});
-```

.github/skills/sanity-best-practices/references/functions.md

@@ -1,663 +0,0 @@
----
-title: Sanity Functions
-description: Rules for Sanity Functions — serverless event handlers that react to content changes in Sanity's Content Lake. Covers blueprint configuration, handler patterns, testing, deployment, and recursion control.
----
-
-# Sanity Functions
-
-Serverless event handlers hosted on Sanity's infrastructure, configured via **Blueprints** and triggered by document lifecycle events.
-
-> Always use `npx sanity@latest` so CLI and runtime versions stay current.
-
-## When to use
-
-- Set computed/derived fields (timestamps, slugs, summaries)
-- Enrich or validate content on publish
-- Trigger external services (CDN purge, deploy hooks, notifications)
-- Automate workflows (translation, tagging, cross-posting)
-- Sync content to external systems
-- Invoke Agent Actions in response to content events
-
-## When NOT to use
-
-- Logic needs >900s execution or >200MB bundle — use an external worker
-- High-throughput bulk operations that exceed rate limits (200/fn/30s, 4000/project/30s)
-- A simple POST to an external URL on publish with no document data shaping — use a webhook
-- Client-side or UI-driven logic (validation, conditional fields) — belongs in Studio schema config
-
-## Requirements
-
-| Dependency           | Version                                  |
-| :------------------- | :--------------------------------------- |
-| Node.js              | v24.x (matches deployed runtime)         |
-| Sanity CLI           | v4.12.0+                                 |
-| `@sanity/blueprints` | Latest                                   |
-| `@sanity/functions`  | Latest                                   |
-| `@sanity/client`     | v7.12.0+ (includes recursion protection) |
-
-## Project Structure
-
-Organize functions alongside your Sanity project, one level above the Studio directory:
-
-```
-my-project/
-├── studio/
-├── next-app/
-├── functions/
-│   ├── my-function/
-│   │   ├── index.ts          # Handler code (entry point)
-│   │   └── package.json      # (optional) function-level dependencies
-│   └── another-function/
-│       └── index.ts
-├── sanity.blueprint.ts        # Blueprint configuration
-├── package.json               # Project-level dependencies
-└── node_modules/
-```
-
-The function directory name must match the `name` in the blueprint config. Each function exports a `handler` from its `index.ts` (or `index.js`).
-
----
-
-## Step-by-step: Creating a Function
-
-### 1. Initialize a Blueprint
-
-```bash
-npx sanity@latest blueprints init . \
-  --type ts \
-  --stack-name production \
-  --project-id <your-project-id>
-```
-
-This creates `sanity.blueprint.ts` and `.sanity/blueprint.config.json` (gitignored automatically; it links your Blueprint to a Stack and is not secret).
-
-### 2. Scaffold a Function
-
-```bash
-npx sanity@latest functions add \
-  --name my-function \
-  --type document-create --type document-update \
-  --installer npm
-```
-
-`--type` options: `document-create`, `document-update`, `document-delete`, `media-library-asset-create`, `media-library-asset-update`, `media-library-asset-delete`, `scheduled-function`, `sync-tag-invalidate`.
-
-### 3. Configure the Blueprint
-
-```typescript
-// sanity.blueprint.ts
-import { defineBlueprint, defineDocumentFunction } from "@sanity/blueprints";
-
-export default defineBlueprint({
-  resources: [
-    defineDocumentFunction({
-      name: "my-function",
-      event: {
-        on: ["create", "update"],
-        filter: '_type == "post"',
-      },
-    }),
-  ],
-});
-```
-
-### 4. Write the Handler
-
-```typescript
-// functions/my-function/index.ts
-import { createClient } from "@sanity/client";
-import { documentEventHandler } from "@sanity/functions";
-
-interface PostData {
-  _id: string;
-  _type: string;
-  title: string;
-}
-
-export const handler = documentEventHandler<PostData>(
-  async ({ context, event }) => {
-    const { data } = event;
-
-    const client = createClient({
-      ...context.clientOptions,
-      apiVersion: "2025-05-08",
-    });
-
-    try {
-      await client.patch(data._id, {
-        setIfMissing: { firstPublished: new Date().toISOString() },
-      });
-      console.log(`Set firstPublished on ${data._id}`);
-    } catch (error) {
-      console.error("Failed to patch document:", error);
-    }
-  },
-);
-```
-
-### 5. Test Locally
-
-```bash
-# Visual dev playground
-npx sanity@latest functions dev
-
-# CLI testing
-npx sanity@latest functions test my-function \
-  --dataset production \
-  --with-user-token
-
-# With a specific document
-npx sanity@latest functions test my-function \
-  --document-id abc123 \
-  --dataset production \
-  --with-user-token
-```
-
-### 6. Deploy
-
-```bash
-npx sanity@latest blueprints deploy
-```
-
-### 7. View Logs
-
-```bash
-npx sanity@latest functions logs my-function
-npx sanity@latest functions logs my-function --watch
-```
-
----
-
-## Handler Reference
-
-Every handler receives `{ context, event }`:
-
-### `context`
-
-| Property                  | Type                   | Description                      |
-| :------------------------ | :--------------------- | :------------------------------- |
-| `clientOptions.apiHost`   | `string`               | API host URL                     |
-| `clientOptions.projectId` | `string`               | Sanity project ID                |
-| `clientOptions.dataset`   | `string`               | Dataset name                     |
-| `clientOptions.token`     | `string`               | Robot token (deployed only)      |
-| `local`                   | `boolean \| undefined` | `true` during local testing      |
-| `eventResourceType`       | `string`               | `'dataset'` or `'media-library'` |
-| `eventResourceId`         | `string`               | e.g., `'projectId.datasetName'`  |
-
-### `event`
-
-```typescript
-{
-  data: {
-    _id: string;
-    _type: string;
-    // ... rest of document (shaped by projection if set)
-  }
-}
-```
-
-When testing locally, `context.clientOptions` only has `projectId` and `apiHost`. Use `--dataset` and `--with-user-token` flags to supply the rest.
-
----
-
-## Blueprint Configuration
-
-### `defineDocumentFunction` Options
-
-| Option        | Type                     | Default            | Description                                      |
-| :------------ | :----------------------- | :----------------- | :----------------------------------------------- |
-| `name`        | `string`                 | required           | Must match the directory name under `functions/` |
-| `displayName` | `string`                 | —                  | Human-readable display name                      |
-| `src`         | `string`                 | `functions/<name>` | Path to function source directory                |
-| `memory`      | `number`                 | `1`                | Memory in GB (max 10)                            |
-| `timeout`     | `number`                 | `10`               | Timeout in seconds (max 900)                     |
-| `runtime`     | `string`                 | `'nodejs24.x'`     | `'node'`, `'nodejs22.x'`, or `'nodejs24.x'`      |
-| `project`     | `string`                 | —                  | Project ID. Required if blueprint is org-scoped. |
-| `robotToken`  | `string`                 | —                  | Custom robot token name for the function         |
-| `event`       | `object`                 | required           | Event configuration (see below)                  |
-| `env`         | `Record<string, string>` | —                  | Environment variables via `process.env`          |
-
-### `event` Options
-
-| Option               | Type       | Default  | Description                                                          |
-| :------------------- | :--------- | :------- | :------------------------------------------------------------------- |
-| `on`                 | `string[]` | required | `'create'`, `'update'`, `'delete'`                                   |
-| `filter`             | `string`   | —        | GROQ filter body (no `*[...]` wrapper)                               |
-| `projection`         | `string`   | —        | GROQ projection to shape `event.data`. Wrap in `{}`.                 |
-| `includeDrafts`      | `boolean`  | `false`  | Trigger on draft changes                                             |
-| `includeAllVersions` | `boolean`  | `false`  | Trigger on all document versions                                     |
-| `resource`           | `object`   | —        | Scope to dataset: `{ type: 'dataset', id: 'projectId.datasetName' }` |
-
-### `defineMediaLibraryAssetFunction`
-
-For Media Library asset events. Requires `@sanity/blueprints` v0.4.0+ and `@sanity/functions` v1.1.0+.
-
-```typescript
-import {
-  defineBlueprint,
-  defineMediaLibraryAssetFunction,
-} from "@sanity/blueprints";
-
-export default defineBlueprint({
-  resources: [
-    defineMediaLibraryAssetFunction({
-      name: "asset-handler",
-      event: {
-        on: ["delete"],
-        filter: "documents::incomingGlobalDocumentReferenceCount() > 0",
-        projection: "{_id, versions, title}",
-        resource: {
-          type: "media-library",
-          id: "mlYourLibraryId",
-        },
-      },
-    }),
-  ],
-});
-```
-
----
-
-## Event Types
-
-| Event    | Description                                                                              |
-| :------- | :--------------------------------------------------------------------------------------- |
-| `create` | New document created                                                                     |
-| `update` | Existing document modified (for published docs, fires when a draft/version is published) |
-| `delete` | Document deleted                                                                         |
-
-Often best to use `['create', 'update']` together for published document triggers.
-
----
-
-## GROQ Filter Tips
-
-- Only the filter body — `_type == 'post'`, not `*[_type == 'post']`
-- `delta::changedAny(fieldName)` — trigger only when specific fields change
-- `sanity::dataset() == 'production'` — scope to a dataset without `resource` config
-- `_id in path('drafts.**')` with `includeDrafts: true` — draft-only triggers
-- Combine conditions to prevent recursion: `_type == 'post' && !defined(processedAt)`
-
----
-
-## Projections
-
-- Shape the data passed to `event.data`
-- Limited to the invoking document's scope (plus `→` for references)
-- Nested filters in projections (like `*[references(^._id)]`) will fail silently — query inside the function instead
-- Wrap in `{}`: `projection: '{title, _id, slug}'`
-
----
-
-## Environment Variables
-
-Three ways to set them:
-
-1. Blueprint config: `env: { MY_VAR: 'value' }`
-2. CLI: `npx sanity@latest functions env add my-function MY_VAR my-value`
-3. Local testing: `MY_VAR=value npx sanity functions test my-function`
-
-Access in handler code via `process.env.MY_VAR`.
-
----
-
-## Critical Rules
-
-### Preventing Recursion
-
-If your function mutates the same document type it listens to, you **will** create an infinite loop.
-
-**✅ Correct — use GROQ filters to exclude processed documents:**
-
-```typescript
-defineDocumentFunction({
-  name: "first-published",
-  event: {
-    on: ["create", "update"],
-    filter: "_type == 'post' && !defined(firstPublished)",
-  },
-});
-```
-
-**✅ Correct — use `@sanity/client` v7.12.0+ for automatic lineage headers:**
-
-```typescript
-import { createClient } from "@sanity/client";
-
-// Client automatically sets X-Sanity-Lineage header
-// Recursive chains are limited to 16 invocations
-const client = createClient({
-  ...context.clientOptions,
-  apiVersion: "2025-05-08",
-});
-```
-
-**❌ Incorrect — no recursion guard:**
-
-```typescript
-defineDocumentFunction({
-  name: "update-post",
-  event: {
-    on: ["create", "update"],
-    filter: "_type == 'post'", // Will re-trigger on its own writes!
-  },
-});
-```
-
-### Local Testing Safety
-
-Use `context.local` to prevent accidental mutations during testing:
-
-```typescript
-// Skip mutations entirely in test
-if (!context.local) {
-  await client.createOrReplace(someDoc);
-}
-
-// Or use dryRun
-await client
-  .patch(event.data._id, {
-    set: { processed: true },
-  })
-  .commit({ dryRun: context.local });
-
-// Or use noWrite for Agent Actions
-await client.agent.action.generate({
-  schemaId: "your-schema-id",
-  documentId: event.data._id,
-  instruction: "Summarize this document",
-  target: { path: ["summary"] },
-  noWrite: context.local,
-});
-```
-
-### Limits
-
-- Max bundle size: 200MB (including dependencies). Prefer slim, platform-agnostic packages.
-- Rate limits: 200 invocations/fn/30s, 4000/project/30s
-- Max timeout: 900s. Larger functions = slower cold starts.
-
-### Cost
-
-Cost = invocations × (memory GB × duration seconds). Default is 1GB memory. A function averaging 1GB and 40ms duration can run ~500k invocations within 20K GB-seconds. [Monitor usage at the organization level](https://www.sanity.io/manage).
-
----
-
-## Common Patterns
-
-### Deploy hook / CDN invalidation
-
-**Blueprint:**
-
-```typescript
-defineDocumentFunction({
-  name: "deploy-hook",
-  event: {
-    on: ["create", "update"],
-    filter: '_type == "page"',
-  },
-});
-```
-
-**Handler:**
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const URL = process.env.DEPLOY_HOOK_URL;
-  if (!URL) throw new Error("DEPLOY_HOOK_URL is not set");
-
-  await fetch(URL);
-  console.log("Deploy hook triggered");
-});
-```
-
-Set the env var: `npx sanity@latest functions env add deploy-hook DEPLOY_HOOK_URL https://...`
-
-### Set a timestamp on first publish
-
-Uses the same pattern as the step-by-step example above. The key insight: the `!defined(firstPublished)` GROQ filter prevents re-triggering after the field is set. The `setIfMissing` patch is a redundant safety net.
-
-```typescript
-defineDocumentFunction({
-  name: "first-published",
-  event: {
-    on: ["create", "update"],
-    filter: '_type == "post" && !defined(firstPublished)',
-  },
-});
-```
-
-### Auto-translate with Agent Actions
-
-**Blueprint:**
-
-```typescript
-defineDocumentFunction({
-  name: "translate",
-  event: {
-    on: ["create", "update"],
-    filter: "_type == 'post' && language == 'en-US'",
-    projection: "{_id}",
-  },
-});
-```
-
-**Handler:**
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const client = createClient({ ...context.clientOptions, apiVersion: "vX" });
-
-  await client.agent.action.translate({
-    schemaId: "your-schema-id",
-    async: true,
-    documentId: event.data._id,
-    languageFieldPath: "language",
-    targetDocument: {
-      operation: "create",
-    },
-    fromLanguage: { id: "en-US", title: "English" },
-    toLanguage: { id: "el-GR", title: "Greek" },
-  });
-});
-```
-
-The GROQ filter ensures only English documents trigger the function. The translated document gets a different `language` value, preventing recursive triggers.
-
-Let Sanity assign the translated document's `_id` for ordinary localized content. To find or update translations later, query by language, slug, or translation metadata instead of deriving IDs from the source document. Reserve explicit `targetDocument._id` values for singleton-style targets.
-
-### Auto-tag with Agent Actions
-
-**Blueprint:**
-
-```typescript
-defineDocumentFunction({
-  name: "auto-tag",
-  event: {
-    on: ["create", "update"],
-    filter: "_type == 'post'",
-    projection: "{_id, title, body}",
-  },
-});
-```
-
-**Handler:**
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const client = createClient({ ...context.clientOptions, apiVersion: "vX" });
-
-  await client.agent.action.generate({
-    schemaId: "your-schema-id",
-    documentId: event.data._id,
-    instruction:
-      "Analyze the content and generate 3 relevant tags. Reuse existing tags when possible.",
-    target: { path: ["tags"] },
-    async: true,
-  });
-});
-```
-
-### Slack notification on publish
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const WEBHOOK_URL = process.env.SLACK_WEBHOOK_URL;
-  if (!WEBHOOK_URL) throw new Error("SLACK_WEBHOOK_URL not set");
-
-  await fetch(WEBHOOK_URL, {
-    method: "POST",
-    headers: { "Content-Type": "application/json" },
-    body: JSON.stringify({
-      text: `📝 New content published: *${event.data.title || event.data._id}* (${event.data._type})`,
-    }),
-  });
-});
-```
-
-### Scope to a specific dataset
-
-**Option A — `resource` config:**
-
-```typescript
-defineDocumentFunction({
-  name: "production-only",
-  event: {
-    on: ["update"],
-    filter: "_type == 'post'",
-    resource: { type: "dataset", id: "myProjectId.production" },
-  },
-});
-```
-
-**Option B — GROQ filter:**
-
-```typescript
-defineDocumentFunction({
-  name: "production-only",
-  event: {
-    on: ["update"],
-    filter: "_type == 'post' && sanity::dataset() == 'production'",
-  },
-});
-```
-
-### React to Media Library asset changes
-
-Requires `@sanity/blueprints` v0.4.0+ and `@sanity/functions` v1.1.0+.
-
-**Blueprint:**
-
-```typescript
-import {
-  defineBlueprint,
-  defineMediaLibraryAssetFunction,
-} from "@sanity/blueprints";
-
-export default defineBlueprint({
-  resources: [
-    defineMediaLibraryAssetFunction({
-      name: "asset-deleted",
-      event: {
-        on: ["delete"],
-        filter: "documents::incomingGlobalDocumentReferenceCount() > 0",
-        projection: "{_id, versions, title}",
-        resource: { type: "media-library", id: "mlYourLibraryId" },
-      },
-    }),
-  ],
-});
-```
-
-**Handler:**
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const { eventResourceId } = context; // Media Library ID
-  const client = createClient({
-    ...context.clientOptions,
-    apiVersion: "2025-05-08",
-  });
-
-  const response = await client.request({
-    uri: `/media-libraries/${eventResourceId}/query`,
-    method: "POST",
-    body: { query: `*[_type == 'sanity.imageAsset']` },
-  });
-
-  console.log("Assets:", response);
-});
-```
-
-### Recursion control with custom HTTP clients
-
-If not using `@sanity/client`, implement lineage tracking manually:
-
-```typescript
-export const handler = documentEventHandler(async ({ context, event }) => {
-  const lineage = process.env.X_SANITY_LINEAGE;
-
-  await fetch(
-    `https://${context.clientOptions.projectId}.api.sanity.io/v2025-05-08/data/mutate/production`,
-    {
-      method: "POST",
-      headers: {
-        "Content-Type": "application/json",
-        Authorization: `Bearer ${context.clientOptions.token}`,
-        ...(lineage ? { "X-Sanity-Lineage": lineage } : {}),
-      },
-      body: JSON.stringify({
-        mutations: [
-          { patch: { id: event.data._id, set: { processed: true } } },
-        ],
-      }),
-    },
-  );
-});
-```
-
-### Multiple functions in one blueprint
-
-```typescript
-export default defineBlueprint({
-  resources: [
-    defineDocumentFunction({
-      name: "first-published",
-      event: {
-        on: ["create", "update"],
-        filter: "_type == 'post' && !defined(firstPublished)",
-      },
-    }),
-    defineDocumentFunction({
-      name: "notify-slack",
-      event: {
-        on: ["create", "update"],
-        filter: "_type == 'post'",
-        projection: "{title, _id}",
-      },
-    }),
-    defineDocumentFunction({
-      name: "sync-algolia",
-      timeout: 30,
-      event: {
-        on: ["create", "update", "delete"],
-        filter: "_type == 'product'",
-      },
-    }),
-  ],
-});
-```
-
----
-
-## CI/CD Deployment
-
-Use the [Blueprints GitHub Action](https://github.com/sanity-io/blueprints-actions)
-
-```yaml
-- uses: sanity-io/blueprints-actions/deploy@deploy-v3
-  with:
-    sanity-token: ${{ secrets.SANITY_DEPLOY_TOKEN }}
-```
-
-Mint a long-lived deploy token with `npx sanity@latest blueprints mint-deploy-token` (creates a robot token with the role required to plan, deploy, and destroy) and store it as a CI secret. Recommended workflow: `blueprints plan` on pull requests, `blueprints deploy` on merge to main. See the `blueprints` reference for CI environment variables and exit codes.

.github/skills/sanity-best-practices/references/get-started.md

@@ -1,425 +0,0 @@
----
-title: Sanity Getting Started Guide
-description: Use these rules when users ask to 'Get started with Sanity' or need help setting up a new Sanity project.
----
-
-# Sanity Getting Started Guide
-
-## Overview
-
-Getting started with Sanity follows three phases:
-
-1. **Studio & Schema** — Set up Sanity Studio and define your content model
-2. **Content** — Import existing content or generate placeholder content via MCP
-3. **Frontend** — Integrate with your application (framework-specific)
-
-## Communication Style
-
-**Keep responses succinct:**
-
-- Tell the user what you did: "Created post schema with title, body, and slug"
-- Ask direct questions: "What kind of content are you building?"
-- Avoid verbose explanations of what you're about to do
-- Don't explain every step unless the user asks
-
-**Examples:**
-
-- **Good**: "Schema deployed. Ready to add some content?"
-- **Bad**: "I'm going to deploy your schema to the Content Lake so that the MCP server can recognize your new document types. This will allow..."
-
----
-
-## Get Started with Sanity (Interactive Guide)
-
-**TRIGGER PHRASE:** When the user says "Get started with Sanity" or similar, follow these steps.
-
-**Before starting:** Let the user know they can pause and resume anytime by saying "Continue Sanity setup".
-
-**RESUME TRIGGER:** If the user says "Continue Sanity setup", check what's already configured:
-
-- Does `sanity.config.ts` exist (typically in a `studio/` folder)? → Studio is set up
-- Are there files in `schemaTypes/`? → Schema exists
-- Is there a frontend framework in `package.json`? → May need integration
-
-Resume from where they left off.
-
----
-
-## Phase 1: Studio & Schema
-
-### Step 1: Check for Existing Studio
-
-**Look for `sanity.config.ts` or `sanity.cli.ts` across the workspace** — in the recommended side-by-side layout the Studio lives in its own folder (`studio/`, or `studio-*` when created by the Sanity onboarding flow) next to the app folder:
-
-**If NO Studio found:**
-
-- Ask: "Want to create a new Sanity Studio?"
-- If yes, run from the repo root — **not inside a Next.js app folder**, where the CLI would switch to its embedded flow (not recommended):
-  ```bash
-  npm create sanity@latest -- --template clean --typescript --output-path studio
-  ```
-- This creates a standalone Studio in `studio/`, alongside your app folder (see `project-structure.md`)
-
-**If Studio exists:**
-
-- Read the config to get `projectId` and `dataset`
-- Proceed to Step 2
-
-### Step 2: Check for Existing Schema
-
-**Look in `schemaTypes/`, `schemas/`, or `src/sanity/schemaTypes/`:**
-
-**If NO schema found:**
-
-- Ask: "What kind of content are you building? (e.g., Blog, E-commerce, Portfolio)"
-- Create appropriate schema types based on their answer
-- See `schema.md` for patterns
-
-**If schema exists:**
-
-- Show them what you found
-- Ask: "Want to add more content types or modify existing ones?"
-
-**If they want a quick example:**
-Create a basic blog schema:
-
-```typescript
-// schemaTypes/post.ts
-import { defineField, defineType } from "sanity";
-
-export const post = defineType({
-  name: "post",
-  title: "Post",
-  type: "document",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "slug", type: "slug", options: { source: "title" } }),
-    defineField({ name: "body", type: "array", of: [{ type: "block" }] }),
-  ],
-});
-```
-
-### Step 3: Deploy Schema
-
-**Required before Phase 2:**
-
-```bash
-npx sanity schema deploy
-```
-
-This uploads your schema to the Content Lake so MCP tools can work with it.
-
----
-
-## Phase 2: Content
-
-### Step 1: Check for Existing Content
-
-**Use MCP `query_documents` to check:**
-
-```
-*[_type == "post"][0...5]
-```
-
-**If content exists:**
-
-- Show them a summary
-- Ask: "Want to add more content or move to frontend integration?"
-
-**If NO content:**
-
-- Ask: "Do you want to:
-  1. Import existing content (from another CMS, markdown, etc.)
-  2. Generate sample content with AI
-  3. Skip this and add content manually in the Studio"
-
-### Step 2a: Import Existing Content
-
-If migrating from another CMS or files:
-
-- See `migration.md` and the `sanity-migration` skill for guidance
-- Use MCP content tools such as `create_documents` and `patch_documents` after converting content to structured Sanity documents
-
-### Step 2b: Generate Sample Content (MCP)
-
-Ask the agent to draft structured sample content, then create it with the Sanity MCP Server:
-
-```
-Tool: create_documents
-Documents: [{ type: "post", content: { title: "Getting started with Sanity", body: [] } }]
-```
-
-**If MCP content tools cannot see new types or fields:** Remind them to run `npx sanity schema deploy` first.
-
-### MCP Setup (If Not Configured)
-
-**Quick start via Sanity CLI:**
-
-```bash
-npx sanity@latest mcp configure
-```
-
-**Cursor:** [One-click install →](cursor://anysphere.cursor-deeplink/mcp/install?name=Sanity&config=eyJ1cmwiOiJodHRwczovL21jcC5zYW5pdHkuaW8iLCJ0eXBlIjoiaHR0cCJ9Cg==)
-
-Or add to `.cursor/mcp.json`:
-
-```json
-{
-  "mcpServers": {
-    "Sanity": {
-      "type": "http",
-      "url": "https://mcp.sanity.io"
-    }
-  }
-}
-```
-
-**Claude Code:**
-
-```bash
-claude mcp add Sanity -t http https://mcp.sanity.io --scope user
-```
-
-**VS Code:** Command Palette → `MCP: Open User Configuration` → add:
-
-```json
-{
-  "servers": {
-    "Sanity": {
-      "type": "http",
-      "url": "https://mcp.sanity.io"
-    }
-  }
-}
-```
-
----
-
-## Phase 3: Frontend Integration
-
-### Client Bundle Warning (Vite-based frameworks)
-
-React Router, SvelteKit, Astro, and Nuxt all run on Vite. **Any module imported by a client component will be bundled to the browser.** `process.env` doesn't exist there.
-
-For publishable values (`projectId`, `dataset`, `apiVersion`, public studio URL), use the framework's client-safe env mechanism:
-
-- React Router / Remix: `import.meta.env.VITE_*`
-- SvelteKit: `$env/static/public`
-- Astro: `import.meta.env.PUBLIC_*`
-- Nuxt: `useRuntimeConfig().public`
-
-For secrets (read tokens, webhook secrets), read `process.env.*` (or the server equivalent) **only from server-only modules** — `.server.ts`, route handlers, API endpoints. Don't centralize them in a shared `env.ts` that anything else imports.
-
-This trap is invisible at SSR — the page renders fine on first load. It surfaces on client-side route transitions, when a lazy-loaded route chunk pulls a shared client/image module into the browser.
-
-### Step 1: Find the App and Detect Framework
-
-The working directory is often a parent folder with the Studio and the app side by side. Identify the app folder first: a sibling of the Studio folder with its own `package.json` (commonly `web/`). If several candidates exist, ask the user which app to integrate — never assume.
-
-**Check the app's `package.json` dependencies:**
-
-| Dependency                           | Framework            | Rule File   |
-| ------------------------------------ | -------------------- | ----------- |
-| `next`                               | Next.js              | `nextjs.md` |
-| `@remix-run/react` or `react-router` | React Router / Remix | `remix.md`  |
-| `svelte` or `@sveltejs/kit`          | SvelteKit            | `svelte.md` |
-| `nuxt`                               | Nuxt                 | `nuxt.md`   |
-| `astro`                              | Astro                | `astro.md`  |
-
-**If NO framework found:**
-
-- Ask: "Which framework are you using, or would you like to create a new app?"
-- Guide them to create one or specify their choice
-
-### Step 2: Next.js Integration (Inline)
-
-If Next.js is detected, follow these essential steps:
-
-**Scaffold a new app (if you don't have one yet):**
-
-Run from the repo root so the app sits alongside your `studio/` folder:
-
-```bash
-npx create-next-app@latest web --tailwind --ts --app --src-dir --eslint --import-alias "@/*" --turbopack
-cd web
-```
-
-**Install dependencies:**
-
-```bash
-npm install next-sanity @sanity/image-url
-```
-
-`next-sanity` is the official Sanity toolkit for Next.js. It bundles `@sanity/client`, `groq` (with `defineQuery`), and `@portabletext/react`, plus dedicated subpath exports for Next.js-specific features:
-
-- `next-sanity` — `createClient`, `defineQuery`, `PortableText`, `SanityDocument`, `stegaClean`
-- `next-sanity/live` — `defineLive` for live content with Next.js cache integration
-- `next-sanity/draft-mode` — Draft Mode endpoint helpers
-- `next-sanity/visual-editing` — `<VisualEditing />` component for click-to-edit overlays
-- `next-sanity/image` — Sanity-aware `<Image />` wrapping `next/image`
-- `next-sanity/studio` — embed the Sanity Studio at a route (legacy setups only — keep the Studio standalone, see `nextjs.md`)
-- `next-sanity/webhook` — webhook signature verification
-
-Don't also install `@sanity/client`, `@portabletext/react`, or `groq` directly — import them from `next-sanity`. `@sanity/image-url` is not bundled (yet), so add it separately.
-
-**Create the client (`src/sanity/client.ts`):**
-
-```typescript
-import { createClient } from "next-sanity";
-
-export const client = createClient({
-  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID!,
-  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET!,
-  apiVersion: "2026-05-15", // Use current date for new projects
-  useCdn: false, // Use API directly for server-side rendering; set true for client-side reads
-});
-```
-
-**Fetch content in a Server Component:**
-
-```typescript
-// src/app/page.tsx
-import { client } from "@/sanity/client";
-import { defineQuery, type SanityDocument } from "next-sanity";
-
-const POSTS_QUERY = defineQuery(
-  `*[_type == "post" && defined(slug.current)] | order(_createdAt desc){ _id, title, slug }`
-);
-
-const options = { next: { revalidate: 30 } };
-
-export default async function PostsPage() {
-  const posts = await client.fetch<SanityDocument[]>(POSTS_QUERY, {}, options);
-
-  return (
-    <ul>
-      {posts.map((post) => (
-        <li key={post._id}>
-          <a href={`/${(post.slug as { current?: string })?.current}`}>{post.title as string}</a>
-        </li>
-      ))}
-    </ul>
-  );
-}
-```
-
-`{ next: { revalidate: 30 } }` opts the fetch into Next.js' ISR cache with a 30-second revalidation window. Tune to taste; omit `options` to use defaults.
-
-**Render an individual post (`src/app/[slug]/page.tsx`):**
-
-```typescript
-import { PortableText, defineQuery, type SanityDocument } from "next-sanity";
-import { notFound } from "next/navigation";
-import { client } from "@/sanity/client";
-
-const POST_QUERY = defineQuery(
-  `*[_type == "post" && slug.current == $slug][0]{ _id, title, body }`
-);
-
-const options = { next: { revalidate: 30 } };
-
-export default async function PostPage({
-  params,
-}: {
-  params: Promise<{ slug: string }>;
-}) {
-  const { slug } = await params;
-  const post = await client.fetch<SanityDocument | null>(POST_QUERY, { slug }, options);
-
-  if (!post) return notFound();
-
-  return (
-    <article>
-      <h1>{post.title as string}</h1>
-      {Array.isArray(post.body) && <PortableText value={post.body} />}
-    </article>
-  );
-}
-```
-
-**Add environment variables (`.env.local`):**
-
-```
-NEXT_PUBLIC_SANITY_PROJECT_ID=your-project-id
-NEXT_PUBLIC_SANITY_DATASET=production
-```
-
-For advanced patterns (TypeGen, Visual Editing with `next-sanity/visual-editing`, live content with `defineLive` from `next-sanity/live`, standalone Studio architecture), see `nextjs.md`.
-
-### Step 3: Other Frameworks
-
-For non-Next.js frameworks, read the corresponding rule file and follow its integration guide:
-
-- **React Router / Remix:** `remix.md`
-- **SvelteKit:** `svelte.md`
-- **Nuxt:** `nuxt.md`
-- **Astro:** `astro.md`
-
-Each rule file contains framework-specific patterns for data fetching, Portable Text rendering, and Visual Editing.
-
-### Step 4: Smoke Test
-
-Before declaring integration done, exercise both render paths:
-
-1. `npm run dev` (in the app folder)
-2. Load the home page (lists posts).
-3. **Click through to a detail page** via an in-app `<Link>` / `<a>` — do not paste the URL.
-4. Open the browser console. It should be clean. No `ReferenceError: process is not defined`, no hard reload to `/`.
-5. For good measure, reload the detail page directly (URL bar) — that exercises SSR.
-
-Server-side rendering passing isn't enough. Client-side route transitions pull lazy chunks that exercise different code paths, and that's where env/bundling traps surface.
-
----
-
-## What's Next
-
-Once setup is complete, let the user know:
-
-"You're all set! Here are some things I can help with:
-
-- **Visual Editing** — Click-to-edit in the Presentation tool (`visual-editing.md`)
-- **TypeGen** — Type-safe queries with generated types (`typegen.md`)
-- **Studio Structure** — Customize the Studio sidebar (`studio-structure.md`)
-- **SEO** — Metadata, sitemaps, and Open Graph (`seo.md`)
-- **i18n** — Multi-language content (`localization.md`)
-
-Just ask about any of these!"
-
----
-
-## Environment Variables
-
-### Framework-Specific Prefixes
-
-| Framework            | Client-Side Prefix | Example                         |
-| -------------------- | ------------------ | ------------------------------- |
-| Next.js              | `NEXT_PUBLIC_`     | `NEXT_PUBLIC_SANITY_PROJECT_ID` |
-| React Router / Remix | `VITE_`            | `VITE_SANITY_PROJECT_ID`        |
-| SvelteKit            | `PUBLIC_`          | `PUBLIC_SANITY_PROJECT_ID`      |
-| Nuxt                 | `NUXT_PUBLIC_`     | `NUXT_PUBLIC_SANITY_PROJECT_ID` |
-| Astro                | `PUBLIC_`          | `PUBLIC_SANITY_PROJECT_ID`      |
-
-**Secrets** (read tokens, webhook secrets) stay **unprefixed** and are read via `process.env` (or the framework's server-only equivalent) from server-only modules — `*.server.ts`, route handlers, API routes. Never re-export a secret from a module that a route component can import.
-
----
-
-## Common Commands
-
-```bash
-npx sanity@latest mcp configure  # Configure MCP for your editor
-npx sanity dev                   # Start Studio locally
-npx sanity schema deploy         # Deploy schema for MCP/editor access
-npx sanity deploy                # Deploy Studio to Sanity hosting
-npx sanity manage                # Open project settings
-npm run typegen                  # Generate TypeScript types
-```
-
----
-
-## Important Notes
-
-- **Be succinct** — Guide step-by-step without over-explaining
-- **Check context first** — Read existing files before suggesting changes
-- **Don't give up** — If something fails, give the user a way to complete manually
-- **Deploy schema early** — MCP content tools need deployed schemas to see new types and fields
-- **One phase at a time** — Complete each phase before moving to the next

.github/skills/sanity-best-practices/references/groq.md

@@ -1,373 +0,0 @@
----
-title: GROQ Query Maintenance & Best Practices
-description: Guidelines for GROQ queries, type safety, performance optimization, and syntax highlighting.
----
-
-# GROQ Query Maintenance & Best Practices
-
-Use this contents list to jump to the query concern you need to solve.
-
-## Table of Contents
-
-- Query definition and imports
-- Query fragments
-- Expansion patterns
-- Maintenance workflow
-- Common patterns
-- Performance rules
-- API version best practices
-
-## 1. Query Definition & Imports
-
-### The `defineQuery` Function
-
-**ALWAYS** wrap GROQ queries in `defineQuery` for TypeGen support. The import location depends on your framework:
-
-```typescript
-// Framework-agnostic (Angular, Remix, SvelteKit, Astro, vanilla)
-import { defineQuery } from "groq";
-
-// Next.js (re-exported for convenience)
-import { defineQuery } from "next-sanity";
-```
-
-### Syntax Highlighting
-
-For VS Code syntax highlighting, either:
-
-1. Use the `groq` tagged template (recommended): `groq\`...\``
-2. Or prefix with `/* groq */` comment when using `defineQuery`
-
-```typescript
-import { defineQuery } from "groq";
-
-// ✅ Option A: groq tag (provides highlighting automatically)
-import groq from "groq";
-const QUERY = defineQuery(groq`*[_type == "post"]`);
-
-// ✅ Option B: Comment prefix (for plain template literals)
-const QUERY = defineQuery(/* groq */ `*[_type == "post"]`);
-
-// ✅ Also valid: Just defineQuery (TypeGen works, but no editor highlighting)
-const QUERY = defineQuery(`*[_type == "post"]`);
-```
-
-## 2. Query Fragments
-
-Use string interpolation to reuse query logic and keep queries maintainable.
-
-```typescript
-// src/sanity/fragments/image.ts
-export const imageFragment = /* groq */ `
-  asset->{
-    _id,
-    url,
-    metadata { lqip, dimensions }
-  },
-  alt
-`;
-
-// src/sanity/queries/post.ts
-import { defineQuery } from "groq";
-import { imageFragment } from "../fragments/image";
-
-export const POST_QUERY = defineQuery(/* groq */ `
-  *[_type == "post"][0] {
-    title,
-    mainImage {
-      ${imageFragment}
-    }
-  }
-`);
-```
-
-## 3. Expansion Patterns (Page Builder)
-
-When building a Page Builder query, expand all potential component types.
-
-**Best Practice:** Use a `pageFields` fragment or similar strategy to keep the main query clean.
-
-```typescript
-const pageBuilderExpansion = /* groq */ `
-  pageBuilder[] {
-    ...,
-    _type == "hero" => {
-      ...,
-      cta[] { link, label }
-    },
-    _type == "gallery" => {
-      images[] { ${imageFragment} }
-    }
-  }
-`;
-```
-
-## 4. Maintenance Workflow
-
-When you add a new field or component to the Schema:
-
-1.  **Update the Query:** Add the new field/expansion to the relevant GROQ query immediately.
-2.  **Run TypeGen:** If you have `typegen.enabled: true` in `sanity.cli.ts`, types regenerate automatically during `sanity dev`/`sanity build`. Otherwise, run `npm run typegen` manually.
-3.  **Verify:** Ensure the new field is available in the generated types.
-
-## 5. Common Patterns
-
-### Ordering
-
-```groq
-// Single field
-*[_type == "post"] | order(publishedAt desc)
-
-// Multiple fields (tiebreaker)
-*[_type == "post"] | order(featured desc, publishedAt desc)
-
-// ⚠️ Order BEFORE slice, not after!
-*[_type == "post"] | order(publishedAt desc)[0...10]  // ✅ Correct
-*[_type == "post"][0...10] | order(publishedAt desc)  // ❌ Wrong order
-```
-
-### Slice Notation
-
-```groq
-*[_type == "post"][0]       // Single document (object, not array)
-*[_type == "post"][0...5]   // First 5 (exclusive) ← Most common
-*[_type == "post"][$start...$end]  // Pagination with params
-```
-
-### Default Values with `coalesce()`
-
-```groq
-*[_type == "page"]{
-  "title": coalesce(seoTitle, title, "Untitled"),
-  "image": coalesce(ogImage, mainImage, defaultImage)
-}
-```
-
-### Conditionals with `select()`
-
-```groq
-*[_type == "product"]{
-  title,
-  "badge": select(
-    stock == 0 => "Out of Stock",
-    stock < 5 => "Low Stock",
-    "In Stock"
-  )
-}
-```
-
-### Aggregation with `count()`
-
-```groq
-// Total count
-count(*[_type == "post" && defined(slug.current)])
-
-// Count per document
-*[_type == "category"]{
-  title,
-  "postCount": count(*[_type == "post" && references(^._id)])
-}
-```
-
-### Reverse References
-
-```groq
-*[_type == "author"]{
-  name,
-  "posts": *[_type == "post" && references(^._id)]{ title, slug }
-}
-```
-
-### Array Filtering
-
-```groq
-*[_type == "movie"]{
-  title,
-  "mainCast": castMembers[role == "lead"]->{name}
-}
-
-// Check if value exists in array
-*[_type == "post" && "tech" in categories[]->slug.current]
-```
-
-### Special Variables
-
-```groq
-// ^ = parent document (in nested queries)
-*[_type == "author"]{
-  name,
-  "posts": *[_type == "post" && author._ref == ^._id]
-}
-
-// @ = current item (in array operations)
-*[_type == "post"]{
-  "tagCount": count(tags[@ != null])
-}
-```
-
-## 6. Performance Rules
-
-### Optimizable vs Non-Optimizable Filters
-
-GROQ uses indexes for **optimizable** filters. Non-optimizable filters scan ALL documents.
-
-| Pattern                 | Optimizable | Example                          |
-| ----------------------- | ----------- | -------------------------------- |
-| `_type == "x"`          | ✅ Yes      | `*[_type == "post"]`             |
-| `_id == "x"`            | ✅ Yes      | `*[_id == "abc123"]`             |
-| `slug.current == $slug` | ✅ Yes      | `*[slug.current == "hello"]`     |
-| `defined(field)`        | ✅ Yes      | `*[defined(publishedAt)]`        |
-| `references($id)`       | ✅ Yes      | `*[references("author-123")]`    |
-| `field->attr == x`      | ❌ No       | Resolves reference for every doc |
-| `fieldA < fieldB`       | ❌ No       | Compares two attributes          |
-
-**Fix non-optimizable filters by stacking:**
-
-```groq
-// Stack optimizable filters FIRST to reduce search space
-*[_type == "product" && defined(salePrice) && salePrice < displayPrice]
-```
-
-### Avoid Joins in Filters
-
-Reference resolution (`->`) in filters is expensive. Use `_ref` instead:
-
-```groq
-// ❌ Slow: Resolves reference for every document
-*[_type == "post" && author->name == "Bob Woodward"]
-
-// ✅ Fast: Direct _ref comparison
-*[_type == "post" && author._ref == "author-bob-woodward-id"]
-```
-
-**When you need dynamic lookups** (don't know the ID upfront):
-
-```groq
-// Two-step approach:
-// 1. Get the reference ID first
-*[_type == "author" && name == "Bob Woodward"][0]._id
-
-// 2. Use that ID in your main query
-*[_type == "post" && author._ref == $authorId]
-
-// Or use a subquery (still better than -> in filter):
-*[_type == "post" && author._ref in *[_type == "author" && name == "Bob Woodward"]._id]
-```
-
-### Merge Repeated Reference Resolutions
-
-Each `->` is a subquery. Don't repeat it:
-
-```groq
-// ❌ Slow: Two separate subqueries
-*[_type == "category"]{
-  "parentTitle": parent->title,
-  "parentSlug": parent->slug.current
-}
-
-// ✅ Fast: Single subquery, merged
-*[_type == "category"]{
-  ...(parent->{ "parentTitle": title, "parentSlug": slug.current })
-}
-```
-
-### Cursor-Based Pagination (Not Deep Slicing)
-
-Deep slices are slow because all skipped docs must be sorted first.
-
-```groq
-// ❌ Slow: Must sort and skip 10,000 docs
-*[_type == "article"] | order(_id)[10000...10020]
-
-// ✅ Fast: Cursor-based, only fetches 20
-*[_type == "article" && _id > $lastId] | order(_id)[0...20]
-```
-
-**For custom sort orders**, include the sort field in the cursor:
-
-```groq
-// Compound cursor: publishedAt + _id for deterministic pagination
-*[_type == "article" && (
-  publishedAt < $lastDate ||
-  (publishedAt == $lastDate && _id > $lastId)
-)] | order(publishedAt desc, _id)[0...20]
-```
-
-### Always Project Fields
-
-Always use projections to return only the fields your application needs. Fetching entire documents wastes bandwidth and processing time.
-
-```groq
-// ❌ Returns ALL fields including unused ones, metadata, revisions
-*[_type == "post"]
-
-// ✅ Only fetch what the component needs
-*[_type == "post"]{
-  _id,
-  title,
-  "slug": slug.current,
-  publishedAt,
-  excerpt
-}
-```
-
-Apply projections at every level, including nested references:
-
-```groq
-*[_type == "post"]{
-  title,
-  author->{ name, "avatar": image.asset->url },
-  categories[]->{ title, "slug": slug.current }
-}
-```
-
-Use conditional projections for different contexts:
-
-```groq
-*[_type == "post"]{
-  title,
-  slug,
-  // Only include body for single post view
-  $includeBody == true => { body }
-}
-```
-
-### Don't Filter/Sort on Projected Values
-
-Computed attributes can't use indexes:
-
-```groq
-// ❌ Not optimizable (computed attribute)
-*[_type == "person"]{
-  "fullName": firstName + " " + lastName
-} | order(fullName)
-
-// ✅ Optimizable (original attribute)
-*[_type == "person"] | order(firstName, lastName)
-```
-
-### Quick Checklist
-
-| Rule                                | Why                                           |
-| ----------------------------------- | --------------------------------------------- |
-| Always project `{ fields }`         | Reduces data returned                         |
-| Use `defined()` checks              | Filters use indexes                           |
-| Use `$params` not interpolation     | Prevents query manipulation + enables caching |
-| Order BEFORE slice                  | `order()[0...N]` not `[0...N] order()`        |
-| Use `_ref` not `->field` in filters | Avoids expensive joins                        |
-| Merge repeated `->` calls           | Single subquery vs many                       |
-| Cursor pagination for deep pages    | Avoids sorting entire dataset                 |
-
-## 7. API Version Best Practices
-
-Always use dated versions (`YYYY-MM-DD`) for consistent behavior:
-
-```typescript
-const client = createClient({
-  apiVersion: "2026-02-01", // Use current date for new projects
-});
-```
-
-- **New projects:** Use current date (e.g., `2026-02-01`)
-- **Existing projects:** Keep current version unless you need new features
-- Dated versions lock behavior; `v1` or `vX` may change unexpectedly

.github/skills/sanity-best-practices/references/hydrogen.md

@@ -1,275 +0,0 @@
----
-title: "Sanity + Shopify + Hydrogen Rules"
-description: Integration guide for Sanity with Shopify using the Hydrogen framework (React Router 7).
----
-
-# Sanity + Shopify + Hydrogen Rules
-
-**Package:** [`hydrogen-sanity`](https://github.com/sanity-io/hydrogen-sanity) — requires `@shopify/hydrogen >= 2025.5.0`
-
-## 1. Architecture Overview
-
-| Component          | Purpose                                                             |
-| ------------------ | ------------------------------------------------------------------- |
-| **Shopify**        | Product catalog, inventory, checkout (source of truth for commerce) |
-| **Sanity Connect** | Syncs Shopify data to Sanity in real-time                           |
-| **Sanity Studio**  | Editorial content, rich descriptions, media (enhances Shopify data) |
-| **Hydrogen**       | React Router 7 front-end optimized for Shopify                      |
-
-**Project Structure:**
-
-```
-./
-├── /studio    # Sanity Studio
-└── /web       # Hydrogen front-end
-```
-
-## 2. Environment Variables
-
-```bash
-# web/.env
-PUBLIC_STOREFRONT_API_TOKEN="your-public-storefront-token"
-PRIVATE_STOREFRONT_API_TOKEN="your-private-storefront-token"
-PUBLIC_STORE_DOMAIN="your-store.myshopify.com"
-SESSION_SECRET="your-random-session-secret"
-
-# Sanity
-SANITY_PROJECT_ID="your-project-id"
-SANITY_DATASET="production"
-SANITY_API_VERSION="2026-02-01"
-SANITY_PREVIEW_TOKEN="your-sanity-viewer-token"  # Viewer token for previews
-```
-
-## 3. Sanity Client Setup
-
-### Vite Config
-
-```typescript
-// web/vite.config.ts
-import { hydrogen } from "@shopify/hydrogen/vite";
-import { sanity } from "hydrogen-sanity/vite";
-
-export default defineConfig({
-  plugins: [hydrogen(), sanity()],
-});
-```
-
-### Context Setup
-
-```typescript
-// web/app/lib/context.ts
-import { type SanityContext, createSanityContext } from "hydrogen-sanity";
-import { isPreviewEnabled } from "hydrogen-sanity/preview";
-import { PreviewSession } from "hydrogen-sanity/preview/session";
-
-const sanity = await createSanityContext({
-  request,
-  cache,
-  waitUntil,
-  client: {
-    projectId: env.SANITY_PROJECT_ID,
-    dataset: env.SANITY_DATASET,
-    apiVersion: env.SANITY_API_VERSION || "2026-02-01",
-    useCdn: true,
-    stega: {
-      enabled: isPreviewEnabled(env.SANITY_PROJECT_ID, previewSession),
-      studioUrl: "http://localhost:3333",
-    },
-  },
-  preview: {
-    token: env.SANITY_PREVIEW_TOKEN,
-    session: previewSession,
-  },
-});
-```
-
-### Provider Setup (entry.server.tsx)
-
-```typescript
-const {SanityProvider} = context.sanity
-
-const body = await renderToReadableStream(
-  <NonceProvider>
-    <SanityProvider>
-      <ServerRouter context={reactRouterContext} url={request.url} nonce={nonce} />
-    </SanityProvider>
-  </NonceProvider>,
-)
-```
-
-### Root Layout (root.tsx)
-
-```typescript
-import {Sanity} from 'hydrogen-sanity'
-
-export function Layout({children}) {
-  const nonce = useNonce()
-  return (
-    <html>
-      <body>
-        {children}
-        <Sanity nonce={nonce} />  {/* Required for client-side */}
-        <Scripts nonce={nonce} />
-      </body>
-    </html>
-  )
-}
-```
-
-## 4. Data Fetching
-
-Fetch from **both** Shopify (GraphQL) and Sanity (GROQ). Use `defineQuery` for TypeGen support.
-
-### Recommended: `query` + `Query` component
-
-```typescript
-import {defineQuery} from 'groq'
-import {Query} from 'hydrogen-sanity'
-
-const PRODUCT_QUERY = defineQuery(`*[_type == "product" && store.slug.current == $handle][0]{ body }`)
-
-// Loader
-export async function loader({params, context: {sanity}}: LoaderFunctionArgs) {
-  const initial = await context.sanity.query(PRODUCT_QUERY, params)
-  return {initial}
-}
-
-// Component - auto-enables live preview when active
-export default function ProductPage({loaderData}) {
-  return (
-    <Query query={PRODUCT_QUERY} options={{initial: loaderData.initial}}>
-      {(data) => <div>{data?.body}</div>}
-    </Query>
-  )
-}
-```
-
-### Alternative methods
-
-| Method                     | Use Case                        |
-| -------------------------- | ------------------------------- |
-| `sanity.query()` + `Query` | Recommended - auto preview mode |
-| `sanity.loadQuery()`       | Manual loader integration       |
-| `sanity.fetch()`           | No preview needed, lightweight  |
-| `sanity.client`            | Mutations in actions            |
-
-### Images
-
-```typescript
-import {useImageUrl} from 'hydrogen-sanity'
-
-function Hero({image}) {
-  const imageUrl = useImageUrl(image)
-  return <img src={imageUrl.width(1200).height(600).url()} />
-}
-```
-
-**Key Insight:** Shopify fields synced via Sanity Connect are `readOnly`. Use Sanity for editorial enhancements only.
-
-## 5. Visual Editing Setup
-
-### Root Layout
-
-```typescript
-// web/app/root.tsx
-import {usePreviewMode} from 'hydrogen-sanity/preview'
-import {VisualEditing} from 'hydrogen-sanity/visual-editing'
-
-export function Layout({children}: {children?: React.ReactNode}) {
-  const previewMode = usePreviewMode()
-
-  return (
-    <html>
-      <body>
-        {children}
-        {previewMode ? <VisualEditing action="/api/preview" /> : null}
-      </body>
-    </html>
-  )
-}
-```
-
-### Preview Route
-
-```typescript
-// web/app/routes/api.preview.ts
-export { action, loader } from "hydrogen-sanity/preview/route";
-```
-
-### Content Security Policy
-
-```typescript
-// web/entry.server.tsx
-const { nonce, header, NonceProvider } = createContentSecurityPolicy({
-  frameAncestors: isPreviewEnabled ? [studioHostname] : [],
-  connectSrc: [
-    `https://${projectId}.api.sanity.io`,
-    `wss://${projectId}.api.sanity.io`,
-  ],
-});
-```
-
-## 6. Studio: Presentation Tool
-
-```typescript
-// studio/sanity.config.ts
-import { presentationTool } from "sanity/presentation";
-
-export default defineConfig({
-  plugins: [
-    presentationTool({
-      resolve: {
-        locations: {
-          product: defineLocations({
-            select: { title: "store.title", slug: "store.slug.current" },
-            resolve: (doc) => ({
-              locations: [
-                {
-                  title: doc?.title || "Untitled",
-                  href: `/products/${doc?.slug}`,
-                },
-                { title: "Products", href: `/collections/all` },
-              ],
-            }),
-          }),
-        },
-      },
-      previewUrl: {
-        origin: "http://localhost:3000",
-        previewMode: { enable: "/api/preview" },
-      },
-    }),
-  ],
-});
-```
-
-## 7. Commands
-
-```bash
-# Install dependencies
-pnpm add hydrogen-sanity @sanity/client @portabletext/react
-
-# Development (run in separate terminals)
-cd studio && pnpm dev    # Studio at localhost:3333
-cd web && pnpm dev       # Hydrogen at localhost:3000
-
-# Sanity Manage (CORS, tokens): https://www.sanity.io/manage
-pnpm dlx sanity manage
-```
-
-## 8. Boundaries
-
-- Always:
-  - Query Shopify for commerce data (price, inventory, variants)
-  - Query Sanity for editorial content (rich text, custom fields)
-  - Use `hydrogen-sanity` package for Visual Editing
-  - Add Hydrogen URL to CORS origins in [Sanity Manage](https://www.sanity.io/manage)
-
-- Ask First:
-  - Before modifying Sanity Connect sync settings
-  - Before changing CSP configuration
-
-- Never:
-  - Edit Shopify-synced fields in Sanity (they're `readOnly`)
-  - Expose `SANITY_API_TOKEN` to client-side code
-  - Query Sanity for commerce data that should come from Shopify

.github/skills/sanity-best-practices/references/image.md

@@ -1,133 +0,0 @@
----
-title: "Sanity Image Rules"
-description: "Best practices for handling images in Sanity: Schema, URL generation, and Next.js Image integration."
----
-
-# Sanity Image Rules
-
-## 1. Schema Definition
-
-**Always** enable `hotspot: true`. This allows editors to control cropping and the focal point.
-
-```typescript
-defineField({
-  name: "mainImage",
-  title: "Main Image",
-  type: "image",
-  options: {
-    hotspot: true, // CRITICAL
-  },
-  fields: [
-    defineField({
-      name: "alt",
-      type: "string",
-      title: "Alternative Text",
-      validation: (rule) =>
-        rule.required().warning("Alt text is important for SEO"),
-    }),
-  ],
-});
-```
-
-## 2. URL Builder (`urlFor`)
-
-Use the Sanity Image URL Builder to generate optimized URLs (resize, crop, format).
-
-**Setup (`sanity/lib/image.ts`):**
-
-```typescript
-import createImageUrlBuilder from "@sanity/image-url";
-import { dataset, projectId } from "../env";
-
-const builder = createImageUrlBuilder({ projectId, dataset });
-
-export const urlFor = (source: any) => {
-  return builder.image(source);
-};
-```
-
-**Usage:** The URL builder automatically uses hotspot/crop data when available:
-
-```typescript
-const imageUrl = urlFor(mainImage)
-  .width(800)
-  .height(600)
-  .fit("crop") // Respects hotspot when cropping
-  .url();
-```
-
-## 3. Next.js Image Component Pattern
-
-Create a reusable `SanityImage` component that handles the `urlFor` logic and `next/image` props.
-
-```typescript
-import Image from 'next/image'
-import { urlFor } from '@/sanity/lib/image'
-
-interface SanityImageProps {
-  value: any // SanityImageSource
-  width?: number
-  height?: number
-  className?: string
-  priority?: boolean
-}
-
-export function SanityImage({ value, width = 800, height, className, priority }: SanityImageProps) {
-  if (!value?.asset) return null
-
-  return (
-    <Image
-      className={className}
-      src={urlFor(value)
-        .width(width)
-        .height(height || Math.round(width / 1.5)) // Default aspect ratio if no height
-        .url()}
-      alt={value.alt || ''}
-      width={width}
-      height={height || Math.round(width / 1.5)}
-      priority={priority}
-      // Optional: Use LQIP (Low Quality Image Placeholder)
-      placeholder={value.asset.metadata?.lqip ? 'blur' : 'empty'}
-      blurDataURL={value.asset.metadata?.lqip}
-    />
-  )
-}
-```
-
-## 4. Querying Images
-
-**Critical:** LQIP (Low Quality Image Placeholder) is **not automatic**. You must explicitly query it via `asset->{ metadata { lqip } }`.
-
-### Minimal Query (No LQIP)
-
-```groq
-mainImage {
-  asset->{ _id, url },
-  alt
-}
-```
-
-### Full Query (With LQIP & Dimensions)
-
-```groq
-mainImage {
-  asset->{
-    _id,
-    url,
-    metadata {
-      lqip,                          // Base64 blur placeholder
-      dimensions { width, height }   // For aspect ratio
-    }
-  },
-  alt,
-  hotspot,  // Include if using hotspot cropping
-  crop      // Include if using cropping
-}
-```
-
-**Why this matters:** Without querying `metadata.lqip`, the `blurDataURL` in your component will be `undefined` and the blur effect won't work.
-
-## 5. Performance Tips
-
-- **Auto Format:** Sanity CDN automatically serves WebP/AVIF if the browser supports it (no need to specify `.format('webp')` manually in most cases, but `next/image` handles this too).
-- **Sizing:** Always request the exact size you need using `.width()` and `.height()` in `urlFor`. Don't download a 4000px image for a thumbnail.

.github/skills/sanity-best-practices/references/localization.md

@@ -1,458 +0,0 @@
----
-title: Sanity Localization Rules
-description: Localization patterns for Sanity using official plugins and best practices.
----
-
-# Sanity Localization Rules
-
-Use the contents list to jump directly to the localization pattern you need.
-
-## Table of Contents
-
-- Guiding principles
-- Terminology
-- Locale content type
-- Choosing document-level vs field-level localization
-- Document-level localization
-- Localized singletons
-- Field-level localization
-- AI-powered translation
-- UI enhancement
-- Frontend URL best practices
-
-## 1. Guiding Principles
-
-### Priority: Easy Authoring Experience
-
-The structured nature of Sanity schemas and GROQ make it easy to parse localized content for your frontend. **Never** let frontend architecture dictate your localization approach — prioritize the editor experience.
-
-### Avoid Content Duplication
-
-Don't create nearly identical copies with slight differences (e.g., US vs British English). Use Portable Text marks and custom blocks to swap out words or sections as needed.
-
-## 2. Terminology
-
-| Term                            | Definition                                                |
-| ------------------------------- | --------------------------------------------------------- |
-| **Internationalization (i18n)** | Designing your frontend to support multiple languages     |
-| **Localization**                | Adapting content for a specific language/region           |
-| **Language Tag**                | Code like `en`, `en-US`, `zh-Hant-TW` (per IETF RFC 5646) |
-| **Locale**                      | A language tag with region info (e.g., `en-US`)           |
-
-## 3. Create a Locale Content Type
-
-**Best Practice:** Store locales in Sanity, not just in code. This allows sharing between Studio and frontend.
-
-```typescript
-// schemaTypes/locale.ts
-import { TranslateIcon } from "@sanity/icons";
-import { defineField, defineType } from "sanity";
-
-export const localeType = defineType({
-  name: "locale",
-  icon: TranslateIcon,
-  type: "document",
-  fields: [
-    defineField({
-      name: "name",
-      type: "string",
-      validation: (r) => r.required(),
-    }),
-    defineField({
-      name: "tag",
-      type: "string",
-      description: "IANA tag (en, en-US)",
-      validation: (r) => r.required(),
-    }),
-    defineField({
-      name: "fallback",
-      type: "reference",
-      to: [{ type: "locale" }],
-    }),
-    defineField({ name: "default", type: "boolean" }),
-  ],
-  preview: { select: { title: "name", subtitle: "tag" } },
-});
-```
-
-**Tip:** Restrict locale editing to admins via Structure by filtering `locale` from non-admin users.
-
-## 4. Choose Your Localization Method
-
-| Content Type            | Examples                                | Recommended Method |
-| ----------------------- | --------------------------------------- | ------------------ |
-| **Structured** (things) | Products, People, Locations, Categories | Field-level        |
-| **Presentation** (UI)   | Pages, Posts, Components                | Document-level     |
-
-### Decision Questions
-
-1. **Are fields shared across languages?** → Field-level
-2. **Should changes be "global" for all locales?** (e.g., reordering components) → Field-level
-3. **Is content mostly the same except regional differences?** → Field-level with PT marks
-4. **Need to publish language versions independently?** → Document-level
-
-## 5. Document-Level Localization
-
-Use the **@sanity/document-internationalization** plugin.
-
-```bash
-npm install @sanity/document-internationalization
-```
-
-### Configuration
-
-```typescript
-// sanity.config.ts
-import { documentInternationalization } from "@sanity/document-internationalization";
-
-export default defineConfig({
-  plugins: [
-    documentInternationalization({
-      // Fetch from Content Lake
-      supportedLanguages: (client) =>
-        client.fetch(`*[_type == "locale"]{ "id": tag, "title": name }`),
-      // Document types to localize
-      schemaTypes: ["post", "page"],
-    }),
-  ],
-});
-```
-
-### Add Language Field to Schema
-
-```typescript
-// In each schema type listed in schemaTypes
-defineField({
-  name: "language",
-  type: "string",
-  readOnly: true,
-  hidden: true,
-});
-```
-
-### Initial Value Templates
-
-Pre-set language when creating documents outside the translation UI:
-
-```typescript
-// sanity.config.ts
-import { template } from "sanity";
-
-export default defineConfig({
-  // ...
-  document: {
-    newDocumentOptions: (prev, { creationContext }) => {
-      // Filter to only show base language in "New document" menu
-      // The plugin handles creating translations from there
-      return prev.filter(
-        (item) =>
-          !["post", "page"].includes(item.templateId) ||
-          item.parameters?.language === "en",
-      );
-    },
-  },
-  // Initial value templates for each language
-  templates: (prev) => [
-    ...prev,
-    template.initial({
-      id: "post-en",
-      title: "Post (English)",
-      schemaType: "post",
-      parameters: [{ name: "language", type: "string" }],
-      value: ({ language }) => ({ language }),
-    }),
-  ],
-});
-```
-
-### Querying Translated Documents
-
-```groq
-// Get document in specific language
-*[_type == "post" && language == $locale && slug.current == $slug][0]
-
-// Get all translations via metadata document
-*[_type == "translation.metadata" && references($docId)][0] {
-  translations[] {
-    _key,
-    value-> { title, slug, language }
-  }
-}
-```
-
-## 6. Localized Singletons (Homepage per Locale)
-
-For singletons like homepages that need a separate document per locale, combine document-level localization with the singleton pattern.
-
-### Schema Definition
-
-```typescript
-// schemaTypes/homePage.ts
-import { HomeIcon } from "@sanity/icons";
-import { defineField, defineType } from "sanity";
-
-export const homePageType = defineType({
-  name: "homePage",
-  title: "Home Page",
-  type: "document",
-  icon: HomeIcon,
-  fields: [
-    defineField({
-      name: "language",
-      type: "string",
-      readOnly: true,
-      hidden: true,
-    }),
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "pageBuilder", type: "pageBuilder" }),
-    // ... other fields
-  ],
-  preview: {
-    select: { language: "language" },
-    prepare({ language }) {
-      return {
-        title: "Home Page",
-        subtitle: language?.toUpperCase() || "No language",
-      };
-    },
-  },
-});
-```
-
-### Initial Value Templates
-
-Create templates that pre-set the language for each locale:
-
-```typescript
-// sanity.config.ts
-import { Template, defineConfig } from "sanity";
-
-// Define your supported locales
-const LOCALES = [
-  { id: "en", title: "English" },
-  { id: "fr", title: "French" },
-  { id: "de", title: "German" },
-];
-
-export default defineConfig({
-  // ...
-  templates: (prev) => {
-    // Create a template for each locale
-    const homePageTemplates: Template[] = LOCALES.map((locale) => ({
-      id: `homePage-${locale.id}`,
-      title: `Home Page (${locale.title})`,
-      schemaType: "homePage",
-      parameters: [{ name: "language", type: "string" }],
-      value: { language: locale.id },
-    }));
-
-    return [...prev, ...homePageTemplates];
-  },
-});
-```
-
-### Structure: Localized Singleton Helper
-
-Create a helper to show one singleton per locale in the Structure:
-
-```typescript
-// src/structure/index.ts
-import { HomeIcon } from "@sanity/icons";
-import { StructureBuilder, StructureResolver } from "sanity/structure";
-
-const LOCALES = ["en", "fr", "de"];
-
-function createLocalizedSingleton(
-  S: StructureBuilder,
-  typeName: string,
-  title: string,
-  icon?: React.ComponentType,
-) {
-  return S.listItem()
-    .title(title)
-    .icon(icon)
-    .child(
-      S.list()
-        .title(title)
-        .items(
-          LOCALES.map((locale) =>
-            S.listItem()
-              .title(`${title} (${locale.toUpperCase()})`)
-              .icon(icon)
-              .child(
-                S.document()
-                  .schemaType(typeName)
-                  .documentId(`${typeName}-${locale}`) // Fixed ID per locale
-                  .title(`${title} (${locale.toUpperCase()})`),
-              ),
-          ),
-        ),
-    );
-}
-
-export const structure: StructureResolver = (S) =>
-  S.list()
-    .title("Content")
-    .items([
-      // Localized singletons
-      createLocalizedSingleton(S, "homePage", "Home Page", HomeIcon),
-
-      S.divider(),
-
-      // Filter localized singletons from default list
-      ...S.documentTypeListItems().filter(
-        (item) => !["homePage"].includes(item.getId() as string),
-      ),
-    ]);
-```
-
-### Querying Localized Singletons
-
-```groq
-// Get homepage for specific locale
-*[_type == "homePage" && language == $locale][0]{
-  title,
-  pageBuilder[]{...}
-}
-
-// Or by fixed document ID
-*[_id == "homePage-" + $locale][0]{...}
-```
-
-### Key Points
-
-- **Fixed IDs:** Use `${typeName}-${locale}` only for localized singletons; let Sanity generate IDs for ordinary localized content
-- **Initial Value Templates:** Essential for the "New document" menu to work correctly
-- **Structure:** Group all locale versions under one list item for cleaner navigation
-- **See also:** `studio-structure.md` for more singleton patterns
-
-## 7. Field-Level Localization
-
-Use **sanity-plugin-internationalized-array** (NOT localized objects — they hit attribute limits).
-
-```bash
-npm install sanity-plugin-internationalized-array
-```
-
-### Configuration
-
-```typescript
-// sanity.config.ts
-import { internationalizedArray } from "sanity-plugin-internationalized-array";
-
-export default defineConfig({
-  plugins: [
-    internationalizedArray({
-      languages: (client) =>
-        client.fetch(`*[_type == "locale"]{ "id": tag, "title": name }`),
-      fieldTypes: ["string", "text", "simpleBlockContent"],
-    }),
-  ],
-});
-```
-
-### Usage in Schema
-
-```typescript
-// The plugin creates types like `internationalizedArrayString`
-defineField({
-  name: "jobTitle",
-  type: "internationalizedArrayString", // Localized string field
-});
-```
-
-### Portable Text Localization
-
-Create a reusable block content type, then add it to `fieldTypes`:
-
-```typescript
-// schemaTypes/simpleBlockContent.ts
-export default defineType({
-  name: "simpleBlockContent",
-  type: "array",
-  of: [
-    {
-      type: "block",
-      styles: [{ title: "Normal", value: "normal" }],
-      lists: [],
-    },
-  ],
-});
-
-// sanity.config.ts
-fieldTypes: ["string", "simpleBlockContent"];
-
-// In your schema
-defineField({
-  name: "bio",
-  type: "internationalizedArraySimpleBlockContent",
-});
-```
-
-### Querying Internationalized Arrays
-
-```groq
-// Get specific locale value
-*[_type == "author"][0] {
-  "jobTitle": jobTitle[_key == $locale][0].value
-}
-
-// With fallback
-*[_type == "author"][0] {
-  "jobTitle": coalesce(
-    jobTitle[_key == $locale][0].value,
-    jobTitle[_key == "en"][0].value
-  )
-}
-```
-
-## 8. AI-Powered Translation
-
-Use **@sanity/assist** for automated translations.
-
-```bash
-npm install @sanity/assist
-```
-
-```typescript
-// sanity.config.ts
-import { assist } from "@sanity/assist";
-
-export default defineConfig({
-  plugins: [
-    assist({
-      translate: {
-        // For document-level localization
-        document: {
-          languageField: "language",
-        },
-        // For field-level localization
-        field: {
-          languages: (client) =>
-            client.fetch(`*[_type == "locale"]{ "id": tag, "title": name }`),
-          documentTypes: ["author", "category"],
-        },
-      },
-    }),
-  ],
-});
-```
-
-## 9. UI Enhancement
-
-Use **@sanity/language-filter** to let editors show/hide locales:
-
-```bash
-npm install @sanity/language-filter
-```
-
-## 10. Frontend URL Best Practices
-
-**Always include locale in the URL** for SEO:
-
-- `yoursite.com/en/my-page` → `yoursite.com/fr/my-page`
-- `yoursite.com/my-page` → redirects to default locale
-
-**Avoid:** Having the default locale at root without prefix — causes SEO edge cases.
-
-Use Next.js middleware (or framework equivalent) to redirect paths missing a locale prefix to the default locale.

.github/skills/sanity-best-practices/references/migration-html-import.md

@@ -1,143 +0,0 @@
----
-title: Import HTML to Portable Text
-description: Use @portabletext/block-tools with JSDOM to convert HTML content
----
-
-## Import HTML to Portable Text
-
-Use `@portabletext/block-tools` with `JSDOM` to convert HTML from legacy CMSs to Portable Text.
-
-### Setup
-
-```bash
-npm install @portabletext/block-tools jsdom
-```
-
-### Basic Conversion
-
-```typescript
-import { htmlToBlocks } from "@portabletext/block-tools";
-import { JSDOM } from "jsdom";
-
-// Get block content type from your schema
-const blockContentType = schema.get("blockContent");
-
-const blocks = htmlToBlocks(htmlString, blockContentType, {
-  parseHtml: (html) => new JSDOM(html).window.document,
-});
-```
-
-### Custom Deserializers
-
-Handle specific HTML patterns:
-
-```javascript
-const blocks = htmlToBlocks(htmlString, blockContentType, {
-  parseHtml: (html) => new JSDOM(html).window.document,
-  rules: [
-    {
-      deserialize(el, next, block) {
-        // Custom link handling
-        if (el.tagName.toLowerCase() === "a") {
-          return {
-            _type: "link",
-            href: el.getAttribute("href"),
-            blank: el.getAttribute("target") === "_blank",
-          };
-        }
-        // Custom image handling
-        if (el.tagName.toLowerCase() === "img") {
-          return {
-            _type: "image",
-            // Upload image separately, store reference
-            _sanityAsset: `image@${el.getAttribute("src")}`,
-          };
-        }
-        return undefined; // Fall through to default handling
-      },
-    },
-  ],
-});
-```
-
-### Pre-Processing HTML
-
-Clean HTML before conversion:
-
-```javascript
-function cleanHtml(html) {
-  const dom = new JSDOM(html);
-  const doc = dom.window.document;
-
-  // Remove layout elements
-  doc
-    .querySelectorAll("header, footer, nav, .sidebar")
-    .forEach((el) => el.remove());
-
-  // Extract metadata before processing body
-  const title = doc.querySelector("title")?.textContent;
-  const description = doc.querySelector('meta[name="description"]')?.content;
-
-  return {
-    body: doc.body.innerHTML,
-    metadata: { title, description },
-  };
-}
-```
-
-### Image Upload
-
-Don't just link external images—upload them:
-
-```javascript
-async function uploadImage(client, imageUrl) {
-  const response = await fetch(imageUrl);
-  const buffer = await response.arrayBuffer();
-
-  const asset = await client.assets.upload("image", Buffer.from(buffer), {
-    filename: imageUrl.split("/").pop(),
-  });
-
-  return {
-    _type: "image",
-    asset: { _type: "reference", _ref: asset._id },
-  };
-}
-```
-
-### Using in a Migration
-
-Wrap this in `defineMigration` for controlled imports:
-
-```typescript
-// migrations/import-wordpress-posts/index.ts
-import { htmlToBlocks } from "@portabletext/block-tools";
-import { create, defineMigration } from "sanity/migrate";
-
-export default defineMigration({
-  title: "Import WordPress posts",
-  async *migrate(documents, context) {
-    const posts = await fetchWordPressPosts(); // Your import source
-
-    for (const post of posts) {
-      const blocks = htmlToBlocks(post.content, blockContentType, {
-        parseHtml: (html) => new JSDOM(html).window.document,
-      });
-
-      yield create({
-        _type: "post",
-        title: post.title,
-        slug: { _type: "slug", current: post.slug },
-        legacyId: String(post.id),
-        body: blocks,
-      });
-    }
-  },
-});
-```
-
-Let Sanity generate document IDs for ordinary imported content. Add schema fields for legacy identifiers or slugs, then use GROQ lookups against those fields when you need to rerun an import, patch existing documents, or create references between imported records. Set `_id` directly only for singleton documents.
-
-Run with: `sanity migration run import-wordpress-posts --no-dry-run`
-
-Reference: [Schema and Content Migrations](https://www.sanity.io/docs/content-lake/schema-and-content-migrations)

.github/skills/sanity-best-practices/references/migration.md

@@ -1,59 +0,0 @@
----
-title: Sanity Content Migration Rules
-description: Best practices for migrating content (HTML, Markdown) into Sanity Portable Text.
----
-
-# Sanity Content Migration Rules
-
-## Document Identity During Import (Critical)
-
-Let Sanity generate `_id` values for imported documents unless you are intentionally creating a singleton. Do not derive deterministic UUIDs or document IDs from slugs, file paths, legacy IDs, or related document IDs.
-
-- Store legacy identifiers in fields such as `legacyId`, `externalId`, or `slug`.
-- Make imports idempotent by looking up existing documents with GROQ before creating or patching them.
-- Create relationships by querying the target document and using its real `_id` in a `reference`; do not predict `_ref` values from naming conventions.
-- Reserve explicit `_id` values for singleton documents such as `settings`, `homePage`, or localized singleton IDs like `homePage-en`.
-
-## 1. HTML Import (Legacy CMS)
-
-Use `@portabletext/block-tools` with `JSDOM` to convert HTML to Portable Text. This covers setup, custom deserializers, pre-processing, image uploads, and wrapping in `defineMigration`.
-
-**See `migration-html-import.md` for the full guide with working examples.**
-
-## 2. Markdown Import (Static Sites)
-
-Use `@portabletext/markdown` for direct, schema-aware Markdown ↔ Portable Text conversion.
-
-**Recommended: Direct Conversion with `@portabletext/markdown`**
-
-```typescript
-import { markdownToPortableText } from "@portabletext/markdown";
-
-const blocks = markdownToPortableText(markdownString);
-```
-
-This handles headings, lists, bold, italic, code, links, images, and tables. Use `@portabletext/sanity-bridge` to pass your Sanity schema so only valid types are produced.
-
-**Alternative: Markdown → HTML → Portable Text**
-For complex Markdown with non-standard extensions, convert to HTML first, then use `htmlToBlocks` (see above).
-
-1.  **Parse:** `marked` or `remark` to convert MD to HTML.
-2.  **Convert:** Use `htmlToBlocks` from `@portabletext/block-tools`.
-
-> **Note:** `@sanity/block-content-to-markdown` and `@sanity/block-tools` are deprecated. Use `@portabletext/markdown` and `@portabletext/block-tools` instead.
-
-## 3. Image Handling (Universal)
-
-Don't just link to external images. Download them and upload to Sanity Asset Pipeline.
-
-1.  **Extract:** Find `<img>` tags or Markdown image syntax.
-2.  **Download:** Fetch the image buffer.
-3.  **Upload:** `client.assets.upload('image', buffer)`
-4.  **Replace:** Return a Sanity Image block with the new asset reference.
-
-## 4. Schema Validation
-
-Ensure your destination schema allows the structures you are importing.
-
-- **Tables:** Need a `table` type (HTML `<table>` or GFM tables).
-- **Code:** Need a `code` type (HTML `<pre><code>` or MD code fences).

.github/skills/sanity-best-practices/references/nextjs.md

@@ -1,563 +0,0 @@
----
-title: Next.js & Sanity Integration Rules
-description: Integration guide for Next.js App Router, Live Content API, and a standalone Sanity Studio.
----
-
-# Next.js & Sanity Integration Rules
-
-Jump to the section that matches the task instead of reading this guide end-to-end.
-
-## Table of Contents
-
-- Architecture patterns
-- Data fetching (Live Content API)
-- Caching and revalidation
-- Visual Editing and clean data
-- Studio setup (standalone)
-- Draft Mode setup
-- Error handling
-- Presentation queries
-- Pagination pattern
-
-## 1. Architecture Patterns
-
-### Option A: Standalone Studio (Recommended)
-
-**Best for:** All new Next.js projects.
-
-The Studio is its own app, living alongside the Next.js app in the same repo:
-
-```
-your-project/
-├── studio/     # Sanity Studio (standalone)
-└── web/        # Next.js frontend
-```
-
-Why standalone instead of embedding the Studio in the Next.js app:
-
-- **Faster dev and builds:** `sanity dev` and `sanity build` run on Vite and are dramatically faster (10-30x) than compiling the Studio through `next dev` / `next build`.
-- **Auto-updates:** Standalone Studios receive bugfixes and new features automatically, with no dependency bump or redeploy. Embedded Studios can't auto-update (Next.js does not support ESM with import maps), so every update means bump + deploy.
-- **TypeGen watch mode:** With `sanity dev`, TypeGen regenerates types as queries change. Embedded Studios can't hook into `next dev`, so you must re-run `sanity typegen generate` manually after every query edit.
-- **Content model independence:** A separate Studio keeps the content model from becoming website-centric and makes collaboration easier.
-
-**Setup:**
-
-- Run both apps side by side in separate terminals: `next dev` (localhost:3000) and `sanity dev` (localhost:3333).
-- Add your Next.js app URL to **CORS Origins**: `npx sanity cors add http://localhost:3000 --credentials` (repeat for your production URL), or via [Sanity Manage](https://www.sanity.io/manage).
-- See `project-structure.md` rule for detailed structure.
-
-### Option B: Embedded Studio (Not Recommended)
-
-The Studio can be mounted inside the Next.js app at `/app/studio/[[...tool]]/page.tsx` via `next-sanity/studio`. Avoid this for new projects: it slows builds, ties every Studio update to an app deploy, and rules out auto-updates and TypeGen watch mode. For maintaining or migrating an existing embedded Studio, see section 5.
-
-## 2. Data Fetching (Live Content API)
-
-We use `defineLive` (next-sanity v11+) to enable real-time content updates and Visual Editing automatically.
-
-### Setup (`src/sanity/lib/live.ts`)
-
-```typescript
-import { defineLive } from "next-sanity";
-import { client } from "./client";
-
-export const { sanityFetch, SanityLive } = defineLive({
-  client: client.withConfig({
-    apiVersion: "2026-02-01",
-  }),
-  serverToken: process.env.SANITY_API_READ_TOKEN,
-  browserToken: process.env.SANITY_API_READ_TOKEN,
-});
-```
-
-### Rendering (`src/app/layout.tsx`)
-
-You **must** render `<SanityLive />` in the root layout to enable real-time updates.
-
-```typescript
-import { SanityLive } from '@/sanity/lib/live'
-import { VisualEditing } from 'next-sanity/visual-editing'
-import { draftMode } from 'next/headers'
-
-export default async function RootLayout({ children }: { children: React.ReactNode }) {
-  return (
-    <html lang="en">
-      <body>
-        {children}
-        <SanityLive />
-        {(await draftMode()).isEnabled && <VisualEditing />}
-      </body>
-    </html>
-  )
-}
-```
-
-## 3. Caching & Revalidation
-
-### Prefer Live Content API (Default)
-
-**Use `defineLive` by default.** It handles fetching, caching, and invalidation automatically. Only implement manual caching when you need fine-grained control.
-
-### When to Use Manual Caching
-
-| Scenario                                 | Approach                        |
-| ---------------------------------------- | ------------------------------- |
-| Real-time updates, Visual Editing        | `defineLive` (default)          |
-| Static marketing pages, rarely updated   | Time-based revalidation         |
-| Blog posts, products with frequent edits | Tag-based revalidation          |
-| Critical accuracy (stock levels, prices) | Path-based + short revalidation |
-
-### Debugging: Enable Fetch Logging
-
-See every fetch with cache HIT/MISS status:
-
-```typescript
-// next.config.ts
-const nextConfig: NextConfig = {
-  logging: {
-    fetches: {
-      fullUrl: true,
-    },
-  },
-};
-```
-
-Console output shows cache status:
-
-```text
-GET /posts 200 in 39ms
- │ GET https://...apicdn.sanity.io/... 200 in 5ms (cache hit)
-```
-
-### Sanity CDN vs API
-
-| Setting         | Speed  | Freshness            | Use When                         |
-| --------------- | ------ | -------------------- | -------------------------------- |
-| `useCdn: true`  | Fast   | May have brief delay | Default for all runtime fetches  |
-| `useCdn: false` | Slower | Guaranteed fresh     | `generateStaticParams`, webhooks |
-
-Override per-request:
-
-```typescript
-// For static generation, use API directly
-export async function generateStaticParams() {
-  const slugs = await client.withConfig({ useCdn: false }).fetch(SLUGS_QUERY);
-  return slugs;
-}
-```
-
-### Manual `sanityFetch` Helper (Advanced)
-
-For manual caching control, create a wrapper:
-
-```typescript
-// src/sanity/lib/client.ts
-export async function sanityFetch<const QueryString extends string>({
-  query,
-  params = {},
-  revalidate = 60,
-  tags = [],
-}: {
-  query: QueryString;
-  params?: QueryParams;
-  revalidate?: number | false;
-  tags?: string[];
-}) {
-  return client.fetch(query, params, {
-    next: {
-      revalidate: tags.length ? false : revalidate,
-      tags,
-    },
-  });
-}
-```
-
-### Time-Based Revalidation
-
-Simple and predictable. Good for content that changes infrequently.
-
-```typescript
-const posts = await sanityFetch({
-  query: POSTS_QUERY,
-  revalidate: 3600, // Revalidate every hour
-});
-```
-
-**The "Typo Problem":** With time-based only, content authors may wait up to an hour to see changes. Use webhooks for instant updates.
-
-### Path-Based Revalidation
-
-Surgically revalidate specific routes when documents change.
-
-**1. Create API Route:**
-
-```typescript
-// src/app/api/revalidate/path/route.ts
-import { parseBody } from "next-sanity/webhook";
-import { revalidatePath } from "next/cache";
-import { type NextRequest, NextResponse } from "next/server";
-
-type WebhookPayload = { path?: string };
-
-export async function POST(req: NextRequest) {
-  try {
-    const { isValidSignature, body } = await parseBody<WebhookPayload>(
-      req,
-      process.env.SANITY_REVALIDATE_SECRET,
-      true, // Add delay to allow CDN to update
-    );
-
-    if (!isValidSignature) {
-      return new Response("Invalid signature", { status: 401 });
-    }
-    if (!body?.path) {
-      return new Response("Missing path", { status: 400 });
-    }
-
-    revalidatePath(body.path);
-    return NextResponse.json({ revalidated: body.path });
-  } catch (err) {
-    return new Response((err as Error).message, { status: 500 });
-  }
-}
-```
-
-**2. Create GROQ-Powered Webhook:**
-
-- URL: `https://yoursite.com/api/revalidate/path`
-- Filter: `_type in ["post"]`
-- Projection: `{ "path": "/posts/" + slug.current }`
-- Add `SANITY_REVALIDATE_SECRET` to webhook and `.env.local`
-
-### Tag-Based Revalidation
-
-"Update once, revalidate everywhere" — best for referenced content.
-
-**1. Tag Your Queries:**
-
-```typescript
-// Posts index - revalidate when ANY post, author, or category changes
-const posts = await sanityFetch({
-  query: POSTS_QUERY,
-  tags: ["post", "author", "category"],
-});
-
-// Individual post - more granular, includes slug-specific tag
-const post = await sanityFetch({
-  query: POST_QUERY,
-  params,
-  tags: [`post:${params.slug}`, "author", "category"],
-});
-```
-
-**2. Create API Route:**
-
-```typescript
-// src/app/api/revalidate/tag/route.ts
-import { parseBody } from "next-sanity/webhook";
-import { revalidateTag } from "next/cache";
-import { type NextRequest, NextResponse } from "next/server";
-
-type WebhookPayload = { tags: string[] };
-
-export async function POST(req: NextRequest) {
-  try {
-    const { isValidSignature, body } = await parseBody<WebhookPayload>(
-      req,
-      process.env.SANITY_REVALIDATE_SECRET,
-      true,
-    );
-
-    if (!isValidSignature) {
-      return new Response("Invalid signature", { status: 401 });
-    }
-    if (!Array.isArray(body?.tags) || !body.tags.length) {
-      return new Response("Missing tags", { status: 400 });
-    }
-
-    body.tags.forEach((tag) => revalidateTag(tag));
-    return NextResponse.json({ revalidated: body.tags });
-  } catch (err) {
-    return new Response((err as Error).message, { status: 500 });
-  }
-}
-```
-
-**3. Create GROQ-Powered Webhook:**
-
-- URL: `https://yoursite.com/api/revalidate/tag`
-- Filter: `_type in ["post", "author", "category"]`
-- Projection: `{ "tags": [_type, _type + ":" + slug.current] }`
-
-### Stale Data After Webhook?
-
-Webhooks fire _before_ Sanity CDN updates. If you see stale data:
-
-1. **Add delay** — Pass `true` as third arg to `parseBody`
-2. **Or bypass CDN** — Set `useCdn: false` in client config (use sparingly)
-
-## 4. Visual Editing (Stega) & Clean Data
-
-Visual Editing injects invisible characters into strings to enable click-to-edit.
-
-### A. The Golden Rule of Stega
-
-If a string field controls logic (alignment, colors, IDs), you **must** clean it before comparing.
-
-```typescript
-import { stegaClean } from "@sanity/client/stega";
-
-export function Layout({ align }: { align: string }) {
-  // ❌ Bad: Will fail in Edit Mode due to invisible chars
-  // if (align === 'center') ...
-
-  // ✅ Good: Clean the value first
-  const cleanAlign = stegaClean(align);
-  return <div className={cleanAlign === 'center' ? 'mx-auto' : ''} />
-}
-```
-
-### B. Metadata & SEO (Critical)
-
-**Never** let Stega characters leak into `<head>` tags. Always set `stega: false` for metadata fetching.
-
-```typescript
-export async function generateMetadata({ params }) {
-  const { data } = await sanityFetch({
-    query: SEO_QUERY,
-    params: await params,
-    stega: false, // 👈 Critical for SEO
-  });
-  return { title: data?.title };
-}
-```
-
-### C. Static Params
-
-When generating static params, fetch only published content and disable stega.
-
-```typescript
-export async function generateStaticParams() {
-  const { data } = await sanityFetch({
-    query: SLUGS_QUERY,
-    perspective: "published", // 👈 No drafts
-    stega: false,
-  });
-  return data;
-}
-```
-
-## 5. Setup: Studio (Standalone)
-
-Create the Studio as its own app from the repo root — **not inside the Next.js app folder**, where the CLI would switch to its embedded flow:
-
-```bash
-npm create sanity@latest -- --project <projectId> --dataset production --template clean --typescript --output-path studio
-```
-
-Run it with `npm run dev` inside `studio/` (defaults to http://localhost:3333). For Visual Editing, point the Presentation Tool's `previewUrl.origin` at the Next.js app (see `visual-editing.md`).
-
-### Migrating an Existing Embedded Studio
-
-Embedded Studios (`<NextStudio />` mounted at a route like `/app/studio/[[...tool]]/page.tsx`) keep working, but migrating to a standalone Studio is recommended:
-
-1. Create a standalone Studio folder as above, reusing your existing `projectId` and dataset.
-2. Move `sanity.config.ts`, `sanity.cli.ts`, and your schema types into it.
-3. Delete the `/app/studio/[[...tool]]/` route from the Next.js app. Keep `next-sanity` — the app still needs it for fetching, Live Content, and Visual Editing.
-4. Add the app's URLs to CORS origins and set the Presentation Tool's `previewUrl.origin` to the app's URL.
-
-## 6. Setup: Draft Mode
-
-Enable Presentation Tool and Visual Editing by setting up a draft mode route.
-
-**`src/app/api/draft-mode/enable/route.ts`:**
-
-```typescript
-import { defineEnableDraftMode } from "next-sanity/draft-mode";
-import { client } from "@/sanity/lib/client";
-import { token } from "@/sanity/lib/token";
-
-// Helper to get token
-
-export const { GET } = defineEnableDraftMode({
-  client: client.withConfig({ token }),
-});
-```
-
-## 7. Error Handling
-
-Use `notFound()` for missing documents. Common errors:
-
-| Error              | Cause                 | Solution                           |
-| ------------------ | --------------------- | ---------------------------------- |
-| 401 Unauthorized   | Invalid/missing token | Check `SANITY_API_READ_TOKEN`      |
-| 403 Forbidden      | CORS not configured   | Add URL to CORS origins            |
-| Query syntax error | Invalid GROQ          | Test in Vision plugin first        |
-| Empty result       | Wrong filter/params   | Log params, check `_type` spelling |
-
-```typescript
-import { notFound } from 'next/navigation'
-
-export default async function PostPage({ params }: Props) {
-  const { data } = await sanityFetch({ query: POST_QUERY, params: await params })
-  if (!data) notFound()
-  return <Post data={data} />
-}
-```
-
-## 8. Presentation Queries (`usePresentationQuery`)
-
-For faster live editing in the Presentation Tool, use `usePresentationQuery` to fetch only the specific block being edited, rather than re-rendering the entire page.
-
-### Why Use This
-
-- **Without:** Editing a hero title re-fetches the whole page, re-renders all blocks
-- **With:** Only the hero block re-fetches and re-renders
-
-This is especially valuable for pages with many Page Builder blocks or complex Portable Text.
-
-### Basic Pattern
-
-```typescript
-'use client'
-import { usePresentationQuery } from 'next-sanity/hooks'
-import { HERO_PRESENTATION_QUERY } from '@/sanity/lib/queries'
-
-type HeroProps = {
-  _key: string
-  documentId: string
-  title: string
-  subtitle?: string
-  // ... other initial props from page query
-}
-
-export function Hero({ _key, documentId, title, subtitle, ...rest }: HeroProps) {
-  // Fetch block-specific data for faster updates in Presentation Tool
-  const { data } = usePresentationQuery({
-    query: HERO_PRESENTATION_QUERY,
-    params: { documentId, blockKey: _key },
-  })
-
-  // Use presentation data if available, fallback to initial server props
-  const blockData = data?.heroBlock || { title, subtitle, ...rest }
-
-  return (
-    <section>
-      <h1>{blockData.title}</h1>
-      {blockData.subtitle && <p>{blockData.subtitle}</p>}
-    </section>
-  )
-}
-```
-
-### The Presentation Query
-
-Create a query that targets the specific block by `_key`:
-
-```typescript
-// queries.ts
-export const HERO_PRESENTATION_QUERY = defineQuery(`
-  *[_id == $documentId][0]{
-    _id,
-    _type,
-    "heroBlock": pageBuilder[_key == $blockKey && _type == "hero"][0]{
-      title,
-      subtitle,
-      image,
-      theme,
-      // Include all fields the component needs
-    }
-  }
-`);
-```
-
-### Passing Document Context
-
-Your PageBuilder component needs to pass `documentId` to each block:
-
-```typescript
-export function PageBuilder({ content, documentId }: { content: Block[]; documentId: string }) {
-  return (
-    <main>
-      {content.map((block) => {
-        switch (block._type) {
-          case "hero":
-            return <Hero key={block._key} documentId={documentId} {...block} />
-          // ... other blocks
-        }
-      })}
-    </main>
-  )
-}
-```
-
-### For Portable Text Blocks
-
-The same pattern works for custom blocks inside Portable Text:
-
-```typescript
-export const PTE_IMAGE_PRESENTATION_QUERY = defineQuery(`
-  *[_id == $documentId][0]{
-    "pteImageBlock": body[_key == $blockKey && _type == "pteImage"][0]{
-      image,
-      caption,
-      alt
-    }
-  }
-`);
-```
-
-**See also:** `visual-editing.md` for the conceptual overview and `page-builder.md` for full Page Builder patterns.
-
-## 9. Pagination Pattern
-
-For listing pages with many entries, use offset-based pagination with a count query.
-
-### Queries
-
-```typescript
-// Paginated listing
-export const ARTICLES_QUERY = defineQuery(`
-  *[_type == "article" && defined(slug.current)]
-  | order(date desc) [$start...$end] {
-    _id, title, "slug": slug.current, date
-  }
-`);
-
-// Total count for pagination UI
-export const ARTICLES_COUNT_QUERY = defineQuery(`
-  count(*[_type == "article" && defined(slug.current)])
-`);
-```
-
-### Listing Page
-
-```typescript
-const ENTRIES_PER_PAGE = 10;
-
-export default async function BlogPage({
-  searchParams
-}: {
-  searchParams: Promise<{ page?: string }>
-}) {
-  const { page: pageParam } = await searchParams;
-  const page = parseInt(pageParam || "1");
-  const start = (page - 1) * ENTRIES_PER_PAGE;
-  const end = start + ENTRIES_PER_PAGE;
-
-  const [{ data: articles }, { data: total }] = await Promise.all([
-    sanityFetch({ query: ARTICLES_QUERY, params: { start, end } }),
-    sanityFetch({ query: ARTICLES_COUNT_QUERY })
-  ]);
-
-  const totalPages = Math.ceil(total / ENTRIES_PER_PAGE);
-
-  return (
-    <main>
-      {articles.map(article => (
-        <ArticleCard key={article._id} article={article} />
-      ))}
-      <Pagination current={page} total={totalPages} />
-    </main>
-  );
-}
-```

.github/skills/sanity-best-practices/references/nuxt.md

@@ -1,171 +0,0 @@
----
-title: Nuxt & Sanity Integration Rules
-description: Integration guide for Nuxt, including @nuxtjs/sanity, visual editing, and data fetching.
----
-
-# Nuxt & Sanity Integration Rules
-
-## 1. Setup & Configuration
-
-### Scaffold a new Nuxt app
-
-```bash
-npm create nuxt@latest my-app -- -t ui -M "" --packageManager npm --no-gitInit
-cd my-app
-```
-
-`-t ui` selects the Nuxt UI starter. `-M ""` skips the interactive module-selection prompt (empty string = no extra modules). `--packageManager npm` and `--no-gitInit` suppress the other two prompts so the scaffold runs end-to-end without input.
-
-### Installation
-
-```bash
-npx nuxi@latest module add sanity
-```
-
-`nuxi module add sanity` resolves to the official `@nuxtjs/sanity` module and registers it in `nuxt.config.ts` automatically. The module bundles `@sanity/client`, `@sanity/visual-editing`, `@portabletext/vue`, and `groq` as direct dependencies — no separate installs needed.
-
-`groq` and `defineQuery` are also **auto-imported** by the module, so you can use them in `.vue` files without an `import` statement.
-
-For manual image-URL building (an alternative to the auto-registered `<SanityImage>` component), add `@sanity/image-url`:
-
-```bash
-npm install @sanity/image-url
-```
-
-### What the module auto-imports
-
-**Composables** (use directly in `<script setup>`, no imports needed):
-
-- `useSanity()` — get the client and its config
-- `useSanityQuery()` / `useLazySanityQuery()` — reactive query helpers
-- `useSanityConfig()` — read the resolved module config
-- `useSanityPerspective()`, `useSanityPreviewPerspective()`, `useSanityPreviewEnvironment()` — perspective helpers for drafts/preview
-- `useSanityVisualEditingState()`, `useIsSanityLivePreview()`, `useIsSanityPresentationTool()` — visual-editing state helpers
-
-**GROQ helpers** (template tags): `groq`, `defineQuery`
-
-**Components** (use directly in `<template>`):
-
-- `<SanityContent>` — Portable Text renderer (uses `@portabletext/vue` internally; prop is `:value`)
-- `<SanityImage>` — image renderer; takes an `assetId` (the image asset's `_ref`); upgrades to `<NuxtImg>` automatically when `@nuxt/image` is installed
-- `<SanityFile>` — file renderer
-
-### Configuration (`nuxt.config.ts`)
-
-```typescript
-export default defineNuxtConfig({
-  modules: ["@nuxtjs/sanity"],
-  sanity: {
-    projectId: process.env.NUXT_SANITY_PROJECT_ID,
-    dataset: process.env.NUXT_SANITY_DATASET,
-    apiVersion: "2026-05-15",
-    // Live Visual Editing Configuration
-    visualEditing: {
-      studioUrl: process.env.NUXT_SANITY_STUDIO_URL,
-      token: process.env.NUXT_SANITY_API_READ_TOKEN, // Required for fetching drafts
-      stega: true, // Enable stega for visual editing
-      mode: "live-visual-editing", // Default: enables live updates
-    },
-  },
-});
-```
-
-**Important:** Don't enable the `minimal` client if you want the full feature set (composables, components, visual editing).
-
-## 2. Data Fetching
-
-### `useSanityQuery`
-
-Use the composable for reactive fetching. It handles preview state automatically when `visualEditing` is configured. `groq` and `defineQuery` are auto-imported — use either.
-
-```vue
-<!-- app/pages/posts.vue -->
-<script setup lang="ts">
-const query = groq`*[_type == "post" && defined(slug.current)]{ _id, title, slug }`
-const { data: posts } = await useSanityQuery<Array<{ _id: string; title?: string; slug?: { current?: string } }>>(query)
-</script>
-
-<template>
-  <ul>
-    <li v-for="post in posts || []" :key="post._id">
-      <NuxtLink :to="`/${post.slug?.current}`">{{ post.title }}</NuxtLink>
-    </li>
-  </ul>
-</template>
-```
-
-### Dynamic Routes (`[slug].vue`)
-
-Pull the slug off `useRoute()` and pass it as a query parameter. The `<SanityContent>` component renders Portable Text — note the prop is `value`, not `blocks` (renamed in v2).
-
-```vue
-<!-- app/pages/[slug].vue -->
-<script setup lang="ts">
-const route = useRoute()
-const query = groq`*[_type == "post" && slug.current == $slug][0]{ _id, title, body }`
-const { data: post } = await useSanityQuery<{ _id: string; title?: string; body?: unknown[] }>(
-  query,
-  { slug: route.params.slug }
-)
-</script>
-
-<template>
-  <article v-if="post">
-    <h1>{{ post.title }}</h1>
-    <SanityContent v-if="post.body" :value="post.body" />
-  </article>
-</template>
-```
-
-## 3. Visual Editing (Live Preview)
-
-### Automatic Setup
-
-When `visualEditing` is configured in `nuxt.config.ts`, the module handles:
-
-1. Injecting the Visual Editing overlays.
-2. Refreshing data when content changes in the Studio.
-3. Enabling Stega encoding.
-
-### Handling Stega in Logic
-
-If you use stega-encoded strings in logic (e.g. `v-if="post.layout === 'full'"`), you must clean them. `stegaClean` is exported from `@sanity/client/stega` (a transitive of `@nuxtjs/sanity`, so no separate install).
-
-```typescript
-import { stegaClean } from "@sanity/client/stega";
-
-const layout = computed(() => stegaClean(props.layout));
-```
-
-## 4. Components
-
-### Portable Text — `<SanityContent>`
-
-The module auto-registers `<SanityContent>`. Don't install `@portabletext/vue` separately; it's a direct dep of the module.
-
-```vue
-<SanityContent :value="post.body" />
-```
-
-For custom blocks/marks, pass `:components`:
-
-```vue
-<SanityContent :value="post.body" :components="{ block: { h2: MyH2 } }" />
-```
-
-### Images — two options
-
-**Option A — `<SanityImage>` (recommended).** Auto-registered. Takes the asset's `_ref` (the `assetId`) and builds the URL via the module's resolved projectId/dataset. If `@nuxt/image` is installed, it transparently upgrades to `<NuxtImg>` for responsive sizing.
-
-```vue
-<SanityImage :asset-id="post.mainImage.asset._ref" width="800" />
-```
-
-**Option B — `@sanity/image-url` builder.** Install `@sanity/image-url` separately and build URLs manually. Useful when you need fine-grained control (hotspot/crop, format negotiation, srcset).
-
-```typescript
-import imageUrlBuilder from "@sanity/image-url";
-
-const builder = imageUrlBuilder(useSanity().client);
-// builder.image(source).width(800).url()
-```

.github/skills/sanity-best-practices/references/page-builder.md

@@ -1,329 +0,0 @@
----
-title: "Sanity Page Builder Patterns"
-description: Patterns for Sanity Page Builder arrays, block components, and live editing.
----
-
-# Sanity Page Builder Patterns
-
-This guide covers **Page Builder** patterns—arrays of block objects that allow content teams to compose flexible page layouts. For Portable Text (rich text within documents), see `portable-text.md`.
-
-## 1. What is a Page Builder?
-
-A page builder is an **array of objects** (`pageBuilder[]`) that allows content teams to compose pages from reusable blocks without developer intervention.
-
-**When to use:**
-
-- Flexible layouts needed (marketing pages, landing pages)
-- Content can be reordered
-- Different components on different pages
-
-**When NOT to use:**
-
-- Rigid, formulaic content (blog posts, product pages)
-- Highly structured data that doesn't change layout
-- Rich text within a document body—use Portable Text instead
-
-## 2. Schema Organization
-
-### Directory Structure
-
-```
-schemaTypes/
-├── blocks/           # Page builder blocks (objects)
-│   ├── heroType.ts
-│   ├── featuresType.ts
-│   └── faqsType.ts
-├── pageBuilderType.ts  # The array definition
-└── pageType.ts         # Document using the page builder
-```
-
-### Objects vs References
-
-| Use **Objects**                | Use **References**               |
-| ------------------------------ | -------------------------------- |
-| Content is unique to this page | Content reused across many pages |
-| Simpler queries                | Needs central management         |
-| Default choice                 | FAQs, CTAs, testimonials         |
-
-**Rule:** Use references sparingly. Most blocks should be objects.
-
-### Page Builder Array
-
-```typescript
-// pageBuilderType.ts
-import { defineArrayMember, defineType } from "sanity";
-
-export const pageBuilderType = defineType({
-  name: "pageBuilder",
-  type: "array",
-  of: [
-    defineArrayMember({ type: "hero" }),
-    defineArrayMember({ type: "splitImage" }),
-    defineArrayMember({ type: "features" }),
-    defineArrayMember({ type: "faqs" }),
-  ],
-  options: {
-    insertMenu: {
-      views: [
-        // Optional: Show visual thumbnails in the insert menu grid
-        {
-          name: "grid",
-          previewImageUrl: (type) => `/block-previews/${type}.png`,
-        },
-      ],
-    },
-  },
-});
-```
-
-### Block Preview Pattern
-
-Every block should have consistent previews:
-
-```typescript
-import { BlockContentIcon } from "@sanity/icons";
-import { defineType } from "sanity";
-
-export const splitImageType = defineType({
-  name: "splitImage",
-  type: "object",
-  icon: BlockContentIcon,
-  fields: [
-    /* ... */
-  ],
-  preview: {
-    select: { title: "title", media: "image" },
-    prepare({ title, media }) {
-      return {
-        title: title || "Untitled",
-        subtitle: "Split Image", // Block type name
-        media: media ?? BlockContentIcon, // Fallback to icon
-      };
-    },
-  },
-});
-```
-
-## 3. Querying Page Builders
-
-Expand references only for blocks that need them:
-
-```groq
-*[_type == "page" && slug.current == $slug][0]{
-  ...,
-  content[]{
-    ...,
-    _type == "faqs" => {
-      ...,
-      faqs[]->  // Expand only FAQ references
-    }
-  }
-}
-```
-
-## 4. Rendering Page Builders
-
-### TypeScript Typing
-
-Use `Extract` to type individual blocks from the query result:
-
-```typescript
-import { PAGE_QUERYResult } from "@/sanity/types";
-
-type HeroProps = Extract<
-  NonNullable<NonNullable<PAGE_QUERYResult>["content"]>[number],
-  { _type: "hero" }
->;
-
-export function Hero({ title, image }: HeroProps) {
-  // Fully typed!
-}
-```
-
-### Switch-Based Rendering
-
-```typescript
-export function PageBuilder({ content }: { content: Block[] }) {
-  if (!Array.isArray(content)) return null;
-
-  return (
-    <main>
-      {content.map((block) => {
-        switch (block._type) {
-          case "hero":
-            return <Hero key={block._key} {...block} />;
-          case "features":
-            return <Features key={block._key} {...block} />;
-          case "splitImage":
-            return <SplitImage key={block._key} {...block} />;
-          default:
-            return <div key={block._key}>Unknown: {block._type}</div>;
-        }
-      })}
-    </main>
-  );
-}
-```
-
-**Always use `_key` for React keys:**
-
-```typescript
-// Breaks Visual Editing and causes hydration issues
-{items.map((item, i) => <Component key={i} {...item} />)}
-
-// Always use Sanity's _key
-{items.map((item) => <Component key={item._key} {...item} />)}
-```
-
-### Cleaning Values for Logic
-
-Use `stegaClean` when block fields control rendering logic:
-
-```typescript
-import { stegaClean } from "next-sanity";
-
-function SplitImage({ orientation, title, image }) {
-  return (
-    <section data-orientation={stegaClean(orientation) || "imageLeft"}>
-      {/* ... */}
-    </section>
-  );
-}
-```
-
-## 5. Presentation Queries for Live Editing (Next.js)
-
-For faster live updates in the Presentation Tool, use **presentation queries** that fetch only the specific block being edited, rather than re-fetching the entire page.
-
-> **Note:** This pattern uses `usePresentationQuery` from `next-sanity/hooks`. For other frameworks, check your loader package for equivalent functionality.
-
-### The Pattern
-
-1. **Create a block-specific presentation query:**
-
-```typescript
-// queries.ts
-export const HERO_PRESENTATION_QUERY = defineQuery(`
-  *[_id == $documentId][0]{
-    _id,
-    _type,
-    "heroBlock": pageBuilder[_key == $blockKey && _type == "hero"][0]{
-      title,
-      subtitle,
-      image,
-      // ... all fields the component needs
-    }
-  }
-`);
-```
-
-2. **Use `usePresentationQuery` in your component:**
-
-```typescript
-'use client'
-import { usePresentationQuery } from 'next-sanity/hooks'
-import { HERO_PRESENTATION_QUERY } from '@/sanity/lib/queries'
-
-type HeroProps = {
-  _key: string
-  documentId: string
-  // ... initial props from page query
-}
-
-export function Hero({ _key, documentId, ...initialProps }: HeroProps) {
-  // Fetch block-specific data for faster updates
-  const { data } = usePresentationQuery({
-    query: HERO_PRESENTATION_QUERY,
-    params: { documentId, blockKey: _key },
-  })
-
-  // Use presentation data if available, fallback to initial props
-  const blockData = data?.heroBlock || initialProps
-
-  return (
-    <section>
-      <h1>{blockData.title}</h1>
-      {/* ... */}
-    </section>
-  )
-}
-```
-
-### Why This Is Faster
-
-- **Without:** Editing a field triggers a full page re-render with all blocks
-- **With:** Only the specific block re-renders with its targeted query
-
-This pattern is especially valuable for pages with many blocks or complex nested data.
-
-**Note:** See `nextjs.md` for more details on `usePresentationQuery` and `visual-editing.md` for the conceptual overview.
-
-## 6. Page Builder Pitfalls
-
-| Pitfall                   | Solution                                                     |
-| ------------------------- | ------------------------------------------------------------ |
-| Too many block variations | Split into separate blocks if >2 variants                    |
-| Paradox of choice         | Limit blocks per document type                               |
-| Overusing references      | Default to objects; references only for truly shared content |
-| Unused blocks accumulate  | Prune regularly; see deprecation patterns                    |
-| Inconsistent previews     | Always set title, subtitle (block name), and media/icon      |
-
-## 7. Component Alignment Pattern
-
-Map Sanity "alignment" fields (usually string/select) to CSS classes using utility functions.
-
-**Schema:**
-
-```typescript
-defineField({
-  name: "align",
-  type: "string",
-  options: { list: ["left", "center", "right"], layout: "radio" },
-});
-```
-
-**Implementation (Utility):**
-
-```typescript
-import { stegaClean } from "@sanity/client/stega";
-
-export function getTextAlign(align?: string) {
-  // CLEAN the value before switching!
-  switch (stegaClean(align)) {
-    case "left":
-      return "text-left";
-    case "right":
-      return "text-right";
-    default:
-      return "text-center";
-  }
-}
-```
-
-## 8. Semantic Heading Levels
-
-**Rule:** Do NOT store heading levels (h1, h2) in Sanity schema options. Determine them dynamically in the frontend to ensure accessibility.
-
-**Bad Schema:**
-
-```typescript
-// Don't do this
-{ name: 'level', type: 'string', options: { list: ['h1', 'h2'] } }
-```
-
-**Good Component:**
-Pass a `semanticLevel` prop based on the component's context/nesting.
-
-```typescript
-type Props = {
-  block: HeroBlock;
-  level?: 'h1' | 'h2' | 'h3'; // Default to h2 if undefined
-}
-
-export default function Section({ block, level = 'h2' }: Props) {
-  const Tag = level;
-  return <Tag>{block.title}</Tag>;
-}
-```
-
-_Note: For Image patterns, see `image.md`. For Portable Text patterns, see `portable-text.md`._

.github/skills/sanity-best-practices/references/portable-text.md

@@ -1,384 +0,0 @@
----
-title: "Sanity Portable Text Rules"
-description: Portable Text (Rich Text) rendering and custom component creation for React/Next.js.
----
-
-# Sanity Portable Text Rules
-
-Portable Text is Sanity's rich text format, used for content like article bodies (`body[]`). This guide covers rendering and creating custom PTE components.
-
-**Note:** For page-level layout blocks (`pageBuilder[]`), see `page-builder.md`.
-
-## 1. The Component
-
-Use the `PortableText` component from `next-sanity` (or `@portabletext/react`).
-
-```typescript
-import { PortableText } from "next-sanity";
-// or import { PortableText } from "@portabletext/react";
-
-export function Content({ value }: { value: any }) {
-  return <PortableText value={value} components={components} />;
-}
-```
-
-## 2. Custom Components (`components` prop)
-
-**Always** define a typed components object to handle custom blocks, marks, and list styles.
-
-```typescript
-import { PortableTextComponents } from "next-sanity";
-
-const components: PortableTextComponents = {
-  // 1. Block styles (paragraphs, headings)
-  block: {
-    h1: ({ children }) => <h1 className="text-4xl font-bold">{children}</h1>,
-    h2: ({ children }) => <h2 className="text-3xl font-bold">{children}</h2>,
-    blockquote: ({ children }) => <blockquote className="border-l-4 pl-4">{children}</blockquote>,
-  },
-
-  // 2. Custom types (non-text blocks like images, videos)
-  types: {
-    image: ({ value }) => <SanityImage value={value} />,
-    callToAction: ({ value }) => <Button href={value.url}>{value.text}</Button>,
-  },
-
-  // 3. Marks (inline decorators and annotations)
-  marks: {
-    strong: ({ children }) => <strong className="font-bold">{children}</strong>,
-    em: ({ children }) => <em className="italic">{children}</em>,
-    link: ({ children, value }) => {
-      const rel = !value.href.startsWith("/") ? "noreferrer noopener" : undefined;
-      return <a href={value.href} rel={rel} className="underline text-blue-600">{children}</a>;
-    },
-  },
-
-  // 4. Lists
-  list: {
-    bullet: ({ children }) => <ul className="list-disc ml-4">{children}</ul>,
-    number: ({ children }) => <ol className="list-decimal ml-4">{children}</ol>,
-  },
-};
-```
-
-## 3. Component Categories
-
-Portable Text has three types of custom components, each with different patterns:
-
-| Type             | Examples                   | Pattern                           |
-| ---------------- | -------------------------- | --------------------------------- |
-| **Block styles** | h1, h2, blockquote, normal | Text blocks with `children` prop  |
-| **Custom types** | image, video, callToAction | Non-text blocks with `value` prop |
-| **Marks**        | link, strong, productRef   | Inline annotations wrapping text  |
-
-## 4. Creating Block Style Components
-
-Block styles are text blocks like headings and paragraphs. For simple styling, inline components work fine:
-
-```typescript
-block: {
-  h2: ({ children }) => <h2 className="mt-8 mb-4 text-3xl font-bold">{children}</h2>,
-  normal: ({ children }) => <p className="mb-4 leading-relaxed">{children}</p>,
-}
-```
-
-### With Visual Editing Support
-
-For live editing in the Presentation Tool, block style components may need **both** a client and server version:
-
-```typescript
-// Heading2.tsx (Server - simple SSR for production)
-export function Heading2({ children }: { children: React.ReactNode }) {
-  return <h2 className="mt-8 mb-4 text-3xl font-bold">{children}</h2>;
-}
-
-// Heading2Client.tsx (Client - for visual editing context)
-'use client'
-export function Heading2Client({ children, value }: { children: React.ReactNode; value: any }) {
-  // Can access block data via `value` for advanced patterns
-  return <h2 className="mt-8 mb-4 text-3xl font-bold">{children}</h2>;
-}
-```
-
-Use `useIsPresentationTool` to conditionally render the client version:
-
-```typescript
-import { useIsPresentationTool } from 'next-sanity/hooks'
-
-function Heading2Wrapper(props) {
-  const isPresentationTool = useIsPresentationTool()
-
-  if (isPresentationTool) {
-    return <Heading2Client {...props} />
-  }
-  return <Heading2 {...props} />
-}
-```
-
-## 5. Creating Custom Type Components
-
-Custom types are non-text blocks like images, videos, or CTAs embedded in rich text.
-
-### Schema Definition
-
-```typescript
-// schemaTypes/blocks/pteImageBlock.ts
-import { defineField, defineType } from "sanity";
-
-export const pteImageBlock = defineType({
-  name: "pteImage",
-  title: "Image",
-  type: "object",
-  fields: [
-    defineField({ name: "image", type: "image", options: { hotspot: true } }),
-    defineField({ name: "caption", type: "string" }),
-    defineField({
-      name: "alt",
-      type: "string",
-      validation: (r) => r.required(),
-    }),
-  ],
-  preview: {
-    select: { title: "caption", media: "image" },
-  },
-});
-```
-
-### Register in Body Schema
-
-```typescript
-defineField({
-  name: "body",
-  type: "array",
-  of: [
-    { type: "block" }, // Standard text
-    { type: "pteImage" }, // Custom image block
-    { type: "pteVideo" }, // Custom video block
-  ],
-});
-```
-
-### Frontend Component
-
-```typescript
-// PteImageComponent.tsx
-'use client'
-
-type PteImageProps = {
-  value: {
-    _key: string
-    image: any
-    caption?: string
-    alt: string
-  }
-}
-
-export function PteImageComponent({ value }: PteImageProps) {
-  if (!value.image) return null
-
-  return (
-    <figure className="my-8">
-      <SanityImage value={value.image} alt={value.alt} />
-      {value.caption && (
-        <figcaption className="text-sm text-gray-600 mt-2">{value.caption}</figcaption>
-      )}
-    </figure>
-  )
-}
-
-// Register in components
-const components: PortableTextComponents = {
-  types: {
-    pteImage: PteImageComponent,
-  },
-}
-```
-
-## 6. Creating Mark Components
-
-Marks are inline annotations that wrap text—links, highlights, or custom references.
-
-### Schema Definition (Annotation)
-
-```typescript
-// In your block configuration
-defineField({
-  name: "body",
-  type: "array",
-  of: [
-    {
-      type: "block",
-      marks: {
-        decorators: [
-          { title: "Strong", value: "strong" },
-          { title: "Emphasis", value: "em" },
-          { title: "Highlight", value: "highlight" },
-        ],
-        annotations: [
-          {
-            name: "link",
-            type: "object",
-            title: "Link",
-            fields: [
-              { name: "href", type: "url", title: "URL" },
-              {
-                name: "openInNewTab",
-                type: "boolean",
-                title: "Open in new tab",
-              },
-            ],
-          },
-          {
-            name: "productRef",
-            type: "object",
-            title: "Product Reference",
-            fields: [
-              { name: "product", type: "reference", to: [{ type: "product" }] },
-            ],
-          },
-        ],
-      },
-    },
-  ],
-});
-```
-
-### Frontend Component
-
-```typescript
-// LinkMark.tsx
-type LinkMarkProps = {
-  children: React.ReactNode
-  value: {
-    href: string
-    openInNewTab?: boolean
-  }
-}
-
-export function LinkMark({ children, value }: LinkMarkProps) {
-  const { href, openInNewTab } = value
-  const target = openInNewTab ? '_blank' : undefined
-  const rel = openInNewTab ? 'noopener noreferrer' : undefined
-
-  return (
-    <a href={href} target={target} rel={rel} className="text-blue-600 underline">
-      {children}
-    </a>
-  )
-}
-
-// Register in components
-const components: PortableTextComponents = {
-  marks: {
-    link: LinkMark,
-    highlight: ({ children }) => <mark className="bg-yellow-200">{children}</mark>,
-  },
-}
-```
-
-## 7. Presentation Queries for PTE Blocks
-
-For faster live editing of custom PTE blocks, use presentation queries that fetch only the specific block:
-
-```typescript
-// queries.ts
-export const PTE_IMAGE_PRESENTATION_QUERY = defineQuery(`
-  *[_id == $documentId][0]{
-    _id,
-    _type,
-    "pteImageBlock": body[_key == $blockKey && _type == "pteImage"][0]{
-      _key,
-      image,
-      caption,
-      alt
-    }
-  }
-`);
-```
-
-Then in your component:
-
-```typescript
-"use client";
-import { usePresentationQuery } from "next-sanity/hooks";
-
-export function PteImageComponent({
-  value,
-  documentId,
-}: {
-  value: any;
-  documentId?: string;
-}) {
-  const { data } = usePresentationQuery({
-    query: PTE_IMAGE_PRESENTATION_QUERY,
-    params: { documentId, blockKey: value._key },
-  });
-
-  const blockData = data?.pteImageBlock || value;
-
-  // ... render with blockData
-}
-```
-
-**Note:** You'll need to pass `documentId` through to your PTE components. See `visual-editing.md` for context patterns.
-
-## 8. GROQ Fragment for PTE
-
-When querying documents with Portable Text, expand custom blocks:
-
-```groq
-*[_type == "article" && slug.current == $slug][0]{
-  ...,
-  body[]{
-    ...,
-    _type == "pteImage" => {
-      ...,
-      "imageUrl": image.asset->url
-    },
-    _type == "pteVideo" => {
-      ...,
-      video->{ title, url }
-    }
-  }
-}
-```
-
-## 9. Stega and Visual Editing
-
-When Visual Editing is enabled, text content contains invisible stega characters for click-to-edit functionality.
-
-**For text rendering:** Let stega characters pass through—they enable overlays:
-
-```typescript
-// Good - stega preserved for click-to-edit
-<h2>{children}</h2>
-```
-
-**For logic/comparisons:** Clean the values first:
-
-```typescript
-import { stegaClean } from '@sanity/client/stega'
-
-// Clean before using in logic
-const cleanedStyle = stegaClean(block.style)
-if (cleanedStyle === 'h2') { ... }
-```
-
-## 10. Type Safety
-
-When using TypeGen, the Portable Text value usually has a complex generated type. You can often use `any` or `PortableTextBlock[]` for the _prop_, but cast specific blocks if needed.
-
-```typescript
-import { PortableTextBlock } from "next-sanity";
-
-type Props = {
-  value: PortableTextBlock[];
-};
-```
-
-## 11. Best Practices
-
-- **Tailwind Typography:** For simple blogs, wrap `<PortableText />` in a `<div className="prose">` (from `@tailwindcss/typography`) instead of manually styling every block.
-- **Handling Nulls:** Always check if `value` exists and is an array before rendering.
-- **Keys:** The `PortableText` component handles React keys automatically using the `_key` from Sanity. Do not add keys manually.
-- **Separate from Page Builder:** PTE blocks live in `body[]` (rich text fields), not `pageBuilder[]` (page layout). Keep these patterns separate.

.github/skills/sanity-best-practices/references/project-structure.md

@@ -1,98 +0,0 @@
----
-title: Sanity Project Structure
-description: Project structure patterns for Sanity projects including standalone Studio and monorepo setups.
----
-
-# Sanity Project Structure
-
-## Standalone Studio
-
-Best for content-only projects, API-first architectures, or when frontend is managed separately.
-
-```
-your-project/
-├── schemaTypes/
-│   ├── index.ts
-│   ├── documents/
-│   ├── objects/
-│   └── blocks/
-├── sanity.config.ts
-├── sanity.cli.ts
-└── package.json
-```
-
-**Use cases:**
-
-- Content modeling with MCP/AI tools (no frontend needed)
-- Headless CMS with external consumers
-- Prototyping and content design
-
-## Monorepo (Recommended with a frontend)
-
-Best for most projects pairing Sanity with a Next.js (or other framework) app. The Studio stays standalone — Vite-based dev/builds, auto-updates, TypeGen watch mode — while living in the same repo as the frontend.
-
-```
-your-project/
-├── studio/                     # Sanity Studio (standalone)
-│   ├── schemaTypes/
-│   │   ├── index.ts
-│   │   ├── documents/
-│   │   ├── objects/
-│   │   └── blocks/
-│   ├── sanity.config.ts
-│   ├── sanity.cli.ts           # CLI + TypeGen configuration
-│   └── package.json
-└── web/                        # Next.js (or other framework)
-    ├── src/
-    │   ├── app/
-    │   └── sanity/
-    │       ├── client.ts
-    │       ├── live.ts         # defineLive setup
-    │       └── queries.ts
-    ├── sanity.types.ts         # Generated types (from TypeGen)
-    └── package.json
-```
-
-No workspace tooling is required — each app manages its own dependencies. For larger repos, the same shape works under `apps/` with npm or pnpm workspaces.
-
-**Setup:**
-
-1. Add the web app URL to CORS origins: `npx sanity cors add http://localhost:3000 --credentials` (or via [Sanity Manage](https://www.sanity.io/manage))
-2. Configure `typegen` in `studio/sanity.cli.ts` to read queries from `../web` and output types to `../web/sanity.types.ts` (see `typegen.md`)
-3. Optionally add a root `package.json` with scripts that run both dev servers
-
-## Embedded Studio (Legacy — Not Recommended)
-
-Older Next.js projects may mount the Studio inside the app at `src/app/studio/[[...tool]]/page.tsx`, with `sanity.config.ts` in the app root. This still works but is no longer recommended: it slows builds, ties Studio updates to app deploys, and rules out auto-updates and TypeGen watch mode. See `nextjs.md` for the rationale and migration steps.
-
-## File Naming Conventions
-
-- **kebab-case** for all files: `user-profile.ts`, `hero-block.ts`
-- `.ts` for schemas/utilities, `.tsx` for React components
-- Each schema exports a named const matching filename
-
-## Schema Directory Structure
-
-```
-schemaTypes/
-├── index.ts              # Exports all types
-├── documents/            # Standalone content types
-│   ├── post.ts
-│   └── author.ts
-├── objects/              # Embeddable/reusable types
-│   ├── seo.ts
-│   └── link.ts
-├── blocks/               # Portable Text blocks
-│   ├── hero.ts
-│   └── callout.ts
-└── shared/               # Shared field definitions
-    └── seoFields.ts
-```
-
-## Key Files
-
-| File               | Purpose                                                 |
-| ------------------ | ------------------------------------------------------- |
-| `sanity.config.ts` | Studio configuration (plugins, schema, structure)       |
-| `sanity.cli.ts`    | CLI configuration (project ID, dataset, TypeGen config) |
-| `structure.ts`     | Custom desk structure                                   |

.github/skills/sanity-best-practices/references/remix.md

@@ -1,276 +0,0 @@
----
-title: React Router (Remix) & Sanity Integration Rules
-description: Integration guide for React Router v7 (and Remix v2) with Sanity, including loaders and visual editing.
----
-
-# React Router (Remix) & Sanity Integration Rules
-
-## Version Note
-
-The primary examples below use **React Router v7** (the current shape — Remix v2 was renamed to React Router v7 starting with the v7 release). Import paths and the route-types file (`./+types/<route>`) come from the `react-router` package and the framework's typegen.
-
-If you are on the older **Remix v2** stack, the integration shape is identical; only the import paths differ:
-
-| React Router v7                                 | Remix v2                                                                                       |
-| ----------------------------------------------- | ---------------------------------------------------------------------------------------------- |
-| `react-router`                                  | `@remix-run/node` / `@remix-run/react`                                                         |
-| `import type { Route } from "./+types/<route>"` | `import type { LoaderFunctionArgs } from "@remix-run/node"` + `useLoaderData<typeof loader>()` |
-| `react-router.config.ts`                        | `remix.config.js`                                                                              |
-
-## 1. Setup & Client Pattern
-
-### Scaffold a new React Router v7 app
-
-```bash
-npx create-react-router@latest my-app -y
-cd my-app
-npm install @sanity/client @sanity/react-loader @sanity/visual-editing @portabletext/react groq
-```
-
-`-y` accepts defaults. The Sanity packages cover server loaders (`@sanity/react-loader`, `@sanity/client`), live preview (`@sanity/visual-editing`), Portable Text rendering (`@portabletext/react`), and typed queries (`groq`).
-
-To support both server-side fetching and client-side live previews, use the **Split Loader Pattern**.
-
-### A. Environment Variables
-
-React Router runs on Vite. **Any module reachable from a route component gets bundled into the client** — `process.env` doesn't exist there and will throw `ReferenceError: process is not defined` on client-side route transitions (SSR will still work, which makes this trap easy to miss).
-
-Split publishable values from secrets:
-
-- **Publishable** (`projectId`, `dataset`, `apiVersion`, `studioUrl`): prefix with `VITE_` and read via `import.meta.env`. Safe to import from anywhere.
-- **Secrets** (read tokens, webhook secrets): keep unprefixed and read via `process.env` **only inside `*.server.ts` files**. Never re-export them from a shared module.
-
-`.env`:
-
-```
-VITE_SANITY_PROJECT_ID=your-project-id
-VITE_SANITY_DATASET=production
-VITE_SANITY_API_VERSION=2026-02-01
-VITE_SANITY_STUDIO_URL=http://localhost:3333
-SANITY_API_READ_TOKEN=your-read-token
-```
-
-`app/sanity/env.ts` — browser-safe, publishable values only:
-
-```typescript
-export const projectId = import.meta.env.VITE_SANITY_PROJECT_ID!;
-export const dataset = import.meta.env.VITE_SANITY_DATASET!;
-export const apiVersion =
-  import.meta.env.VITE_SANITY_API_VERSION ?? "2026-02-01";
-export const studioUrl = import.meta.env.VITE_SANITY_STUDIO_URL;
-```
-
-### B. Shared Loader (`app/sanity/loader.ts`)
-
-Defines the store config (SSR enabled, client deferred).
-
-```typescript
-import { createQueryStore } from "@sanity/react-loader";
-
-export const { loadQuery, setServerClient, useQuery, useLiveMode } =
-  createQueryStore({ client: false, ssr: true });
-```
-
-### C. Server Loader (`app/sanity/loader.server.ts`)
-
-Initializes the server client. Read the token directly from `process.env` here — do **not** import it from `env.ts`, or it will leak into the client bundle the moment any client-reachable module touches `env.ts`.
-
-```typescript
-import { createClient } from "@sanity/client";
-import { apiVersion, dataset, projectId, studioUrl } from "./env";
-import { loadQuery, setServerClient } from "./loader";
-
-const client = createClient({
-  projectId,
-  dataset,
-  apiVersion,
-  useCdn: true,
-  token: process.env.SANITY_API_READ_TOKEN,
-  stega: {
-    // Stega encodes invisible markers into string fields for click-to-edit
-    // overlays in the Presentation tool. Those markers can leak into copy/paste,
-    // screen readers, and some downstream renderers, so only enable when actually
-    // previewing — gate on an env var that's only set in preview environments.
-    enabled: Boolean(studioUrl),
-    studioUrl,
-  },
-});
-
-setServerClient(client);
-
-export { loadQuery };
-```
-
-### D. Browser-safe Client + Image URL Builder (`app/sanity/client.ts`, `app/sanity/image.ts`)
-
-Anything used by a route component runs in the browser too. Build a separate publishable-only client for things like the image URL builder:
-
-```typescript
-// app/sanity/client.ts
-import { createClient } from "@sanity/client";
-import { apiVersion, dataset, projectId } from "./env";
-
-export const client = createClient({
-  projectId,
-  dataset,
-  apiVersion,
-  useCdn: true,
-});
-```
-
-```typescript
-// app/sanity/image.ts
-import imageUrlBuilder from "@sanity/image-url";
-import { client } from "./client";
-
-const builder = imageUrlBuilder(client);
-export const urlFor = (source: Parameters<typeof builder.image>[0]) =>
-  builder.image(source);
-```
-
-Install `@sanity/image-url` if you'll render images:
-
-```bash
-npm install @sanity/image-url
-```
-
-### E. Queries (`app/sanity/queries.ts`)
-
-Keep query definitions in one place so route loaders, components, and TypeGen all read the same source.
-
-```typescript
-import { defineQuery } from "groq";
-
-export const POSTS_QUERY = defineQuery(
-  `*[_type == "post" && defined(slug.current)] | order(_createdAt desc){
-    _id, title, slug
-  }`,
-);
-
-export const POST_QUERY = defineQuery(
-  `*[_type == "post" && slug.current == $slug][0]{
-    _id, title, body, image
-  }`,
-);
-```
-
-## 2. Data Fetching (Loaders)
-
-Use `loadQuery` from your **server** file in route loaders. Import the generated `Route` type from `./+types/<route>` — React Router writes one type module per route file.
-
-```typescript
-// app/routes/home.tsx
-import { loadQuery } from "~/sanity/loader.server";
-import { POSTS_QUERY } from "~/sanity/queries";
-import type { Route } from "./+types/home";
-
-export async function loader() {
-  const initial = await loadQuery(POSTS_QUERY, {});
-  return { initial, query: POSTS_QUERY, params: {} };
-}
-
-export default function Home({ loaderData }: Route.ComponentProps) {
-  const { initial } = loaderData;
-  // …pass to component
-}
-```
-
-For Remix v2: replace `Route.ComponentProps` / `Route.LoaderArgs` with `useLoaderData<typeof loader>()` and `LoaderFunctionArgs` from `@remix-run/node`.
-
-## 3. Dynamic Routes (`:slug`)
-
-Register the dynamic route in `app/routes.ts`:
-
-```typescript
-import { type RouteConfig, index, route } from "@react-router/dev/routes";
-
-export default [
-  index("routes/home.tsx"),
-  route(":slug", "routes/post.tsx"),
-] satisfies RouteConfig;
-```
-
-Then in `app/routes/post.tsx`:
-
-```typescript
-import type { Route } from "./+types/post";
-import { PortableText } from "@portabletext/react";
-import { loadQuery } from "~/sanity/loader.server";
-import { useQuery } from "~/sanity/loader";
-import { urlFor } from "~/sanity/image";
-import { POST_QUERY } from "~/sanity/queries";
-
-export async function loader({ params }: Route.LoaderArgs) {
-  const initial = await loadQuery(POST_QUERY, { slug: params.slug });
-  return { initial, query: POST_QUERY, params: { slug: params.slug } };
-}
-
-export default function Post({ loaderData }: Route.ComponentProps) {
-  const { initial, query, params } = loaderData;
-  const { data: post } = useQuery(query, params, { initial });
-
-  return (
-    <article>
-      <h1>{post?.title}</h1>
-      {post?.image && (
-        <img src={urlFor(post.image).width(1200).url()} alt={post.title ?? ""} />
-      )}
-      {post?.body && <PortableText value={post.body} />}
-    </article>
-  );
-}
-```
-
-This route is the canonical shape that exposes the env trap: `urlFor` → `client.ts` → `env.ts`. If `env.ts` reads `process.env`, the route works under SSR (curl returns HTML) but the client-side `<Link>` navigation will throw `ReferenceError: process is not defined` in the browser console and React Router will hard-reload back to `/`.
-
-## 4. Real-time Preview & Visual Editing
-
-### A. Use `useQuery` in Components
-
-Import `useQuery` from your **shared** loader file.
-
-```typescript
-import { useQuery } from "~/sanity/loader";
-
-export default function Page({ loaderData }: Route.ComponentProps) {
-  const { initial, query, params } = loaderData;
-
-  const { data, encodeDataAttribute } = useQuery(query, params, { initial });
-
-  return (
-    <h1 data-sanity={encodeDataAttribute("title")}>
-      {data?.title}
-    </h1>
-  );
-}
-```
-
-### B. Enable Live Mode (`VisualEditing.tsx`)
-
-Create a component to handle the connection.
-
-```typescript
-import { enableVisualEditing } from "@sanity/visual-editing";
-// Your browser-safe client
-import { useEffect } from "react";
-import { client } from "~/sanity/client";
-import { useLiveMode } from "~/sanity/loader";
-
-export default function VisualEditing() {
-  useEffect(() => enableVisualEditing(), []);
-  useLiveMode({ client });
-  return null;
-}
-```
-
-Render this component in `root.tsx` only when valid (e.g., check env vars or user session).
-
-## 5. Stega Cleaning
-
-When using data for logic (routing, classNames), use `stegaClean`.
-
-```typescript
-import { stegaClean } from "@sanity/client/stega"
-// ...
-if (stegaClean(slug) === 'home') { ... }
-```

.github/skills/sanity-best-practices/references/schema.md

@@ -1,445 +0,0 @@
----
-title: Sanity Schema Best Practices
-description: Rules for defining Sanity Content Models (Schemas), including field definitions, strict typing, and validation patterns.
----
-
-# Sanity Schema Best Practices
-
-Use this contents list to jump to the schema design decision you are making.
-
-## Table of Contents
-
-- Core philosophy: data over presentation
-- Strict definition syntax
-- Shared fields pattern
-- Field patterns
-- References vs nested objects
-- Document creation and IDs
-- Safe schema updates
-- Validation patterns
-
-## 1. Core Philosophy: Data > Presentation
-
-Model **what things are**, not **what they look like**.
-
-- ❌ **Bad:** `bigHeroText`, `redButton`, `threeColumnRow`, `color`, `fontSize`
-- ✅ **Good:** `heroStatement`, `callToAction`, `featuresSection`, `status`, `role`
-
-**The test:** "If we redesigned the site, would this field name still make sense?"
-
-- `threeColumnLayout` → ❌ Fails (what if we go to 2 columns?)
-- `features` → ✅ Passes (features are features regardless of layout)
-
-## 2. Strict Definition Syntax
-
-Always use the helper functions from `sanity` for type safety and autocompletion.
-
-- **ALWAYS** use `defineType` for the root export.
-- **ALWAYS** use `defineField` for fields.
-- **ALWAYS** use `defineArrayMember` for items inside arrays.
-
-```typescript
-import { TagIcon } from "@sanity/icons";
-import { defineArrayMember, defineField, defineType } from "sanity";
-
-export const article = defineType({
-  name: "article",
-  title: "Article",
-  type: "document",
-  icon: TagIcon,
-  fields: [
-    defineField({
-      name: "title",
-      type: "string",
-      validation: (rule) => rule.required(),
-    }),
-    defineField({
-      name: "tags",
-      type: "array",
-      of: [
-        // ALWAYS use defineArrayMember for array items
-        defineArrayMember({ type: "reference", to: [{ type: "tag" }] }),
-      ],
-    }),
-  ],
-});
-```
-
-## 3. Shared Fields Pattern
-
-Export arrays of fields to reuse common patterns (e.g., SEO, standard page headers).
-
-```typescript
-// src/schemaTypes/shared/seoFields.ts
-export const seoFields = [
-  defineField({ name: "seoTitle", type: "string", title: "SEO Title" }),
-  defineField({ name: "seoDesc", type: "text", title: "SEO Description" }),
-];
-
-// Usage
-defineType({
-  name: "page",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    ...seoFields, // Spread shared fields
-  ],
-});
-```
-
-## 4. Field Patterns
-
-### A. Array Keys (`_key`)
-
-Every item in a Sanity array automatically gets a `_key` property. This is **critical** for:
-
-- React reconciliation (use as `key` prop)
-- Visual Editing overlays (click-to-edit)
-- Portable Text rendering
-
-**Schema:** Sanity auto-generates `_key` for array items. You don't define it.
-
-**Frontend:** Always use `_key` as React's `key`:
-
-```typescript
-// ✅ Correct
-{items.map((item) => <Component key={item._key} {...item} />)}
-
-// ❌ Wrong - index keys break Visual Editing
-{items.map((item, i) => <Component key={i} {...item} />)}
-```
-
-**Querying:** Always include `_key` in array projections:
-
-```groq
-*[_type == "page"][0]{
-  pageBuilder[]{
-    _key,  // Always include _key in queries
-    _type,
-    ...
-  }
-}
-```
-
-### B. Icons
-
-Always assign an icon from `@sanity/icons` to documents and objects. This improves the Studio UX significantly. Browse all icons at [icons.sanity.build](https://icons.sanity.build/all).
-
-| Content Type   | Icon               |
-| -------------- | ------------------ |
-| Article, Post  | `DocumentTextIcon` |
-| Author, Person | `UserIcon`         |
-| Category, Tag  | `TagIcon`          |
-| Settings       | `CogIcon`          |
-| Page           | `DocumentIcon`     |
-| Image block    | `ImageIcon`        |
-| Video block    | `PlayIcon`         |
-| FAQ            | `HelpCircleIcon`   |
-| Link           | `LinkIcon`         |
-
-### C. Boolean vs. List
-
-Avoid boolean fields for binary states that might expand later.
-
-- **Prefer:** `options.list` with "radio" layout.
-
-```typescript
-defineField({
-  name: "status",
-  type: "string",
-  options: {
-    list: [
-      { title: "Draft", value: "draft" },
-      { title: "Published", value: "published" },
-    ],
-    layout: "radio",
-  },
-});
-```
-
-### D. The "Toggle" Pattern (Conditional Fields)
-
-Use a radio/boolean field to toggle visibility of other fields (often grouped in fieldsets).
-
-```typescript
-(defineField({
-  name: "linkType",
-  type: "string",
-  options: { list: ["internal", "external"], layout: "radio" },
-}),
-  defineField({
-    name: "internalLink",
-    type: "reference",
-    hidden: ({ parent }) => parent?.linkType !== "internal",
-  }),
-  defineField({
-    name: "externalUrl",
-    type: "url",
-    hidden: ({ parent }) => parent?.linkType !== "external",
-  }));
-```
-
-## 5. References vs Nested Objects
-
-A **critical modeling decision**: when to use `reference` vs embedding an `object`.
-
-### Use References When:
-
-- Content is **reusable** across documents (authors, categories, products)
-- Content needs its **own editing interface** in Studio
-- You need to query/filter by the related content independently
-- Multiple documents should share the **same instance** (update once, reflect everywhere)
-
-```typescript
-// ✅ Author is reusable and independently editable
-defineField({
-  name: "author",
-  type: "reference",
-  to: [{ type: "author" }],
-});
-```
-
-### Use Nested Objects When:
-
-- Content is **specific to this document** (not shared)
-- Content doesn't make sense on its own (address, SEO metadata)
-- You want **simpler editing** (all fields in one place)
-- You need the data to be **copied** not linked
-
-```typescript
-// ✅ SEO is document-specific, not shared
-defineField({
-  name: "seo",
-  type: "object",
-  fields: [
-    defineField({ name: "title", type: "string" }),
-    defineField({ name: "description", type: "text" }),
-  ],
-});
-```
-
-### Quick Decision Matrix
-
-| Scenario                  | Use                                   |
-| ------------------------- | ------------------------------------- |
-| Blog post author          | `reference` (reusable)                |
-| Product category          | `reference` (shared taxonomy)         |
-| Page SEO fields           | `object` (page-specific)              |
-| Hero section content      | `object` (page-specific)              |
-| Team member on About page | `reference` (might be used elsewhere) |
-| Call-to-action button     | `object` (usually page-specific)      |
-
-### Querying Differences
-
-```groq
-// Reference requires expansion
-*[_type == "post"]{ author->{ name, bio } }
-
-// Object is already inline
-*[_type == "post"]{ seo { title, description } }
-```
-
-## 6. Document Creation and IDs
-
-Sanity document `_id` values are implementation identifiers, not a content modeling tool.
-
-- **Prefer generated IDs:** Let Sanity assign `_id` values for ordinary content documents. Avoid deterministic UUIDs, slug-derived IDs, and IDs copied from legacy systems.
-- **Use relationships, not ID conventions:** Connect documents with `reference` fields and set `_ref` from an actual lookup or from the `_id` returned after creating the related document.
-- **Store source identity as content:** For imports, put legacy IDs, external IDs, or stable slugs in explicit fields such as `legacyId`, `externalId`, or `slug`, then query by those fields when you need to find or upsert content.
-- **Keep explicit IDs rare:** Directly setting `_id` is mainly useful for singleton documents managed through Studio Structure, such as `settings` or localized singletons like `homePage-en`.
-
-```typescript
-// ✅ Correct - relationship comes from a lookup
-import { defineQuery } from "groq";
-
-const AUTHOR_BY_EXTERNAL_ID_QUERY = defineQuery(`
-  *[_type == "author" && externalId == $externalId][0]{_id}
-`);
-
-const author = await client.fetch(AUTHOR_BY_EXTERNAL_ID_QUERY, {
-  externalId: post.authorId,
-});
-
-if (!author?._id) throw new Error(`Missing author for ${post.authorId}`);
-
-await client.create({
-  _type: "post",
-  title: post.title,
-  slug: { _type: "slug", current: post.slug },
-  legacyId: post.id,
-  author: { _type: "reference", _ref: author._id },
-});
-
-// ❌ Wrong - IDs encode relationships and source data
-await client.createOrReplace({
-  _id: `post-${post.id}`,
-  _type: "post",
-  author: { _type: "reference", _ref: `author-${post.authorId}` },
-});
-```
-
-## 7. Safe Schema Updates (The Deprecation Pattern)
-
-**NEVER** delete a field that contains production data. It will cause data loss or Studio crashes. Instead, follow the **ReadOnly -> Hidden -> Deprecated** lifecycle.
-
-### The Pattern
-
-1.  **`deprecated`**: Adds a visual warning and reason.
-2.  **`readOnly: true`**: Prevents new edits but keeps data visible.
-3.  **`hidden`**: Hides it from _new_ documents (where value is undefined).
-4.  **`initialValue: undefined`**: Ensures new documents don't get this field.
-
-```typescript
-defineField({
-  name: "oldTitle", // The field you want to remove
-  title: "Article Title (Deprecated)",
-  type: "string",
-  deprecated: {
-    reason: 'Use the new "seoTitle" field instead. This will be removed in v2.',
-  },
-  readOnly: true,
-  hidden: ({ value }) => value === undefined,
-  initialValue: undefined,
-});
-```
-
-### Migration Workflow
-
-**Phase 1: Deprecate** — Apply the deprecation pattern above. Deploy.
-
-**Phase 2: Migrate** — Update frontend to use new fields (with `coalesce()` fallbacks). Create a migration:
-
-```typescript
-// migrations/rename-oldTitle-to-newTitle/index.ts
-import { at, defineMigration, setIfMissing, unset } from "sanity/migrate";
-
-export default defineMigration({
-  title: "Rename oldTitle to newTitle",
-  documentTypes: ["article"],
-  filter: "defined(oldTitle) && !defined(newTitle)",
-  migrate: {
-    document(doc) {
-      if (!doc.oldTitle || doc.newTitle) return;
-      return [
-        at("newTitle", setIfMissing(doc.oldTitle)),
-        at("oldTitle", unset()),
-      ];
-    },
-  },
-});
-```
-
-```bash
-# Dry run first (default)
-sanity migration run rename-oldTitle-to-newTitle
-
-# Execute when ready
-sanity migration run rename-oldTitle-to-newTitle --no-dry-run
-```
-
-**Phase 3: Remove** — Once `oldTitle` is undefined for all documents, delete the field definition.
-
-## 8. Validation Patterns
-
-Beyond `rule.required()`, Sanity offers powerful validation options.
-
-### Common Patterns
-
-```typescript
-// Email validation
-defineField({
-  name: "email",
-  type: "string",
-  validation: (rule) => rule.email().required(),
-});
-
-// URL validation (with custom message)
-defineField({
-  name: "website",
-  type: "url",
-  validation: (rule) =>
-    rule
-      .uri({
-        scheme: ["http", "https"],
-      })
-      .error("Must be a valid URL starting with http:// or https://"),
-});
-
-// Length constraints
-defineField({
-  name: "excerpt",
-  type: "text",
-  validation: (rule) =>
-    rule.max(200).warning("Keep it under 200 characters for best SEO"),
-});
-
-// Regex pattern
-defineField({
-  name: "slug",
-  type: "slug",
-  validation: (rule) =>
-    rule.required().custom((slug) => {
-      if (!slug?.current) return "Required";
-      if (!/^[a-z0-9-]+$/.test(slug.current)) {
-        return "Slug must be lowercase with hyphens only";
-      }
-      return true;
-    }),
-});
-```
-
-### Cross-Field Validation
-
-```typescript
-defineField({
-  name: "endDate",
-  type: "datetime",
-  validation: (rule) =>
-    rule.custom((endDate, context) => {
-      const startDate = context.document?.startDate;
-      if (startDate && endDate && new Date(endDate) < new Date(startDate)) {
-        return "End date must be after start date";
-      }
-      return true;
-    }),
-});
-```
-
-### Array Validation
-
-```typescript
-defineField({
-  name: "tags",
-  type: "array",
-  of: [{ type: "string" }],
-  validation: (rule) =>
-    rule
-      .min(1)
-      .error("Add at least one tag")
-      .max(10)
-      .warning("Too many tags may hurt SEO")
-      .unique(),
-});
-```
-
-### Async Validation (Uniqueness Check)
-
-```typescript
-defineField({
-  name: "slug",
-  type: "slug",
-  validation: (rule) =>
-    rule.required().custom(async (slug, context) => {
-      if (!slug?.current) return true;
-
-      const client = context.getClient({ apiVersion: "2026-02-01" });
-      const id = context.document?._id?.replace(/^drafts\./, "");
-
-      const existing = await client.fetch(
-        `count(*[_type == "post" && slug.current == $slug && _id != $id])`,
-        { slug: slug.current, id },
-      );
-
-      return existing === 0 || "Slug already exists";
-    }),
-});
-```

.github/skills/sanity-best-practices/references/seo.md

@@ -1,340 +0,0 @@
----
-title: Sanity SEO Best Practices
-description: SEO best practices for Sanity with Next.js, including metadata, Open Graph, sitemaps, redirects, and JSON-LD structured data.
----
-
-# Sanity SEO Best Practices
-
-## 1. Core Philosophy
-
-SEO doesn't require complex configurations. A few core principles, applied consistently:
-
-- **Smart defaults with optional overrides** — Don't require SEO fields; use existing content as fallback
-- **Use GROQ for fallback logic** — Move conditional logic into queries, not components
-- **Leverage Next.js APIs** — Use `generateMetadata`, `sitemap.ts`, not manual `<meta>` tags
-- **Structured content = structured data** — Your content model is already SEO-ready
-
-## 2. SEO Schema Type (Reusable)
-
-Create a reusable SEO object type for consistent metadata across document types.
-
-```typescript
-// schemaTypes/seoType.ts
-import { defineField, defineType } from "sanity";
-
-export const seoType = defineType({
-  name: "seo",
-  title: "SEO",
-  type: "object",
-  fields: [
-    defineField({
-      name: "title",
-      description: "Overrides the page title if provided",
-      type: "string",
-    }),
-    defineField({
-      name: "description",
-      type: "text",
-      rows: 3,
-    }),
-    defineField({
-      name: "image",
-      description: "Image for social sharing (1200x630 recommended)",
-      type: "image",
-      options: { hotspot: true },
-    }),
-    defineField({
-      name: "noIndex",
-      description: "Hide this page from search engines",
-      type: "boolean",
-      initialValue: false,
-    }),
-  ],
-});
-```
-
-**Usage in document types:**
-
-```typescript
-defineField({
-  name: "seo",
-  type: "seo",
-});
-```
-
-## 3. GROQ Queries with Fallbacks
-
-Use `coalesce()` to provide fallback values. This keeps frontend logic clean.
-
-```groq
-*[_type == "page" && slug.current == $slug][0]{
-  ...,
-  "seo": {
-    // Use SEO field if provided, otherwise fall back to main title
-    "title": coalesce(seo.title, title, ""),
-    "description": coalesce(seo.description, ""),
-    "image": seo.image,
-    "noIndex": seo.noIndex == true
-  }
-}
-```
-
-**Key principle:** `seo.title` will never be `null` — it contains either the SEO override, the page title, or empty string.
-
-## 4. Next.js Metadata (The Right Way)
-
-Use `generateMetadata` — never render `<title>` or `<meta>` tags directly in components.
-
-```typescript
-// app/(frontend)/[slug]/page.tsx
-import type { Metadata } from "next";
-import { urlFor } from "@/sanity/lib/image";
-
-type RouteProps = {
-  params: Promise<{ slug: string }>;
-};
-
-// Extract fetch to reuse in both functions
-const getPage = async (params: RouteProps["params"]) =>
-  sanityFetch({
-    query: PAGE_QUERY,
-    params: await params,
-    stega: false, // Critical for SEO!
-  });
-
-export async function generateMetadata({
-  params,
-}: RouteProps): Promise<Metadata> {
-  const { data: page } = await getPage(params);
-
-  if (!page) return {};
-
-  const metadata: Metadata = {
-    title: page.seo.title,
-    description: page.seo.description,
-  };
-
-  // Open Graph image
-  if (page.seo.image) {
-    metadata.openGraph = {
-      images: {
-        url: urlFor(page.seo.image).width(1200).height(630).url(),
-        width: 1200,
-        height: 630,
-      },
-    };
-  }
-
-  // noIndex robots directive
-  if (page.seo.noIndex) {
-    metadata.robots = "noindex";
-  }
-
-  return metadata;
-}
-
-export default async function Page({ params }: RouteProps) {
-  const { data: page } = await getPage(params);
-  // ... render page
-}
-```
-
-**Critical:** Always set `stega: false` when fetching for metadata. Stega characters in `<title>` destroy SEO.
-
-## 5. Dynamic Sitemap
-
-Use Next.js `sitemap.ts` convention to auto-generate from Sanity content.
-
-### GROQ Query
-
-```groq
-*[_type in ["page", "post"] && defined(slug.current) && seo.noIndex != true] {
-  "href": select(
-    _type == "page" => "/" + slug.current,
-    _type == "post" => "/posts/" + slug.current,
-    slug.current
-  ),
-  _updatedAt
-}
-```
-
-### Route Implementation
-
-```typescript
-// app/sitemap.ts
-import { MetadataRoute } from "next";
-import { client } from "@/sanity/lib/client";
-import { SITEMAP_QUERY } from "@/sanity/lib/queries";
-
-export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
-  const baseUrl = process.env.VERCEL_URL
-    ? `https://${process.env.VERCEL_URL}`
-    : "http://localhost:3000";
-
-  try {
-    const paths = await client.fetch(SITEMAP_QUERY);
-    if (!paths) return [];
-
-    return paths.map((path) => ({
-      url: new URL(path.href!, baseUrl).toString(),
-      lastModified: new Date(path._updatedAt),
-      changeFrequency: "weekly",
-      priority: 1,
-    }));
-  } catch (error) {
-    console.error("Sitemap generation failed:", error);
-    return [];
-  }
-}
-```
-
-**Note:** Sitemap limit is 50,000 URLs per file. For larger sites, use sitemap index.
-
-## 6. Redirects (Managed in Sanity)
-
-Create a redirect document type for content team management.
-
-### Schema
-
-```typescript
-// schemaTypes/redirectType.ts
-import { LinkIcon } from "@sanity/icons";
-import { SanityDocumentLike, defineField, defineType } from "sanity";
-
-function isValidPath(value: string | undefined) {
-  if (!value) return "Required";
-  if (!value.startsWith("/")) return "Must start with /";
-  if (/[^a-zA-Z0-9\-_/:]/.test(value)) return "Invalid characters";
-  return true;
-}
-
-export const redirectType = defineType({
-  name: "redirect",
-  title: "Redirect",
-  type: "document",
-  icon: LinkIcon,
-  validation: (Rule) =>
-    Rule.custom((doc: SanityDocumentLike | undefined) => {
-      if (doc?.source === doc?.destination) {
-        return "Source and destination cannot be the same";
-      }
-      return true;
-    }),
-  fields: [
-    defineField({
-      name: "source",
-      type: "string",
-      validation: (Rule) => Rule.required().custom(isValidPath),
-    }),
-    defineField({
-      name: "destination",
-      type: "string",
-      validation: (Rule) => Rule.required(),
-    }),
-    defineField({
-      name: "permanent",
-      description: "301 (permanent) or 302 (temporary)",
-      type: "boolean",
-      initialValue: true,
-    }),
-    defineField({
-      name: "isEnabled",
-      type: "boolean",
-      initialValue: true,
-    }),
-  ],
-});
-```
-
-### Next.js Config
-
-```typescript
-// next.config.ts
-import { fetchRedirects } from "@/sanity/lib/fetchRedirects";
-
-const nextConfig: NextConfig = {
-  async redirects() {
-    return await fetchRedirects();
-  },
-};
-```
-
-**Limits:** Vercel allows max 1,024 redirects in `next.config`. For more, use middleware.
-
-## 7. Dynamic Open Graph Images
-
-Generate OG images on-the-fly using Next.js Edge Runtime at `/api/og`.
-
-```typescript
-// app/api/og/route.tsx
-import { ImageResponse } from "next/og";
-export const runtime = "edge";
-
-export async function GET(request: Request) {
-  const id = new URL(request.url).searchParams.get("id");
-  if (!id) return new Response("Missing id", { status: 400 });
-
-  const data = await client.fetch(`*[_id == $id][0]{ title }`, { id });
-
-  return new ImageResponse(
-    <div tw="flex w-full h-full bg-blue-500 text-white p-10">
-      <h1 tw="text-6xl font-bold">{data?.title || "Untitled"}</h1>
-    </div>,
-    { width: 1200, height: 630 }
-  );
-}
-```
-
-Use as fallback in metadata: `url: page.seo.image ? urlFor(page.seo.image).url() : \`/api/og?id=\${page.\_id}\``
-
-## 8. JSON-LD Structured Data
-
-Use `schema-dts` for type-safe structured data.
-
-```bash
-npm install schema-dts
-```
-
-### FAQ Example
-
-```typescript
-import { FAQPage, WithContext } from "schema-dts";
-
-const generateFaqData = (faqs: FAQ[]): WithContext<FAQPage> => ({
-  "@context": "https://schema.org",
-  "@type": "FAQPage",
-  mainEntity: faqs.map((faq) => ({
-    "@type": "Question",
-    name: faq.title,
-    acceptedAnswer: {
-      "@type": "Answer",
-      text: faq.text, // Use pt::text() in GROQ to get plain text
-    },
-  })),
-});
-
-// In component
-<script
-  type="application/ld+json"
-  dangerouslySetInnerHTML={{ __html: JSON.stringify(generateFaqData(faqs)) }}
-/>
-```
-
-### GROQ for Plain Text
-
-```groq
-faqs[]->{
-  _id,
-  title,
-  body,
-  "text": pt::text(body)  // Convert Portable Text to plain string
-}
-```
-
-## 9. Testing Tools
-
-- **Open Graph:** [opengraph.ing](https://opengraph.ing/)
-- **Facebook:** [Sharing Debugger](https://developers.facebook.com/tools/debug/)
-- **Twitter:** [Card Validator](https://cards-dev.twitter.com/validator)
-- **LinkedIn:** [Post Inspector](https://www.linkedin.com/post-inspector/)
-- **Sitemap:** [XML Sitemaps Validator](https://www.xml-sitemaps.com/validate-xml-sitemap.html)

.github/skills/sanity-best-practices/references/studio-structure.md

@@ -1,146 +0,0 @@
----
-title: "Sanity Studio Structure Rules"
-description: Rules for customizing the Sanity Studio Structure (S.structure).
----
-
-# Sanity Studio Structure Rules
-
-## 1. Setup
-
-Custom structure is defined in `sanity.config.ts` using the `structureTool`.
-
-```typescript
-import { structureTool } from "sanity/structure";
-import { structure } from "./src/structure";
-
-export default defineConfig({
-  // ...
-  plugins: [structureTool({ structure })],
-});
-```
-
-## 2. Structure Definition
-
-**Location:** `src/structure/index.ts`
-
-Use a function that receives `S` (StructureBuilder).
-
-```typescript
-import type { StructureResolver } from "sanity/structure";
-
-export const structure: StructureResolver = (S) =>
-  S.list().title("Content").items([
-    // ... items
-  ]);
-```
-
-## 3. Organization Principles
-
-1.  **Singletons First:** Place critical site-wide settings (Global Settings, Homepage) at the top.
-2.  **Dividers:** Use `S.divider()` to visually separate logical groups.
-3.  **Filtered Lists:** Always exclude Singleton documents from generic `documentTypeList` items to avoid duplication.
-
-## 4. Singleton Pattern (Critical)
-
-**Singletons are enforced via Structure, NOT schema options.** There is no `singleton: true` schema option.
-
-This is the main case where explicit document IDs are appropriate. For ordinary content documents, let Sanity generate `_id` values and use references or GROQ lookups to connect records.
-
-### How Singletons Work
-
-1. Use `S.document().documentId('fixed-id')` to lock the document to a specific ID.
-2. Filter the type from generic lists to prevent duplicate entries.
-
-### Singleton Helper Function
-
-```typescript
-// Helper to create singleton list items
-function createSingleton(
-  S: StructureBuilder,
-  typeName: string,
-  title: string,
-  icon?: ComponentType,
-) {
-  return S.listItem().title(title).icon(icon).child(
-    S.document()
-      .schemaType(typeName)
-      .documentId(typeName) // Fixed ID = singleton
-      .title(title),
-  );
-}
-
-// Usage
-createSingleton(S, "settings", "Site Settings", CogIcon);
-```
-
-### Querying Singletons
-
-```groq
-// By fixed ID (most efficient)
-*[_id == "settings"][0]
-
-// By type (works but slower)
-*[_type == "settings"][0]
-```
-
-**For localized singletons** (e.g., homepage per language), see `localization.md` Section 6.
-
-## 5. Implementation Pattern
-
-```typescript
-// Define singleton types to exclude from generic lists
-const SINGLETONS = ["settings", "homePage"];
-
-export const structure: StructureResolver = (S) =>
-  S.list()
-    .title("Website Content")
-    .items([
-      // 1. Singletons
-      S.listItem()
-        .title("Site Settings")
-        .icon(CogIcon)
-        .child(S.document().schemaType("settings").documentId("settings")),
-
-      S.divider(),
-
-      // 2. Content Verticals
-      S.listItem()
-        .title("Blog")
-        .child(
-          S.list()
-            .title("Blog Content")
-            .items([
-              S.documentTypeListItem("post").title("Posts"),
-              S.documentTypeListItem("author").title("Authors"),
-            ]),
-        ),
-
-      S.divider(),
-
-      // 3. Remaining Documents (Filtered)
-      ...S.documentTypeListItems().filter(
-        (listItem) => !SINGLETONS.includes(listItem.getId() as string),
-      ),
-    ]);
-```
-
-## 6. Views (Split Pane)
-
-Add "Web Preview" or other views to documents.
-
-```typescript
-export const defaultDocumentNode: DefaultDocumentNodeResolver = (
-  S,
-  { schemaType },
-) => {
-  switch (schemaType) {
-    case `post`:
-      return S.document().views([
-        S.view.form(), // Default form
-        S.view.component(PreviewComponent).title("Preview"), // Custom view
-      ]);
-    default:
-      return S.document().views([S.view.form()]);
-  }
-};
-```

.github/skills/sanity-best-practices/references/svelte.md

@@ -1,340 +0,0 @@
----
-title: "SvelteKit & Sanity Integration Rules"
-description: Integration guide for SvelteKit with Sanity using @sanity/sveltekit, including Visual Editing and Preview Mode.
----
-
-# SvelteKit & Sanity Integration Rules
-
-This guide uses the official **`@sanity/sveltekit`** package (Svelte 5 + SvelteKit 2). The older `@sanity/svelte-loader` does not work with Svelte 5 — its `useQuery` store returns empty on the client. Use `@sanity/sveltekit` instead.
-
-## 1. Setup & Configuration
-
-### Scaffold a new SvelteKit app
-
-```bash
-npx sv@latest create my-app --template minimal --types ts --no-add-ons --install npm
-cd my-app
-```
-
-`--template minimal` is the bare app. `--types ts` enables TypeScript. `--no-add-ons` skips the add-on picker. `--install <pm>` chooses the package manager (`npm`, `pnpm`, `yarn`, or `bun`).
-
-### Installation
-
-```bash
-npm install @sanity/sveltekit @sanity/image-url @portabletext/svelte
-```
-
-`@sanity/sveltekit` is the one-stop integration: it bundles `@sanity/client`, `@sanity/visual-editing`, `@sanity/core-loader`, `groq`, and friends, and re-exports `createClient`, `defineQuery`, `groq`, and `stegaClean`. **Do not** also install `@sanity/client`, `@sanity/visual-editing`, or `groq` directly — import them from `@sanity/sveltekit`. `@sanity/image-url` and `@portabletext/svelte` are not bundled, so add them separately.
-
-### Environment variables (`.env.local`)
-
-```bash
-PUBLIC_SANITY_PROJECT_ID=your-project-id
-PUBLIC_SANITY_DATASET=production
-PUBLIC_SANITY_API_VERSION=2026-05-15
-PUBLIC_SANITY_STUDIO_URL=http://localhost:3333
-SANITY_API_READ_TOKEN=
-```
-
-SvelteKit's `$env/static/public` requires the `PUBLIC_` prefix for any var read on the client. `SANITY_API_READ_TOKEN` must be declared (even empty) if any file imports it from `$env/static/private`, otherwise Vite throws at build time.
-
-## 2. Files
-
-### `src/lib/sanity/api.ts` — env var resolution
-
-```ts
-import {
-  PUBLIC_SANITY_API_VERSION,
-  PUBLIC_SANITY_DATASET,
-  PUBLIC_SANITY_PROJECT_ID,
-  PUBLIC_SANITY_STUDIO_URL,
-} from "$env/static/public";
-
-function assertEnvVar<T>(value: T | undefined, name: string): T {
-  if (value === undefined || value === "") {
-    throw new Error(`Missing environment variable: ${name}`);
-  }
-  return value;
-}
-
-export const dataset = assertEnvVar(
-  PUBLIC_SANITY_DATASET,
-  "PUBLIC_SANITY_DATASET",
-);
-export const projectId = assertEnvVar(
-  PUBLIC_SANITY_PROJECT_ID,
-  "PUBLIC_SANITY_PROJECT_ID",
-);
-export const apiVersion = PUBLIC_SANITY_API_VERSION || "2026-05-15";
-export const studioUrl = PUBLIC_SANITY_STUDIO_URL || "http://localhost:3333";
-```
-
-### `src/lib/sanity/client.ts` — public client
-
-```ts
-import { apiVersion, dataset, projectId, studioUrl } from "$lib/sanity/api";
-import { createClient } from "@sanity/sveltekit";
-
-export const client = createClient({
-  projectId,
-  dataset,
-  apiVersion,
-  useCdn: true,
-  stega: { studioUrl },
-});
-```
-
-Import `createClient` from `@sanity/sveltekit`, not `@sanity/client`. `useCdn: true` is for production reads; the server (preview) client below overrides to `false`.
-
-### `src/lib/sanity/client.server.ts` — server (preview) client
-
-```ts
-import { SANITY_API_READ_TOKEN } from "$env/static/private";
-import { client } from "$lib/sanity/client";
-
-export const serverClient = client.withConfig({
-  token: SANITY_API_READ_TOKEN,
-  useCdn: false,
-  stega: true,
-});
-```
-
-### `src/lib/sanity/queries.ts` — queries + types
-
-```ts
-import { groq } from "@sanity/sveltekit";
-
-export const postsQuery = groq`*[_type == "post" && defined(slug.current)] | order(_createdAt desc){
-  _id, _createdAt, title, slug, excerpt, mainImage, body
-}`;
-
-export const postQuery = groq`*[_type == "post" && slug.current == $slug][0]{
-  _id, _createdAt, title, slug, excerpt, mainImage, body
-}`;
-
-export interface Post {
-  _id: string;
-  _createdAt: string;
-  title?: string;
-  slug: { current: string };
-  excerpt?: string;
-  mainImage?: unknown;
-  body?: unknown[];
-}
-```
-
-Use `defineQuery` instead of `groq` if you want TypeGen-friendly query definitions; both are re-exported from `@sanity/sveltekit`.
-
-### `src/lib/sanity/image.ts` — image URL builder
-
-```ts
-import { createImageUrlBuilder } from "@sanity/image-url";
-import { client } from "./client";
-
-const builder = createImageUrlBuilder(client);
-
-export function urlFor(source: unknown) {
-  return builder.image(source as never);
-}
-```
-
-Use the named `createImageUrlBuilder` export; the default export logs a deprecation warning at runtime.
-
-## 3. Hooks & Locals
-
-### `src/hooks.server.ts` — wire preview + query loader
-
-```ts
-import { serverClient } from "$lib/sanity/client.server";
-import {
-  handlePreviewMode,
-  handleQueryLoader,
-  setServerClient,
-} from "@sanity/sveltekit";
-import { redirect } from "@sveltejs/kit";
-import { sequence } from "@sveltejs/kit/hooks";
-
-setServerClient(serverClient);
-
-export const handle = sequence(
-  handlePreviewMode({
-    client: serverClient,
-    preview: { redirect },
-  }),
-  handleQueryLoader(),
-);
-```
-
-`handlePreviewMode` installs `/preview/enable` and `/preview/disable` endpoints, reads the preview cookie, and populates `locals.sanity` with `{client, fetch, loadQuery, previewEnabled, previewPerspective, browserToken}`. `handleQueryLoader` attaches `loadQuery` to `locals.sanity` for use in `+page.server.ts` / `+layout.server.ts`.
-
-### `src/app.d.ts` — typed locals
-
-```ts
-import type { SanityLocals } from "@sanity/sveltekit";
-
-declare global {
-  namespace App {
-    interface Locals extends SanityLocals {}
-  }
-}
-
-export {};
-```
-
-## 4. Layout: Preview + Visual Editing Providers
-
-### `src/routes/+layout.server.ts` — propagate previewEnabled
-
-```ts
-import type { LayoutServerLoad } from "./$types";
-
-export const load: LayoutServerLoad = (event) => {
-  const { previewEnabled } = event.locals.sanity;
-  return { previewEnabled };
-};
-```
-
-### `src/routes/+layout.svelte` — wrap children in providers (Svelte 5)
-
-```svelte
-<script lang="ts">
-  import {PreviewMode, QueryLoader, VisualEditing} from '@sanity/sveltekit'
-  import type {LayoutProps} from './$types'
-  import {client} from '$lib/sanity/client'
-  const {children, data}: LayoutProps = $props()
-  // svelte-ignore state_referenced_locally
-  const {previewEnabled} = data
-</script>
-
-<PreviewMode enabled={previewEnabled}>
-  <VisualEditing enabled={previewEnabled}>
-    <QueryLoader enabled={previewEnabled} {client}>
-      {@render children()}
-    </QueryLoader>
-  </VisualEditing>
-</PreviewMode>
-```
-
-Svelte 5 idioms here are mandatory:
-
-- `const {children, data} = $props()` — not `export let data`.
-- `{@render children()}` — not `<slot />`.
-- The `svelte-ignore state_referenced_locally` comment silences a warning about destructuring reactive props at module scope.
-
-`<VisualEditing>` dynamically imports its component only when `enabled === true`, so a preview-off app never loads the React-Compiler-runtime chunk.
-
-## 5. Data Fetching (Loaders + `useQuery`)
-
-### Posts list
-
-`src/routes/+page.server.ts`:
-
-```ts
-import { type Post, postsQuery as query } from "$lib/sanity/queries";
-import type { PageServerLoad } from "./$types";
-
-export const load: PageServerLoad = async ({ locals }) => {
-  const { loadQuery } = locals.sanity;
-  const initial = await loadQuery<Post[]>(query);
-  return { query, options: { initial } };
-};
-```
-
-The return shape `{query, params?, options: {initial}}` is what `useQuery(data)` on the client expects — don't change the field names.
-
-`src/routes/+page.svelte`:
-
-```svelte
-<script lang="ts">
-  import {useQuery} from '@sanity/sveltekit'
-  import type {Post} from '$lib/sanity/queries'
-  import type {PageProps} from './$types'
-
-  const {data}: PageProps = $props()
-  const query = $derived(useQuery<Post[]>(data))
-  const posts = $derived($query.data)
-</script>
-
-<h1>Posts</h1>
-{#if posts?.length}
-  <ul>
-    {#each posts as post (post._id)}
-      <li><a href={`/post/${post.slug.current}`}>{post.title}</a></li>
-    {/each}
-  </ul>
-{:else}
-  <p>No posts yet.</p>
-{/if}
-```
-
-Critical Svelte 5 pattern:
-
-- `useQuery` returns a Svelte Readable store. Wrap in `$derived(useQuery(data))` so the store reference stays current across reactive updates.
-- Subscribe via `$query` (Svelte's auto-subscription) and read `.data`.
-- Works on both SSR and client.
-
-### Post detail (`[slug]`)
-
-`src/routes/post/[slug]/+page.server.ts`:
-
-```ts
-import { type Post, postQuery as query } from "$lib/sanity/queries";
-import type { PageServerLoad } from "./$types";
-
-export const load: PageServerLoad = async ({ locals, params }) => {
-  const { loadQuery } = locals.sanity;
-  const { slug } = params;
-  const initial = await loadQuery<Post>(query, { slug });
-  return { query, params: { slug }, options: { initial } };
-};
-```
-
-`src/routes/post/[slug]/+page.svelte`:
-
-```svelte
-<script lang="ts">
-  import {useQuery} from '@sanity/sveltekit'
-  import {PortableText} from '@portabletext/svelte'
-  import {urlFor} from '$lib/sanity/image'
-  import type {Post} from '$lib/sanity/queries'
-  import type {PageProps} from './$types'
-
-  const {data}: PageProps = $props()
-  const query = $derived(useQuery<Post>(data))
-  const post = $derived($query.data)
-</script>
-
-{#if post}
-  <article>
-    <h1>{post.title}</h1>
-    {#if post.mainImage}
-      <img src={urlFor(post.mainImage).width(800).url()} alt={post.title ?? ''} />
-    {/if}
-    {#if post.body}
-      <PortableText value={post.body} />
-    {/if}
-  </article>
-{:else}
-  <p>Post not found.</p>
-{/if}
-```
-
-## 6. Stega Cleaning
-
-When using fetched strings for logic (routing, classNames), strip the stega markers first.
-
-```ts
-import { stegaClean } from "@sanity/sveltekit";
-
-// …
-if (stegaClean(slug) === "home") {
-  /* … */
-}
-```
-
-## 7. Caveats
-
-- **Yarn classic + Visual Editing.** `@sanity/visual-editing` lazy-loads a chunk that imports `react/compiler-runtime`. Yarn classic doesn't auto-install peer deps, so users who flip preview mode on with yarn classic also need `yarn add react react-dom`. (Other package managers handle this automatically.) `<VisualEditing>` only loads this chunk when `enabled === true`, so a default preview-off app is unaffected.
-- **No `<slot />`.** Svelte 5 layouts use `{@render children()}`.
-- **No `export let`.** Pages and components use `const {data} = $props()`.
-- **`@sanity/image-url` default export.** Use the named `createImageUrlBuilder`; the default export still works but logs a runtime deprecation warning.

.github/skills/sanity-best-practices/references/typegen.md

@@ -1,234 +0,0 @@
----
-title: Sanity TypeGen Rules
-description: Workflow for generating TypeScript types from Sanity Schema and GROQ queries.
----
-
-# Sanity TypeGen Rules
-
-## 1. The Workflow
-
-Sanity TypeGen generates TypeScript types from your schema and GROQ queries. Types can be generated automatically or manually.
-
-### Automatic (Recommended)
-
-Enable in `sanity.cli.ts` — types regenerate during `sanity dev` and `sanity build`:
-
-```typescript
-// sanity.cli.ts
-import { defineCliConfig } from "sanity/cli";
-
-export default defineCliConfig({
-  typegen: {
-    enabled: true,
-  },
-});
-```
-
-### Manual
-
-Run the extract + generate cycle whenever schema or queries change:
-
-1.  **Extract:** Converts your Schema (TS/JS) into a static JSON representation.
-2.  **Generate:** Scans your codebase for GROQ queries and generates TypeScript types.
-
-```bash
-npx sanity schema extract && npx sanity typegen generate
-```
-
-### Watch Mode (for separate frontends)
-
-If your frontend is in a separate repo from the Studio, use watch mode:
-
-```bash
-npx sanity typegen generate --watch
-```
-
-## 2. The "Update Types" Pattern
-
-For manual workflows, implement a single script:
-
-**package.json:**
-
-```json
-"scripts": {
-  "typegen": "sanity schema extract && sanity typegen generate"
-}
-```
-
-### Git Strategy for Generated Files
-
-**Option A: Commit generated types (Recommended for most teams)**
-
-- Types available immediately after `git pull`
-- CI/CD doesn't need to run typegen
-- Can cause merge conflicts
-
-**Option B: Generate in CI (Recommended for larger teams)**
-Add to `.gitignore`:
-
-```gitignore
-# Sanity TypeGen (generated)
-sanity.types.ts
-schema.json
-```
-
-Then ensure CI runs typegen before build:
-
-```yaml
-# Example GitHub Actions
-- run: npm run typegen
-- run: npm run build
-```
-
-## 3. Configuration (`sanity.cli.ts`)
-
-> **Note:** `sanity-typegen.json` is deprecated. Move your configuration to `sanity.cli.ts`.
-
-```typescript
-// sanity.cli.ts
-import { defineCliConfig } from "sanity/cli";
-
-export default defineCliConfig({
-  typegen: {
-    enabled: true, // Auto-generate during sanity dev/build
-    path: "./src/**/*.{ts,tsx,js,jsx,astro,svelte,vue}", // Glob to find queries
-    schema: "schema.json", // Schema file from extract
-    generates: "./sanity.types.ts", // Output file
-    overloadClientMethods: true, // Auto-type client.fetch() calls
-  },
-});
-```
-
-### Project Structure Examples
-
-**Monorepo (recommended)** (Studio in `studio/`, Frontend in `web/` — same config works under `apps/`):
-
-```typescript
-export default defineCliConfig({
-  typegen: {
-    path: "../web/src/**/*.{ts,tsx,js,jsx}",
-    schema: "schema.json",
-    generates: "../web/sanity.types.ts",
-  },
-});
-```
-
-**Single Repo / Embedded Studio (legacy):**
-Use defaults — no extra config needed.
-
-**Separate Repos:**
-Use `--watch` mode in your frontend: `sanity typegen generate --watch`
-
-## 4. Usage in Code
-
-### Automatic Type Inference (Recommended)
-
-With `overloadClientMethods: true` (default), `client.fetch()` automatically returns typed results when you use `defineQuery`:
-
-```typescript
-import { defineQuery } from "groq";
-import { createClient } from "@sanity/client";
-
-const client = createClient({...});
-
-const POSTS_QUERY = defineQuery(`*[_type == "post"]{ title, slug }`);
-
-// Return type is automatically inferred — no manual type import needed!
-const posts = await client.fetch(POSTS_QUERY);
-```
-
-### Manual Type Import (Alternative)
-
-You can also import generated types directly:
-
-```typescript
-import { defineQuery } from "groq";
-// Next.js re-exports defineQuery for convenience:
-// import { defineQuery } from "next-sanity";
-
-const AUTHOR_QUERY = defineQuery(`*[_type == "author" && slug.current == $slug][0]{ name, bio }`);
-
-import type { AUTHOR_QUERYResult } from "@/sanity.types";
-
-export default function Author({ data }: { data: AUTHOR_QUERYResult }) {
-  return <h1>{data.name}</h1>
-}
-```
-
-### Required Fields
-
-Use `--enforce-required-fields` during extraction to translate `validation: rule => rule.required()` into non-optional types:
-
-```bash
-npx sanity schema extract --enforce-required-fields
-npx sanity typegen generate
-```
-
-> **Warning:** If you use draft previews, fields may still be `undefined` even with required validation, since drafts can be in an invalid state.
-
-### Type Utilities
-
-TypeGen provides utilities for working with complex types:
-
-```typescript
-import type { FilterByType, Get } from "sanity";
-import type { Page, PageBuilder } from "./sanity.types";
-
-// Extract deeply nested type (up to 20 levels)
-type HeroSection = Get<Page, "sections", number, "hero">;
-
-// Filter specific types from unions using _type discriminator
-type HeroBlock = FilterByType<PageBuilder, "hero">;
-```
-
-### Unique Query Names
-
-All queries must have unique variable names. Duplicate names across files will cause TypeGen to silently overwrite types. Use descriptive, scoped names:
-
-```typescript
-// Unique names
-const POSTS_INDEX_QUERY = defineQuery(`*[_type == "post"]{ title }`)
-const POST_DETAIL_QUERY = defineQuery(`*[_type == "post" && slug.current == $slug][0]`)
-
-// Duplicate names will conflict
-const QUERY = defineQuery(`*[_type == "post"]`)  // file-a.ts
-const QUERY = defineQuery(`*[_type == "author"]`) // file-b.ts — overwrites!
-```
-
-### Supported Query Formats
-
-Queries must be assigned to a variable using `groq` or `defineQuery`:
-
-```typescript
-// Works — groq template tag
-const query = groq`*[_type == "post"]`
-
-// Works — defineQuery
-const query = defineQuery(`*[_type == "post"]`)
-
-// Won't work — inline query
-await client.fetch(groq`*[_type == "post"]`)
-```
-
-### Supported File Types
-
-TypeGen parses queries from: `.ts`, `.tsx`, `.js`, `.jsx`, `.astro`, `.svelte`, `.vue`
-
-### tsconfig Requirements
-
-Ensure `sanity.types.ts` is included in your `tsconfig.json`'s `include` array. If your config restricts includes (e.g., `["src/**/*"]`) and the types file is at the project root, TypeScript won't pick up the generated types:
-
-```json
-{
-  "include": ["src/**/*", "sanity.types.ts"]
-}
-```
-
-### Skipping Individual Queries
-
-Add `@sanity-typegen-ignore` in a comment before a query to skip type generation:
-
-```typescript
-// @sanity-typegen-ignore
-const debugQuery = groq`*[_type == "debug"]`;
-```

.github/skills/sanity-best-practices/references/visual-editing.md

@@ -1,279 +0,0 @@
----
-title: "Sanity Visual Editing Rules"
-description: Comprehensive guide for Sanity Visual Editing, including Presentation Tool, Stega (Content Source Maps), and Overlays.
----
-
-# Sanity Visual Editing Rules
-
-## 1. Concepts
-
-### Presentation Tool
-
-The Studio plugin (`sanity/presentation`) that renders your front-end application inside an iframe in the Studio. It enables the "Edit" overlay and bidirectional navigation.
-
-### Content Source Maps (Stega)
-
-Invisible characters embedded in strings that tell the Presentation Tool which field in which document the content comes from.
-
-- **Mechanism:** Sanity encodes document ID, field path, and dataset info into string values.
-- **Result:** Click-to-edit functionality in the preview.
-
-### Loaders
-
-Framework-agnostic or specific libraries that handle:
-
-1.  Fetching data (production vs. preview).
-2.  Subscribing to real-time updates (Live Content API).
-3.  Encoding Stega strings (if not handled by the Content Lake automatically).
-
-## 2. The Golden Rule of Stega (Clean Data)
-
-When Visual Editing is enabled, string fields will contain invisible characters. You **MUST** clean them before using the value for logic.
-
-| Scenario                             | Clean? | Why                   |
-| ------------------------------------ | ------ | --------------------- |
-| Comparing strings (`if (x === 'y')`) | ✅ Yes | Stega breaks equality |
-| Using as object keys                 | ✅ Yes | Keys won't match      |
-| Using as HTML IDs                    | ✅ Yes | Invalid characters    |
-| Passing to third-party libraries     | ✅ Yes | May validate input    |
-| Rendering text (`<h1>{title}</h1>`)  | ❌ No  | Breaks click-to-edit  |
-| Passing to `<PortableText />`        | ❌ No  | Handles internally    |
-| Passing to image helpers             | ❌ No  | Handles internally    |
-
-```typescript
-import { stegaClean } from "@sanity/client/stega";
-
-export function Layout({ align }: { align: string }) {
-  // Good: Clean before comparison
-  const cleanAlign = stegaClean(align);
-  return <div className={cleanAlign === 'center' ? 'mx-auto' : ''} />
-}
-```
-
-## 3. Token Handling (Security)
-
-Store your read token in a dedicated file that throws if missing:
-
-```typescript
-// src/sanity/lib/token.ts
-export const token = process.env.SANITY_API_READ_TOKEN;
-
-if (!token) {
-  throw new Error("Missing SANITY_API_READ_TOKEN");
-}
-```
-
-**Never** expose tokens in client bundles. Pass to `defineLive` for server/browser use only when Draft Mode is enabled.
-
-## 4. Setup: Presentation Tool
-
-**File:** `sanity.config.ts`
-
-```typescript
-import { defineConfig } from "sanity";
-import { presentationTool } from "sanity/presentation";
-import { resolve } from "@/sanity/presentation/resolve";
-
-export default defineConfig({
-  // ...
-  plugins: [
-    presentationTool({
-      resolve, // Document locations (see below)
-      previewUrl: {
-        // The front-end origin — required when the Studio runs standalone
-        origin:
-          process.env.SANITY_STUDIO_PREVIEW_ORIGIN || "http://localhost:3000",
-        previewMode: {
-          enable: "/api/draft-mode/enable",
-        },
-      },
-    }),
-  ],
-});
-```
-
-### Document Locations
-
-Show where documents appear in the front-end — enables quick navigation between Structure and Presentation tools.
-
-```typescript
-// src/sanity/presentation/resolve.ts
-import {
-  PresentationPluginOptions,
-  defineLocations,
-} from "sanity/presentation";
-
-export const resolve: PresentationPluginOptions["resolve"] = {
-  locations: {
-    post: defineLocations({
-      select: { title: "title", slug: "slug.current" },
-      resolve: (doc) => ({
-        locations: [
-          { title: doc?.title || "Untitled", href: `/posts/${doc?.slug}` },
-          { title: "Posts index", href: `/posts` },
-        ],
-      }),
-    }),
-    // Add more document types as needed
-  },
-};
-```
-
-## 5. Visual Editing Overlays
-
-Render `<VisualEditing />` in Draft Mode for click-to-edit overlays.
-
-**Next.js (App Router):**
-
-```typescript
-// layout.tsx
-import { VisualEditing } from 'next-sanity/visual-editing'
-import { draftMode } from 'next/headers'
-import { DisableDraftMode } from '@/components/disable-draft-mode'
-
-export default async function RootLayout({ children }) {
-  return (
-    <html>
-      <body>
-        {children}
-        {(await draftMode()).isEnabled && (
-          <>
-            <DisableDraftMode />
-            <VisualEditing />
-          </>
-        )}
-      </body>
-    </html>
-  )
-}
-```
-
-### Disable Draft Mode Button
-
-Useful for content authors to exit preview and see published content:
-
-```typescript
-// src/components/disable-draft-mode.tsx
-'use client'
-import { useDraftModeEnvironment } from 'next-sanity/hooks'
-
-export function DisableDraftMode() {
-  const environment = useDraftModeEnvironment()
-  // Only show outside of Presentation Tool
-  if (environment !== 'live' && environment !== 'unknown') return null
-
-  return (
-    <a href="/api/draft-mode/disable" className="fixed bottom-4 right-4 bg-gray-50 px-4 py-2">
-      Disable Draft Mode
-    </a>
-  )
-}
-```
-
-**Remix/Svelte:** See framework-specific rules for `useLiveMode` and `enableVisualEditing` patterns.
-
-## 6. SEO & Metadata (Critical)
-
-**NEVER** allow Stega strings in `<head>` tags (Title, Description, Canonical URLs). It destroys SEO rankings and looks broken in search results.
-
-- **Next.js:** Set `stega: false` in `generateMetadata`.
-- **General:** Explicitly clean fields used in `<title>` or `<meta>`.
-
-```typescript
-// Next.js Example — disable stega at fetch level
-export async function generateMetadata({ params }) {
-  const { data } = await sanityFetch({
-    query: SEO_QUERY,
-    stega: false, // Critical
-  });
-  return { title: data.title };
-}
-```
-
-**Alternative:** If you can't disable stega at the fetch level, clean explicitly:
-
-```typescript
-import { stegaClean } from "@sanity/client/stega";
-
-export async function generateMetadata({ params }) {
-  const { data } = await sanityFetch({ query: PAGE_QUERY });
-  return {
-    title: stegaClean(data.title),
-    description: stegaClean(data.description),
-    openGraph: { url: stegaClean(data.canonicalUrl) },
-  };
-}
-```
-
-## 7. Drag-and-Drop Reordering (Advanced)
-
-For arrays (e.g., "Related Posts"), enable drag-and-drop in the preview using `data-sanity` attributes and `useOptimistic`:
-
-```typescript
-import { createDataAttribute } from 'next-sanity'
-import { useOptimistic } from 'next-sanity/hooks'
-
-// Add data-sanity to array container
-<ul data-sanity={createDataAttribute({ id: documentId, type: 'post', path: 'relatedPosts' }).toString()}>
-  {items.map((item) => (
-    <li key={item._key} data-sanity={createDataAttribute({
-      id: documentId, type: 'post', path: `relatedPosts[_key=="${item._key}"]`
-    }).toString()}>
-      {item.title}
-    </li>
-  ))}
-</ul>
-```
-
-**Key requirements:**
-
-- Query must include `_key` for array items
-- Use `useOptimistic` hook for instant UI updates during mutations
-
-## 8. Optimistic Updates for Faster Editing
-
-By default, editing a field in the Presentation Tool triggers a full page re-render. For pages with many components, this can feel sluggish. **Presentation queries** solve this by fetching only the specific block being edited.
-
-### The Concept
-
-Instead of:
-
-1. User edits a field -> Full page query re-runs -> All components re-render
-
-You get:
-
-1. User edits a field -> Block-specific query runs -> Only that component re-renders
-
-### How It Works
-
-1. **Create a targeted query** that fetches just the block data using `_key`:
-
-```groq
-*[_id == $documentId][0]{
-  "heroBlock": pageBuilder[_key == $blockKey && _type == "hero"][0]{
-    title, subtitle, image
-  }
-}
-```
-
-2. **Use a presentation query hook** in your component (e.g., `usePresentationQuery` in Next.js)
-
-3. **Fall back to initial props** when not in presentation mode
-
-This pattern works for both Page Builder blocks (`pageBuilder[]`) and Portable Text blocks (`body[]`).
-
-**See framework-specific rules for implementation:**
-
-- Next.js: `nextjs.md` (Section 9)
-- Page Builder: `page-builder.md` (Section 5)
-- Portable Text: `portable-text.md` (Section 7)
-
-## 9. Framework Specifics
-
-| Framework   | Loader Package          | Key Components                                               |
-| :---------- | :---------------------- | :----------------------------------------------------------- |
-| **Next.js** | `next-sanity`           | `<VisualEditing />`, `defineLive`, `usePresentationQuery`    |
-| **Remix**   | `@sanity/react-loader`  | `createQueryStore`, `useLiveMode`, `enableVisualEditing`     |
-| **Svelte**  | `@sanity/svelte-loader` | `createRequestHandler`, `useLiveMode`, `enableVisualEditing` |
-| **Nuxt**    | `@nuxtjs/sanity`        | Automatic via module config (`visualEditing: {}`)            |
-| **Astro**   | `@sanity/astro`         | `sanity({ useCdn: false, stega: true })`                     |

.github/skills/website-example/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: website-example
+description: >
+  Add or update a code example or template shown on aksel.nav.no
+  (aksel.nav.no/website/pages/eksempler/** or pages/templates/**). Use when
+  asked to create a component example, demo, usage snippet or page template
+  for the documentation site, or when an example fails the aksel-local ESLint
+  rules or validate:eksempler.
+argument-hint: "Component group and example name, e.g. button/loading"
+---
+
+# Website example
+
+Examples are public copy-paste snippets. The code above the marker comment is shown verbatim on the site and opened in the sandbox.
+
+## 1. Locate
+
+- Component examples: `aksel.nav.no/website/pages/eksempler/<group>/<example-name>.tsx` (group = lowercase component, e.g. `lookup`).
+- Page templates: `aksel.nav.no/website/pages/templates/<name>/...`.
+- Read 1-2 sibling examples in the same group first and match their tone. Content is in Norwegian (bokmål).
+
+## 2. Write the file
+
+```tsx
+import { Button } from "@navikt/ds-react";
+import { withDsExample } from "@/web/examples/withDsExample";
+
+const Example = () => {
+  return <Button>Lagre</Button>;
+};
+
+// EXAMPLES DO NOT INCLUDE CONTENT BELOW THIS LINE
+export default withDsExample(Example);
+
+/* Storybook story */
+export const Demo = {
+  render: Example,
+};
+
+export const args: ExampleArgsT = {
+  index: 0,
+  desc: "Kort hint om når eksemplet brukes.",
+};
+```
+
+Hard rules (enforced by `tooling/eslint` rules `aksel-local/*`):
+
+- With the sandbox enabled (default), import only from `@navikt/*`, `react`, relative `../__parts*` helpers and exactly `@/web/examples/withDsExample`. Anything else breaks the "open in sandbox" button. Set `sandbox: false` in `args` only if it's unavoidable.
+- The demo component must be named `Example` (the sandbox depends on it).
+- The marker comment `// EXAMPLES DO NOT INCLUDE CONTENT BELOW THIS LINE` sits directly above `export default`.
+- `export const args: ExampleArgsT` with `index` (sort order within the group). Optional: `desc`, `title`, `sandbox: false`.
+- `withDsExample(Example, { variant: "static" | ... })`: see its JSDoc for layout options.
+
+## 3. Validate
+
+```sh
+corepack yarn eslint --max-warnings=0 --no-warn-ignored <file>
+corepack yarn workspace website validate:eksempler
+corepack yarn storybook:aksel   # visual check at :6007, needs no secrets
+```
+
+Never run `update:eksempler`. It writes to the Sanity CMS. Tell the user that a maintainer syncs examples to Sanity and links a new group from the component page.
+
+## Done when
+
+ESLint and `validate:eksempler` pass, and the story renders in `storybook:aksel`.

.github/workflows/release.yml

@@ -12,15 +12,15 @@ on:
 concurrency: ${{ github.workflow }}-${{ github.ref }}
 
 jobs:
-  build:
-    name: Release packages
+  version:
+    name: Create release Pull Request
     if: ${{ !contains(github.event.head_commit.message, '[ci skip]') }}
     runs-on: ubuntu-latest
     permissions:
-      id-token: "write"
       contents: "write"
-      packages: "write"
       pull-requests: "write"
+    outputs:
+      has-changesets: ${{ steps.changesets.outputs.has-changesets }}
     steps:
       - name: Checkout code
         uses: actions/checkout@v7
@@ -39,40 +39,60 @@ jobs:
         env:
           NPM_AUTH_TOKEN: ${{ secrets.READER_TOKEN }}
 
-      - name: Create release Pull Request or publish to NPM
+      # Without `publish-script` the action only creates/updates the release PR
+      - name: Create or update release Pull Request
         id: changesets
-        uses: changesets/action@v1
+        uses: changesets/action@v2
         with:
-          version: yarn create-version
-          publish: yarn release
-          createGithubReleases: false
+          version-script: yarn create-version
         env:
-          # Use OIDC for npm authentication instead of NPM_TOKEN
-          # https://github.com/changesets/changesets/issues/1152#issuecomment-3190884868
-          NPM_TOKEN: ""
-          # Needed for push to main
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          github-token: ${{ secrets.GITHUB_TOKEN }}
 
-      - name: Create .npmrc for GPR
-        run: |
-          cat << EOF > "$HOME/.npmrc"
-            @navikt:registry=https://npm.pkg.github.com
-            //npm.pkg.github.com/:_authToken=$NPM_TOKEN
-          EOF
-        env:
-          NPM_TOKEN: ${{ secrets.GIT_REPO }}
-
-      - name: Publish to GPR
-        if: steps.changesets.outputs.published == 'true'
-        id: changesets-gpr
-        uses: changesets/action@v1
+  # Both publish jobs are idempotent: `changeset publish` only publishes versions missing from the target registry.
+  # Re-run a failed job to retry that registry without affecting the other.
+  publish-npm:
+    name: Publish to npm
+    needs: version
+    if: ${{ needs.version.outputs.has-changesets == 'false' }}
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: "write"
+      contents: "write"
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v7
         with:
-          publish: yarn changeset publish
-          createGithubReleases: false
+          fetch-depth: 0
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v7
+        with:
+          node-version: lts/*
+          cache: yarn
+          cache-dependency-path: "yarn.lock"
+
+      - name: Install dependencies
+        run: yarn
         env:
+          NPM_AUTH_TOKEN: ${{ secrets.READER_TOKEN }}
+
+      # changeset v3 uses `yarn npm info`, which reads the @navikt scope registry (GPR) from .yarnrc.yml.
+      # Only changes this job's checkout, after install.
+      - name: Point @navikt scope to npm
+        run: yarn config set npmScopes.navikt.npmRegistryServer "https://registry.npmjs.org"
+
+      - name: Publish to npm
+        id: changesets
+        uses: changesets/action@v2
+        with:
+          publish-script: yarn release
+          create-github-releases: false
+        env:
+          # No token: `yarn npm publish` falls back to npm OIDC (trusted publishing)
           NPM_TOKEN: ""
-          # Needed for push to main
-          GITHUB_TOKEN: ${{ secrets.GIT_REPO }}
+          # `yarn npm publish` ignores the scope's npmRegistryServer and defaults to registry.yarnpkg.com
+          YARN_NPM_PUBLISH_REGISTRY: https://registry.npmjs.org
+          github-token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Generate icon.zip
         if: steps.changesets.outputs.published == 'true'
@@ -89,10 +109,11 @@ jobs:
           identity_provider: ${{ secrets.NAIS_WORKLOAD_IDENTITY_PROVIDER }}
 
       - name: Get @navikt/ds-css version
+        if: steps.changesets.outputs.published == 'true'
         run: |
           VERSION=$(yarn css:get-version)
           echo "version=$VERSION" >> $GITHUB_ENV
-          echo "Version of @navikt/ds-css: ${{ env.version }}"
+          echo "Version of @navikt/ds-css: $VERSION"
 
       - name: Upload CSS to Nav CDN
         if: steps.changesets.outputs.published == 'true'
@@ -103,3 +124,40 @@ jobs:
           destination: "@navikt/ds-css"
           project_id: ${{ vars.NAIS_MANAGEMENT_PROJECT_ID }}
           identity_provider: ${{ secrets.NAIS_WORKLOAD_IDENTITY_PROVIDER }}
+
+  publish-gpr:
+    name: Publish to GitHub Packages
+    needs: version
+    if: ${{ needs.version.outputs.has-changesets == 'false' }}
+    runs-on: ubuntu-latest
+    permissions:
+      # Needed for `publishConfig.provenance`
+      id-token: "write"
+      contents: "read"
+      packages: "write"
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v7
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v7
+        with:
+          node-version: lts/*
+          cache: yarn
+          cache-dependency-path: "yarn.lock"
+
+      - name: Install dependencies
+        run: yarn
+        env:
+          NPM_AUTH_TOKEN: ${{ secrets.READER_TOKEN }}
+
+      - name: Build packages
+        run: yarn build:release
+
+      # Git tags and GitHub releases are handled by the npm job
+      - name: Publish to GitHub Packages
+        run: yarn changeset publish --no-git-tag
+        env:
+          NPM_AUTH_TOKEN: ${{ secrets.GIT_REPO }}
+          # `yarn npm publish` ignores the scope's npmRegistryServer and defaults to registry.yarnpkg.com
+          YARN_NPM_PUBLISH_REGISTRY: https://npm.pkg.github.com

@navikt/aksel-icons/CHANGELOG.md

@@ -1,5 +1,9 @@
 # @navikt/aksel-icons
 
+## 8.17.1
+
+## 8.17.0
+
 ## 8.16.2
 
 ## 8.16.1

@navikt/aksel-icons/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@navikt/aksel-icons",
-  "version": "8.16.2",
+  "version": "8.17.1",
   "author": "Aksel | Nav",
   "homepage": "https://aksel.nav.no/ikoner",
   "repository": {
@@ -76,12 +76,12 @@
     "@svgr/cli": "8.1.0",
     "@types/js-yaml": "^4.0.9",
     "@types/react": "19.2.14",
-    "adm-zip": "^0.6.0",
+    "adm-zip": "^0.6.1",
     "concurrently": "10.0.4",
     "copyfiles": "^2.4.1",
     "fast-glob": "3.3.3",
     "hast-util-select": "6.0.4",
-    "js-yaml": "^5.4.1",
+    "js-yaml": "^5.4.2",
     "lodash": "4.18.1",
     "prettier": "3.9.6",
     "react": "19.2.8",
@@ -90,6 +90,6 @@
     "tsx": "^4.23.1",
     "typescript": "6.0.3",
     "unified": "11.0.5",
-    "vitest": "4.1.10"
+    "vitest": "4.1.11"
   }
 }

@navikt/aksel-stylelint/CHANGELOG.md

@@ -1,5 +1,9 @@
 # @navikt/aksel-stylelint
 
+## 8.17.1
+
+## 8.17.0
+
 ## 8.16.2
 
 ## 8.16.1

@navikt/aksel-stylelint/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@navikt/aksel-stylelint",
-  "version": "8.16.2",
+  "version": "8.17.1",
   "type": "module",
   "engines": {
     "node": ">=18.12.0"
@@ -43,8 +43,8 @@
     "dev": "yarn watch:lint"
   },
   "devDependencies": {
-    "@navikt/ds-css": "^8.16.2",
-    "@navikt/ds-tokens": "^8.16.2",
+    "@navikt/ds-css": "^8.17.1",
+    "@navikt/ds-tokens": "^8.17.1",
     "concurrently": "10.0.4",
     "postcss-selector-parser": "^7.1.5",
     "postcss-value-parser": "^4.2.0",

@navikt/aksel/CHANGELOG.md

@@ -1,5 +1,9 @@
 # @navikt/aksel
 
+## 8.17.1
+
+## 8.17.0
+
 ## 8.16.2
 
 ## 8.16.1

@navikt/aksel/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@navikt/aksel",
-  "version": "8.16.2",
+  "version": "8.17.1",
   "description": "Aksel command line interface. Codemods and other utilities for Aksel users.",
   "author": "Aksel | Nav designsystem team",
   "license": "MIT",
@@ -57,7 +57,7 @@
     "@types/jscodeshift": "17.3.0",
     "rimraf": "6.1.3",
     "typescript": "6.0.3",
-    "vitest": "4.1.10"
+    "vitest": "4.1.11"
   },
   "sideEffects": false,
   "engines": {

@navikt/core/css/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @navikt/ds-css
 
+## 8.17.1
+
+## 8.17.0
+
+### Minor Changes
+
+- New component: Badge, a small badge that communicates updates, presence or a count. ([#5096](https://github.com/navikt/aksel/pull/5096))
+
+### Patch Changes
+
+- ExpansionCard: Updated borders and transitions ([#5277](https://github.com/navikt/aksel/pull/5277))
+
 ## 8.16.2
 
 ### Patch Changes

@navikt/core/css/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@navikt/ds-css",
-  "version": "8.16.2",
+  "version": "8.17.1",
   "description": "CSS for Nav Designsystem",
   "author": "Aksel | Nav designsystem team",
   "keywords": [
@@ -32,7 +32,7 @@
     "css:get-version": "node config/get-version.js"
   },
   "devDependencies": {
-    "@navikt/ds-tokens": "^8.16.2",
+    "@navikt/ds-tokens": "^8.17.1",
     "browserslist": "^4.28.7",
     "esbuild": "^0.28.2",
     "fast-glob": "3.3.3",

@navikt/core/css/src/badge.css

@@ -0,0 +1,48 @@
+.aksel-badge__anchor {
+  position: relative;
+  display: inline-flex;
+  flex-shrink: 0;
+  width: fit-content;
+}
+
+.aksel-badge {
+  --__axc-badge-size: 1.25rem;
+
+  box-sizing: border-box;
+  position: relative;
+  z-index: 0;
+  display: inline-flex;
+  align-items: center;
+  justify-content: center;
+  min-width: var(--__axc-badge-size);
+  height: var(--__axc-badge-size);
+  padding: var(--ax-space-4);
+  border-radius: var(--ax-radius-16);
+  background: var(--ax-bg-strong);
+  color: var(--ax-text-contrast);
+  white-space: nowrap;
+  line-height: 1;
+
+  @media (forced-colors: active) {
+    forced-color-adjust: none;
+    background: canvastext;
+    color: canvas;
+  }
+}
+
+.aksel-badge__anchor > .aksel-badge {
+  position: absolute;
+  z-index: 1;
+  pointer-events: none;
+  inset-block-start: 0;
+  inset-inline-end: 0;
+
+  /* 5px offset */
+  transform: translate(0.3125rem, -0.3125rem);
+}
+
+.aksel-badge[data-dot] {
+  --__axc-badge-size: 0.75rem;
+
+  padding-inline: 0;
+}

@navikt/core/css/src/data-token-filter.css

@@ -30,7 +30,6 @@
   max-width: min(95vw, 640px);
   animation-duration: 160ms;
   animation-timing-function: cubic-bezier(0.16, 1, 0.3, 1);
-  overflow: auto;
   /* stylelint-disable-next-line csstools/value-no-unknown-custom-properties */
   max-height: calc(var(--__axc-floating-available-height) - 4px);
 }

@navikt/core/css/src/expansioncard.css

@@ -6,15 +6,18 @@
   border-radius: var(--ax-radius-12);
   background-color: var(--ax-bg-softA);
   height: fit-content;
-  border: 1px solid var(--ax-border-default);
+  border: 1px solid var(--ax-border-subtleA);
+  transition-property: border-color, box-shadow;
+  transition-duration: 300ms;
+  transition-timing-function: cubic-bezier(0, 0, 0, 1);
 
   &[data-color="neutral"] {
     background-color: var(--ax-bg-raised);
   }
 
   &:has(.aksel-expansioncard__header:hover) {
-    box-shadow: 0 0 0 1px var(--ax-border-strong);
-    border-color: var(--ax-border-strong);
+    box-shadow: 0 0 0 1px var(--ax-border-default);
+    border-color: var(--ax-border-default);
   }
 }
 
@@ -47,6 +50,7 @@
   background-color: transparent;
   position: relative;
   justify-content: space-between;
+  transition: background-color 300ms cubic-bezier(0, 0, 0, 1);
 
   &:hover {
     background-color: var(--ax-bg-moderate-hoverA);
@@ -66,6 +70,7 @@
       width: calc(100% - 2 * var(--__axc-expansioncard-padding-inline));
       position: absolute;
       opacity: 1;
+      transition: opacity 150ms cubic-bezier(0, 0, 0, 1);
     }
 
     &:hover::after {
@@ -100,6 +105,7 @@
   min-width: 3rem;
   font-size: 1.5rem;
   align-self: flex-start;
+  transition: background-color 100ms cubic-bezier(0, 0, 0, 1);
 
   &:focus-visible {
     outline: 3px solid var(--ax-border-focus);

@navikt/core/css/src/form/combobox2.css

@@ -1,5 +1,10 @@
+.aksel-combobox2[data-disabled="true"] {
+  opacity: var(--ax-opacity-disabled);
+  pointer-events: none;
+}
+
 /************************************************
- * Label & description                          *
+ * Label & description & error                  *
  ************************************************/
 
 .aksel-combobox2__label {
@@ -11,6 +16,10 @@
   margin-bottom: var(--ax-space-8);
 }
 
+.aksel-combobox2__error {
+  margin-top: var(--ax-space-8);
+}
+
 /************************************************
  * Field                                        *
  ************************************************/
@@ -32,6 +41,9 @@
   padding-right: var(--ax-space-40);
   scroll-margin-block-start: 4rem;
   text-align: left;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+  overflow: hidden;
 
   &:hover {
     border-color: var(--ax-border-strong);
@@ -60,6 +72,11 @@
     border-color: var(--ax-border-neutral-subtleA);
     cursor: default;
   }
+
+  &[data-error="true"] {
+    box-shadow: 0 0 0 1px var(--ax-border-danger-strong);
+    border-color: var(--ax-border-danger-strong);
+  }
 }
 
 .aksel-combobox2__field-chevron {
@@ -79,26 +96,57 @@
   }
 }
 
+/************************************************
+ * Overlay                                      *
+ ************************************************/
+
+.aksel-combobox2__modal {
+  /**
+   * We set the height of the content to the visible viewport, but the virtual
+   * keyboard will still compensate for it's precence by adding some empty space
+   * at the bottom. We use overscroll-behavior and touch-action to prevent scrolling
+   * to this area. They overlap some, but both are needed to make it work everywhere.
+   * See also "List" section below and ComboboxOverlay.tsx.
+   *
+   * On iOS, overscroll-behavior has no effect on scroll containers that have
+   * no scrollable overflow, but it works well in Chrome on Android.
+   *
+   * touch-action works on iOS, but (on Chrome on Android at least) it's still
+   * possible to scroll by dragging from just bellow the list.
+   */
+  overscroll-behavior-y: contain;
+  touch-action: pinch-zoom pan-x;
+}
+
+.aksel-combobox2__modal-inner {
+  display: flex;
+  flex-direction: column;
+  overflow: hidden;
+}
+
 /************************************************
  * Popup                                        *
  ************************************************/
 
 .aksel-combobox2__popup {
   /* stylelint-disable-next-line csstools/value-no-unknown-custom-properties */
-  width: max(280px, var(--__axc-floating-anchor-width));
+  min-width: var(--__axc-floating-anchor-width);
   /* stylelint-disable-next-line csstools/value-no-unknown-custom-properties */
   max-height: calc(var(--__axc-floating-available-height) - 4px);
   background-color: var(--ax-bg-raised);
-  outline: 1px solid var(--ax-border-neutral-subtleA);
-  outline-offset: -1px;
   padding: 1px;
-  border-radius: var(--ax-radius-8);
-  box-shadow: var(--ax-shadow-dialog);
 
   /* This is needed to get overflow:auto to work on child */
   display: flex;
   flex-direction: column;
   overflow: hidden;
+
+  .aksel-combobox2:has(:not(.aksel-combobox2__modal)) & {
+    outline: 1px solid var(--ax-border-neutral-subtleA);
+    outline-offset: -1px;
+    border-radius: var(--ax-radius-8);
+    box-shadow: var(--ax-shadow-dialog);
+  }
 }
 
 /************************************************
@@ -107,39 +155,45 @@
 
 .aksel-combobox2__filter {
   margin: -1px;
-  margin-bottom: var(--ax-space-12);
+}
 
-  & .aksel-search__wrapper {
-    border-bottom-left-radius: 0;
-    border-bottom-right-radius: 0;
+.aksel-combobox2__filter .aksel-search__wrapper {
+  border-bottom-left-radius: 0;
+  border-bottom-right-radius: 0;
 
-    &:has(.aksel-search__input:focus-visible) {
-      outline: none;
-      position: relative;
+  &:has(.aksel-search__input:focus-visible) {
+    outline: none;
+    position: relative;
 
-      &::after {
-        content: "";
-        position: absolute;
-        inset: 0;
-        pointer-events: none;
-        border: 2px solid var(--ax-border-focus);
-        border-top-left-radius: var(--ax-radius-8);
-        border-top-right-radius: var(--ax-radius-8);
-      }
+    &::after {
+      content: "";
+      position: absolute;
+      inset: 0;
+      pointer-events: none;
+      border: 2px solid var(--ax-border-focus);
+    }
+
+    .aksel-combobox2:has(:not(.aksel-combobox2__modal)) &::after {
+      border-top-left-radius: var(--ax-radius-8);
+      border-top-right-radius: var(--ax-radius-8);
     }
   }
+}
 
-  & .aksel-search__input {
-    border-bottom-left-radius: 0;
-    border-bottom-right-radius: 0;
+.aksel-combobox2__filter .aksel-search__input {
+  border-bottom-left-radius: 0;
+  border-bottom-right-radius: 0;
 
-    .aksel-listbox[data-size="medium"] & {
-      min-height: 0;
-    }
+  &:not(:hover) {
+    border-color: var(--ax-border-neutral-subtleA);
+  }
 
-    &:not(:hover) {
-      border-color: var(--ax-border-neutral-subtleA);
-    }
+  .aksel-combobox2[data-size="medium"] & {
+    min-height: 0;
+  }
+
+  .aksel-combobox2__modal & {
+    border-radius: 0;
   }
 }
 
@@ -148,7 +202,17 @@
  ************************************************/
 
 .aksel-combobox2__list {
-  overflow: auto;
+  padding-block: var(--ax-space-12);
+
+  .aksel-combobox2__modal & {
+    padding-inline: var(--ax-space-16);
+
+    /* Prevents scrolling to area taken up by virtual keyboard.
+       Needed for iOS since it doesn't work to set it on the entire modal.
+       NB: Doesn't work if the list doesn't overflow.
+       See also "Overlay" section above and ComboboxOverlay.tsx. */
+    overscroll-behavior-y: contain;
+  }
 }
 
 .aksel-combobox2__no-results {
@@ -156,23 +220,22 @@
   text-align: center;
 }
 
+/************************************************
+ * Group                                        *
+ ************************************************/
+
+.aksel-combobox2__group-label {
+  padding: var(--ax-space-8) var(--ax-space-8);
+  font-weight: bold;
+}
+
 /************************************************
  * Option                                       *
  ************************************************/
 
-.aksel-combobox2__option {
-  & > div {
-    display: flex;
-    gap: var(--ax-space-2);
-
-    & > div:last-child {
-      flex-grow: 1;
-    }
-  }
-
-  &:is([aria-selected="true"], [aria-selected="true"][data-virtual-focus="true"]) > div {
-    background-color: var(--ax-bg-moderate-pressedA);
-  }
+.aksel-combobox2__option:is([aria-selected="true"], [aria-selected="true"][data-virtual-focus="true"])
+  .aksel-listbox__option-inner {
+  background-color: var(--ax-bg-moderate-pressedA);
 }
 
 .aksel-combobox2__option-checkmark {
@@ -180,7 +243,8 @@
 
   width: var(--__axc-combobox2-option-checkmark-size);
   height: var(--__axc-combobox2-option-checkmark-size);
-  margin-top: 0.1875rem;
+  margin-top: var(--ax-space-2);
+  float: left;
 
   .aksel-combobox2[data-size="small"] & {
     --__axc-combobox2-option-checkmark-size: 1rem;
@@ -190,3 +254,14 @@
     font-size: var(--__axc-combobox2-option-checkmark-size);
   }
 }
+
+.aksel-combobox2__option-label {
+  padding-left: var(--ax-space-24);
+
+  /* &[data-nowrap="true"] {
+    padding-left: var(--ax-space-2);
+    text-overflow: ellipsis;
+    white-space: nowrap;
+    overflow: hidden;
+  } */
+}

@navikt/core/css/src/index.css

@@ -48,6 +48,7 @@
 @import "./pagination.css" layer(aksel.components.modules);
 @import "./popover.css" layer(aksel.components.modules);
 @import "./lookup.css" layer(aksel.components.modules);
+@import "./badge.css" layer(aksel.components.modules);
 @import "./tag.css" layer(aksel.components.modules);
 @import "./timeline.css" layer(aksel.components.modules);
 @import "./tooltip.css" layer(aksel.components.modules);

@navikt/core/css/src/listbox.css

@@ -1,3 +1,7 @@
+.aksel-listbox__options {
+  overflow: auto;
+}
+
 .aksel-listbox__group-label {
   background: var(--ax-bg-neutral-softA);
   padding: var(--ax-space-2) var(--ax-space-8);
@@ -17,9 +21,16 @@
   }
 
   .aksel-listbox__options > &:last-child,
-  .aksel-listbox__group:last-child > &:last-child {
+  .aksel-listbox__group:last-child &:last-child {
     margin-bottom: var(--ax-space-2);
   }
+
+  .aksel-listbox__group:first-child &:nth-child(1 of &) {
+    /* When we scroll to the first option, and that option is in a group,
+       scroll to the very top so that the group label is visible as well.
+       We exaggerate the value to take into account custom content. */
+    scroll-margin-top: 60px;
+  }
 }
 
 .aksel-listbox__option-inner {

@navikt/core/react/CHANGELOG.md

@@ -1,5 +1,35 @@
 # @navikt/ds-react
 
+## 8.17.1
+
+### Patch Changes
+
+- Popover: Keep `bottom` placement when there is not enough space above or below the anchor, so the content stays reachable by scrolling. Fixes DatePicker being cut off above the viewport. ([#5297](https://github.com/navikt/aksel/pull/5297))
+- Updated dependencies []:
+  - @navikt/aksel-icons@8.17.1
+  - @navikt/ds-tokens@8.17.1
+
+## 8.17.0
+
+### Minor Changes
+
+- New component: Badge, a small badge that communicates updates, presence or a count. ([#5096](https://github.com/navikt/aksel/pull/5096))
+
+### Patch Changes
+
+- Alert: Component is now marked as deprecated. Use GlobalAlert, LocalAlert, InfoCard or InlineMessage instead. ([#5256](https://github.com/navikt/aksel/pull/5256))
+
+- Combobox: Fix issue deselecting options when uncontrolled ([#5259](https://github.com/navikt/aksel/pull/5259))
+
+- Select: Prevent from being changed with keyboard when readOnly ([#5257](https://github.com/navikt/aksel/pull/5257))
+
+- DatePicker: Fix validation-bug in `useRangeDatePicker` where initial validation could incorrectly assume `isValidDate` to be false ([#5278](https://github.com/navikt/aksel/pull/5278))
+
+- OverridableComponent: Add built-in guard against using `as` and `asChild` at the same time ([#5238](https://github.com/navikt/aksel/pull/5238))
+- Updated dependencies []:
+  - @navikt/aksel-icons@8.17.0
+  - @navikt/ds-tokens@8.17.0
+
 ## 8.16.2
 
 ### Patch Changes

@navikt/core/react/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@navikt/ds-react",
-  "version": "8.16.2",
+  "version": "8.17.1",
   "description": "React components from the Norwegian Labour and Welfare Administration.",
   "author": "Aksel, a team part of the Norwegian Labour and Welfare Administration.",
   "license": "MIT",
@@ -76,6 +76,16 @@
         "default": "./cjs/lookup/index.js"
       }
     },
+    "./PREVIEW/Badge": {
+      "import": {
+        "types": "./esm/badge/index.d.ts",
+        "default": "./esm/badge/index.js"
+      },
+      "require": {
+        "types": "./cjs/badge/index.d.ts",
+        "default": "./cjs/badge/index.js"
+      }
+    },
     "./types/theme": {
       "types": "./esm/types/theme.d.ts"
     },
@@ -738,15 +748,15 @@
   "dependencies": {
     "@floating-ui/react": "0.27.20",
     "@floating-ui/react-dom": "^2.1.9",
-    "@navikt/aksel-icons": "^8.16.2",
-    "@navikt/ds-tokens": "^8.16.2",
+    "@navikt/aksel-icons": "^8.17.1",
+    "@navikt/ds-tokens": "^8.17.1",
     "date-fns": "^4.0.0",
     "react-day-picker": "10.0.1"
   },
   "devDependencies": {
     "@testing-library/dom": "10.4.1",
     "@testing-library/jest-dom": "^6.6.3",
-    "@testing-library/react": "^16.3.0",
+    "@testing-library/react": "^16.3.3",
     "@testing-library/user-event": "^14.5.2",
     "@types/jscodeshift": "17.3.0",
     "@types/node": "^24.10.9",
@@ -765,7 +775,7 @@
     "tsc-alias": "1.9.1",
     "tsx": "^4.23.1",
     "typescript": "6.0.3",
-    "vitest": "4.1.10"
+    "vitest": "4.1.11"
   },
   "peerDependencies": {
     "@types/react": "^17.0.30 || ^18 || ^19",

@navikt/core/react/src/action-menu/checkbox-item/ActionMenuCheckboxItem.tsx

@@ -52,7 +52,6 @@ const ActionMenuCheckboxItem = forwardRef<
               xmlns="http://www.w3.org/2000/svg"
               className="aksel-action-menu__indicator-icon"
               aria-hidden
-              role="presentation"
             >
               <g className="aksel-action-menu__indicator-icon--unchecked">
                 <rect

@navikt/core/react/src/action-menu/radio-item/ActionMenuRadioItem.tsx

@@ -39,7 +39,6 @@ const ActionMenuRadioItem = forwardRef<
               xmlns="http://www.w3.org/2000/svg"
               className="aksel-action-menu__indicator-icon"
               aria-hidden
-              role="presentation"
             >
               <g className="aksel-action-menu__indicator-icon--unchecked">
                 <rect

@navikt/core/react/src/badge/Badge.meta.ts

@@ -0,0 +1,21 @@
+import type { ComponentMetadata } from "../utils/types/metadata";
+import { Badge } from "./index";
+
+const metadata: ComponentMetadata = {
+  name: "Badge",
+  components: {
+    Badge,
+  },
+  keywords: [
+    "status",
+    "badge",
+    "dot",
+    "count",
+    "notification",
+    "indicator",
+    "presence",
+    "status",
+  ],
+};
+
+export { metadata };

@navikt/core/react/src/badge/Badge.stories.tsx

@@ -0,0 +1,105 @@
+import type { Meta, StoryObj } from "@storybook/react-vite";
+import React from "react";
+import { InboxIcon } from "@navikt/aksel-icons";
+import { Badge } from ".";
+import { Button } from "../button";
+import { HStack } from "../primitives/stack";
+import type { AkselColor } from "../types/theme";
+import { renderStoriesForChromatic } from "../utils/renderStoriesForChromatic";
+
+const meta: Meta<typeof Badge> = {
+  title: "ds-react/Badge",
+  component: Badge,
+  parameters: {
+    chromatic: { disable: true },
+  },
+};
+
+export default meta;
+
+type Story = StoryObj<typeof Badge>;
+
+const statuses: { color: AkselColor; label: string }[] = [
+  { color: "danger", label: "Avslått" },
+  { color: "success", label: "Innvilget" },
+  { color: "info", label: "Under behandling" },
+  { color: "warning", label: "Mangler dokumentasjon" },
+  { color: "neutral", label: "Ikke startet" },
+];
+
+export const Default: Story = {
+  args: {
+    count: 42,
+    "data-color": "danger",
+  },
+};
+
+export const Dot: Story = {
+  render: () => (
+    <HStack gap="space-16" align="center">
+      {statuses.map(({ color, label }) => (
+        <Badge key={color} data-color={color} aria-label={label} />
+      ))}
+    </HStack>
+  ),
+};
+
+export const Count: Story = {
+  render: () => (
+    <HStack gap="space-16" align="center">
+      <Badge data-color="danger" count={1} />
+      <Badge data-color="danger" count={42} />
+      <Badge data-color="danger" count={42} maxCount={42} />
+      <Badge data-color="accent" count={199} />
+    </HStack>
+  ),
+};
+
+export const Anchored: Story = {
+  render: () => (
+    <HStack gap="space-32" align="center">
+      <Badge data-color="danger" count={42}>
+        <Button
+          icon={<InboxIcon aria-hidden />}
+          aria-label="Innboks, 42 nye meldinger"
+        />
+      </Badge>
+      <Badge data-color="danger" aria-label="Nytt varsel">
+        <Button icon={<InboxIcon aria-hidden />} aria-label="Innboks" />
+      </Badge>
+    </HStack>
+  ),
+};
+
+export const DynamicCount: Story = {
+  render: () => {
+    const [count, setCount] = React.useState(2);
+
+    return (
+      <HStack gap="space-16" align="center">
+        <Badge data-color="danger" count={count}>
+          <Button
+            icon={<InboxIcon aria-hidden />}
+            aria-label={`Innboks, ${count} nye meldinger`}
+          />
+        </Badge>
+        <Button
+          size="small"
+          variant="secondary"
+          onClick={() => setCount((prev) => prev + 1)}
+        >
+          Ny melding
+        </Button>
+        <span role="status" className="aksel-sr-only">
+          {`${count} nye meldinger`}
+        </span>
+      </HStack>
+    );
+  },
+};
+
+export const Chromatic = renderStoriesForChromatic({
+  Count,
+  Dot,
+  Anchored,
+});

@navikt/core/react/src/badge/Badge.tsx

@@ -0,0 +1,129 @@
+import React, { type HTMLAttributes, forwardRef } from "react";
+import type { AkselColor } from "../types";
+import { BodyShort } from "../typography";
+import { cl } from "../utils/helpers";
+
+interface BadgeProps extends HTMLAttributes<HTMLSpanElement> {
+  /**
+   * Element the badge is anchored to.
+   * Leave empty to render the badge standalone.
+   */
+  children?: React.ReactNode;
+  /**
+   * Badge color.
+   * @default "danger"
+   * @see 🏷️ {@link AkselColor}
+   * @see [📝 Documentation](https://aksel.nav.no/grunnleggende/styling/farger-tokens)
+   */
+  "data-color"?: AkselColor;
+  /**
+   * Optional count to display inside the badge, normalized to a non-negative integer.
+   * Omit to render a dot.
+   */
+  count?: number;
+  /**
+   * The maximum count to display inside the badge, normalized to a non-negative integer.
+   * Numbers above are displayed as `maxCount+`.
+   * @default 99
+   */
+  maxCount?: number;
+}
+
+/**
+ * A small badge that communicates updates or count.
+ *
+ * Use standalone for inline indicators/counts, or pass the element you want to
+ * anchor it to as `children` to pin the badge to one of its corners.
+ *
+ * Accessibility: A badge with no label is treated as decorative when it is a
+ * dot or anchored to another element. When anchoring to an interactive element,
+ * fold the state into that element's accessible name
+ * (e.g. `aria-label="Inbox, 42 new messages"`).
+ *
+ * @see [📝 Documentation](https://aksel.nav.no/komponenter/core/badge)
+ * @see 🏷️ {@link BadgeProps}
+ *
+ * @example
+ * ```jsx
+ * // Standalone
+ * <Badge data-color="success" aria-label="Active" />
+ * <Badge data-color="danger" count={42} />
+ *
+ * // Anchored to an element
+ * <Badge data-color="danger" count={42}>
+ *   <Button icon={<InboxIcon />} aria-label="Inbox, 42 new messages" />
+ * </Badge>
+ * ```
+ */
+const Badge = forwardRef<HTMLSpanElement, BadgeProps>(
+  (
+    {
+      children,
+      className,
+      "data-color": color = "danger",
+      "aria-label": ariaLabel,
+      "aria-labelledby": ariaLabelledby,
+      role,
+      "aria-hidden": ariaHidden,
+      count,
+      maxCount = 99,
+      ...rest
+    },
+    ref,
+  ) => {
+    const normalizedCount =
+      count == null ? undefined : normalizeCount(count, 0);
+    const normalizedMaxCount = normalizeCount(maxCount, 99);
+    const isDot = normalizedCount == null;
+    const hasLabel =
+      Boolean(ariaLabel?.trim()) || Boolean(ariaLabelledby?.trim());
+    const isDecorative =
+      role == null && !hasLabel && (isDot || children != null);
+
+    const badge = (
+      <BodyShort
+        {...rest}
+        ref={ref}
+        as="span"
+        size="small"
+        weight="semibold"
+        data-color={color}
+        data-dot={isDot || undefined}
+        aria-label={ariaLabel}
+        aria-labelledby={ariaLabelledby}
+        role={role}
+        aria-hidden={ariaHidden ?? (isDecorative || undefined)}
+        className={cl("aksel-badge", className)}
+      >
+        {isDot
+          ? null
+          : normalizedCount > normalizedMaxCount
+            ? `${normalizedMaxCount}+`
+            : normalizedCount}
+      </BodyShort>
+    );
+
+    if (children == null) {
+      return badge;
+    }
+
+    return (
+      <span className="aksel-badge__anchor">
+        {children}
+        {badge}
+      </span>
+    );
+  },
+);
+
+function normalizeCount(value: number, fallback: number) {
+  return Number.isFinite(value) ? Math.max(0, Math.floor(value)) : fallback;
+}
+
+// eslint-disable-next-line @typescript-eslint/no-namespace, import/export
+export namespace Badge {
+  export type Props = BadgeProps;
+}
+
+// eslint-disable-next-line import/export
+export { Badge };

@navikt/core/react/src/badge/index.ts

@@ -0,0 +1,2 @@
+"use client";
+export { Badge } from "./Badge";

@navikt/core/react/src/chat/Chat.stories.tsx

@@ -250,12 +250,7 @@ export const ColorRole: Story = {
 
 function Illustration() {
   return (
-    <svg
-      xmlns="http://www.w3.org/2000/svg"
-      viewBox="0 0 54 93"
-      aria-hidden
-      role="presentation"
-    >
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 54 93" aria-hidden>
       <path
         fill="#e7e5e2"
         d="M14 50.7C15 52.3 17.9 81 26.5 81S39 51.8 39 50.3c-13.2-7.6-25 .4-25 .4z"

@navikt/core/react/src/chips/toggle/ChipsToggle.tsx

@@ -64,7 +64,6 @@ export const ChipsToggle: OverridableComponent<
             fill="none"
             xmlns="http://www.w3.org/2000/svg"
             focusable={false}
-            role="presentation"
           >
             {selected ? (
               <path

@navikt/core/react/src/data/token-filter/AutoSuggest.tsx

@@ -182,46 +182,43 @@ const AutoSuggestPopup = forwardRef<HTMLDivElement, AutoSuggestPopupProps>(
           sideOffset={8}
           className="aksel-property-filter__popup"
         >
-          <div className="aksel-property-filter__popup-inner">
-            <Listbox.Options
-              id={id}
-              aria-multiselectable={options.some((group) =>
-                group.options.some((item) => item.multiSelect),
-              )}
-              /* Options are only virtually focused, so real focus must stay on the input */
-              onMouseDown={(event) => event.preventDefault()}
-            >
-              {options.map((group) => {
-                /* Property- and value-groups can share a label, so include an option to keep keys unique */
-                const groupKey = `${group.label}-${group.options[0]?.value ?? ""}`;
+          <Listbox.Options
+            id={id}
+            className="aksel-property-filter__popup-inner"
+            aria-multiselectable={options.some((group) =>
+              group.options.some((item) => item.multiSelect),
+            )}
+            /* Options are only virtually focused, so real focus must stay on the input */
+            onMouseDown={(event) => event.preventDefault()}
+          >
+            {options.map((group) => {
+              /* Property- and value-groups can share a label, so include an option to keep keys unique */
+              const groupKey = `${group.label}-${group.options[0]?.value ?? ""}`;
 
-                const groupOptions = group.options.map((item) => (
-                  <AutoSuggestOption
-                    key={item.value}
-                    item={item}
-                    onSelect={onSelect}
-                    hasVirtualFocus={focusedValue === item.value}
-                    autoSuggestValue={autoSuggestValue}
-                  />
-                ));
-
-                /* Groups without a label are rendered as plain options */
-                if (!group.label) {
-                  return (
-                    <React.Fragment key={groupKey}>
-                      {groupOptions}
-                    </React.Fragment>
-                  );
-                }
+              const groupOptions = group.options.map((item) => (
+                <AutoSuggestOption
+                  key={item.value}
+                  item={item}
+                  onSelect={onSelect}
+                  hasVirtualFocus={focusedValue === item.value}
+                  autoSuggestValue={autoSuggestValue}
+                />
+              ));
 
+              /* Groups without a label are rendered as plain options */
+              if (!group.label) {
                 return (
-                  <Listbox.Group key={groupKey} label={group.label}>
-                    {groupOptions}
-                  </Listbox.Group>
+                  <React.Fragment key={groupKey}>{groupOptions}</React.Fragment>
                 );
-              })}
-            </Listbox.Options>
-          </div>
+              }
+
+              return (
+                <Listbox.Group key={groupKey} label={group.label}>
+                  {groupOptions}
+                </Listbox.Group>
+              );
+            })}
+          </Listbox.Options>
         </Floating.Content>
       </DismissableLayer>
     );

@navikt/core/react/src/datepicker/root/useRangeDatepicker.tsx

@@ -117,15 +117,16 @@ const fromValidation = (day: Date, opt?: UseRangeDatepickerOptions) => {
     opt?.fromDate && day && differenceInCalendarDays(opt?.fromDate, day) > 0;
   const isAfter =
     opt?.toDate && day && differenceInCalendarDays(day, opt?.toDate) > 0;
+  const isDayValidDate = isValidDate(day);
 
   if (
-    isValidDate(day) &&
+    isDayValidDate &&
     !(opt?.disableWeekends && isWeekend(day)) &&
     !(opt?.disabled && dateMatchModifiers(day, opt.disabled))
   ) {
     return {
-      isValidDate: false,
-      isInvalid: !isValidDate(day),
+      isValidDate: isDayValidDate,
+      isInvalid: !isDayValidDate,
       isWeekend: opt?.disableWeekends && isWeekend(day),
       isDisabled: opt?.disabled && dateMatchModifiers(day, opt.disabled),
       isBefore,
@@ -134,7 +135,7 @@ const fromValidation = (day: Date, opt?: UseRangeDatepickerOptions) => {
   }
   if (isBefore || isAfter) {
     return {
-      isValidDate: false,
+      isValidDate: isDayValidDate,
       isBefore,
       isAfter,
     };
@@ -153,15 +154,16 @@ const toValidation = (
 
   const isBeforeFrom =
     (from && differenceInCalendarDays(from, day) > 0) ?? false;
+  const isDayValidDate = isValidDate(day);
 
   if (
-    isValidDate(day) &&
+    isDayValidDate &&
     !(opt?.disableWeekends && isWeekend(day)) &&
     !(opt?.disabled && dateMatchModifiers(day, opt.disabled))
   ) {
     return {
-      isValidDate: false,
-      isInvalid: !isValidDate(day),
+      isValidDate: isDayValidDate,
+      isInvalid: !isDayValidDate,
       isWeekend: opt?.disableWeekends && isWeekend(day),
       isDisabled: opt?.disabled && dateMatchModifiers(day, opt.disabled),
       isBefore,
@@ -171,7 +173,7 @@ const toValidation = (
   }
   if (isBefore || isAfter || isBeforeFrom) {
     return {
-      isValidDate: false,
+      isValidDate: isDayValidDate,
       isBefore,
       isAfter,
       isBeforeFrom,

@navikt/core/react/src/dialog/popup/DialogPopupInternal.tsx

@@ -1,5 +1,5 @@
 import React, { forwardRef } from "react";
-import { BoxNew, type BoxNewProps } from "../../primitives/box";
+import { Box, type BoxProps } from "../../primitives/box";
 import { DismissableLayer } from "../../utils/components/dismissablelayer/DismissableLayer";
 import { FocusBoundary } from "../../utils/components/focus-boundary/FocusBoundary";
 import { FocusGuards } from "../../utils/components/focus-guards/FocusGuards";
@@ -203,7 +203,7 @@ const DialogPopupInternal = forwardRef<
               !closeOnOutsideClick && event.preventDefault();
             }}
           >
-            <BoxNew
+            <Box
               aria-labelledby={ariaLabelledbyProp ?? titleId}
               id={id ?? popupId}
               {...restProps}
@@ -233,7 +233,7 @@ const DialogPopupInternal = forwardRef<
 function translateWidth(
   width: DialogPopupInternalProps["width"],
   position: DialogPosition,
-): BoxNewProps["width"] {
+): BoxProps["width"] {
   if (position === "fullscreen") {
     return undefined;
   }
@@ -253,7 +253,7 @@ function translateWidth(
 function translateHeight(
   height: DialogPopupInternalProps["height"],
   position: DialogPosition,
-): BoxNewProps["height"] {
+): BoxProps["height"] {
   if (
     position === "fullscreen" ||
     position === "left" ||

@navikt/core/react/src/form/checkbox/checkbox-input/CheckboxInput.tsx

@@ -52,7 +52,6 @@ const CheckboxInput = forwardRef<HTMLInputElement, CheckboxInputProps>(
           fill="none"
           focusable={false}
           aria-hidden
-          role="presentation"
           className="aksel-checkbox__icon"
         >
           <path

@navikt/core/react/src/form/combobox/SelectedOptions/selectedOptionsContext.tsx

@@ -96,7 +96,7 @@ const SelectedOptionsProvider = ({
       } else {
         setSelectedOptions((oldSelectedOptions) =>
           oldSelectedOptions.filter(
-            (selectedOption) => selectedOption !== option,
+            (selectedOption) => selectedOption.value !== option.value,
           ),
         );
       }

@navikt/core/react/src/form/combobox/__tests__/combobox.test.tsx

@@ -1,4 +1,4 @@
-import { render, screen } from "@testing-library/react";
+import { act, render, screen } from "@testing-library/react";
 import userEvent from "@testing-library/user-event";
 import React from "react";
 import { describe, expect, test, vi } from "vitest";
@@ -305,5 +305,33 @@ describe("Render combobox", () => {
       await pressKey("PageUp");
       hasVirtualFocus("apple");
     });
+
+    test("should focus previously selected option when reopening with ArrowDown", async () => {
+      render(
+        <>
+          <App options={options} />
+          <button type="button">Outside</button>
+        </>,
+      );
+
+      const combobox = screen.getByRole("combobox", {
+        name: "Hva er dine favorittfrukter?",
+      });
+
+      await userEvent.click(combobox);
+      await userEvent.click(screen.getByRole("option", { name: "pear" }));
+
+      for (let i = 0; i < 3; i++) {
+        await userEvent.click(screen.getByRole("button", { name: "Outside" }));
+        act(() => combobox.focus());
+        expect(combobox).toHaveFocus();
+
+        await userEvent.keyboard("{ArrowDown}");
+        expect(combobox.getAttribute("aria-activedescendant")).toBe(
+          screen.getByRole("option", { name: "pear", selected: true }).id,
+        );
+        await userEvent.keyboard("{Escape}");
+      }
+    });
   });
 });

@navikt/core/react/src/form/combobox2/Combobox.tsx

@@ -1,8 +1,9 @@
 import React from "react";
-import { BodyShort } from "../../typography";
-import { omit } from "../../utils-external";
+import { Dialog } from "../../dialog";
+import { BodyShort, ErrorMessage } from "../../typography";
 import { cl } from "../../utils/helpers";
-import { useFormField } from "../useFormField";
+import { useControllableState } from "../../utils/hooks";
+import { type FormFieldProps, useFormField } from "../useFormField";
 import { ComboboxField } from "./field/ComboboxField";
 import { ComboboxFilter } from "./filter/ComboboxFilter";
 import { ComboboxLabel } from "./label/ComboboxLabel";
@@ -19,52 +20,100 @@ import { ComboboxTrigger } from "./trigger/ComboboxTrigger";
 
 interface ComboboxProps<
   T extends ComboboxOptionData | ComboboxGroupData<ComboboxOptionData>,
-> extends Omit<ComboboxRootProps<T>, "children"> {
+>
+  extends
+    Omit<
+      ComboboxRootProps<T>,
+      "children" | "selectedOptions" | "onToggleOption"
+    >,
+    Partial<Pick<ComboboxRootProps<T>, "selectedOptions" | "onToggleOption">>,
+    Omit<FormFieldProps, "size"> {
   label: string;
-  description?: string;
   hideLabel?: boolean;
-  readOnly?: boolean;
-  //name?: string; // TODO: rendre hidden input med valgt(e) verdi(er) hvis satt.
-} // TODO: trolig extend FormFieldProps
-// TODO: extend React.HTMLAttributes<HTMLDivElement>
+  name?: string;
+  defaultSelectedOptions?: ComboboxRootProps<T>["selectedOptions"];
+  onSelectedOptionsChange?: (
+    newSelectedOptions: ComboboxRootProps<T>["selectedOptions"],
+  ) => void;
+}
 
 function Combobox<
   T extends ComboboxOptionData | ComboboxGroupData<ComboboxOptionData>,
 >({
   label,
   hideLabel,
-  description,
+  name,
+  defaultSelectedOptions,
+  onSelectedOptionsChange,
   size: sizeProp,
+  error,
+  errorId: errorIdProp,
+  disabled: disabledProp,
+  description,
+  id,
   readOnly: readOnlyProp,
+  multiselect = false, // Default value should be synced with ComboboxRoot
+  selectedOptions: selectedOptionsProp,
+  onToggleOption: onToggleOptionProp,
   ...rest
 }: ComboboxProps<T>) {
   const {
     inputProps,
-    //errorId,
-    //showErrorMsg,
-    //hasError,
+    errorId,
+    showErrorMsg,
+    hasError,
     size,
     inputDescriptionId,
     readOnly,
   } = useFormField(
     {
       description,
-      //disabled,
-      //error,
-      //errorId,
-      //id: rest.triggerId,
+      disabled: disabledProp,
+      error,
+      errorId: errorIdProp,
+      id,
       readOnly: readOnlyProp,
       size: sizeProp,
     },
     "combobox",
   );
 
-  // TODO: Kunne være ukontrollert?
-  // TODO: Vurder å koble opp label her, slik at vi slipper å ha triggerId prop i ComboboxRoot.
+  const [selectedOptions, setSelectedOptions] = useControllableState({
+    defaultValue: defaultSelectedOptions || [],
+    value: selectedOptionsProp,
+    onChange: onSelectedOptionsChange,
+  });
+
+  const onToggleOption: ComboboxRootProps<T>["onToggleOption"] = (
+    option,
+    isSelected,
+  ) => {
+    onToggleOptionProp?.(option, isSelected);
+    setSelectedOptions((prevSelectedOptions) => {
+      if (!multiselect) {
+        return [option.value];
+      }
+      if (isSelected) {
+        return [...prevSelectedOptions, option.value];
+      }
+      return prevSelectedOptions.filter((value) => value !== option.value);
+    });
+  };
 
   return (
-    <ComboboxRoot size={size} triggerId={inputProps.id} {...rest}>
-      <ComboboxLabel hide={hideLabel} readOnly={readOnly}>
+    <ComboboxRoot
+      size={size}
+      disabled={inputProps.disabled}
+      multiselect={multiselect}
+      selectedOptions={selectedOptions}
+      onToggleOption={onToggleOption}
+      {...rest}
+    >
+      <ComboboxLabel
+        htmlFor={inputProps.id}
+        hide={hideLabel}
+        readOnly={readOnly}
+      >
         {label}
       </ComboboxLabel>
       {!!description && (
@@ -80,10 +129,37 @@ function Combobox<
           {description}
         </BodyShort>
       )}
-      <ComboboxTrigger readOnly={readOnly} {...omit(inputProps, ["id"])}>
-        <ComboboxField />
+      <ComboboxTrigger readOnly={readOnly} {...inputProps}>
+        <ComboboxField hasError={hasError} />
       </ComboboxTrigger>
-      <ComboboxOverlay>
+      <div
+        className="aksel-form-field__error aksel-combobox2__error"
+        id={errorId}
+        aria-relevant="additions removals"
+        aria-live="polite"
+      >
+        {showErrorMsg && (
+          <ErrorMessage size={size} showIcon>
+            {error}
+          </ErrorMessage>
+        )}
+      </div>
+
+      {name &&
+        selectedOptions.map((value) => (
+          <input key={value} type="hidden" name={name} value={value} />
+        ))}
+
+      <ComboboxOverlay
+        mobileHeader={
+          <Dialog.Header>
+            <Dialog.Title>{label}</Dialog.Title>
+            {!!description && (
+              <Dialog.Description>{description}</Dialog.Description>
+            )}
+          </Dialog.Header>
+        }
+      >
         <ComboboxPopup>
           <ComboboxFilter />
           <ComboboxList />

@navikt/core/react/src/form/combobox2/Combobox2.stories.tsx

@@ -1,6 +1,7 @@
 import type { Meta, StoryFn } from "@storybook/react-vite";
 import React, { useMemo, useState } from "react";
 import { Button } from "../../button";
+import { Dialog } from "../../dialog";
 import { HStack, VStack } from "../../primitives/stack";
 import { Select } from "../select";
 import { Combobox, type ComboboxProps } from "./Combobox";
@@ -32,18 +33,28 @@ type MyOption = {
   metadata?: string;
 };
 
-const countries: MyOption[] = [
+const nordicCountries: MyOption[] = [
   { label: "Norge", value: "opt-1", metadata: "foo1" },
   { label: "Finland", value: "opt-2" },
   { label: "Sverige", value: "opt-3", metadata: "foo3" },
   { label: "Danmark", value: "opt-4" },
   { label: "Island", value: "opt-5" },
-  { label: "Færøyene", value: "opt-6" },
-  { label: "Åland", value: "opt-7" },
-  { label: "Estland", value: "opt-8" },
-  { label: "Latvia", value: "opt-9" },
-  { label: "Litauen", value: "opt-10" },
+  { label: "Grønland", value: "opt-6" },
+  { label: "Færøyene", value: "opt-7" },
+  { label: "Åland", value: "opt-8" },
 ];
+const centralEuropeanCountries: MyOption[] = [
+  { label: "Tyskland", value: "opt-9" },
+  { label: "Østerrike", value: "opt-10" },
+  { label: "Sveits", value: "opt-11" },
+  { label: "Liechtenstein", value: "opt-12" },
+  { label: "Polen", value: "opt-13" },
+  { label: "Tsjekkia", value: "opt-14" },
+  { label: "Slovakia", value: "opt-15" },
+  { label: "Ungarn", value: "opt-16" },
+  { label: "Slovenia", value: "opt-17" },
+];
+const countries: MyOption[] = [...nordicCountries, ...centralEuropeanCountries];
 
 type MyGroup = {
   label: string;
@@ -53,14 +64,14 @@ type MyGroup = {
 
 const groupedCountries: (MyGroup | MyOption)[] = [
   {
-    label: "Nordiske land",
+    label: "Norden",
     id: "group-1",
-    options: countries.slice(0, 6),
+    options: nordicCountries,
   },
   {
-    label: "Baltiske land",
+    label: "Sentral-Europa",
     id: "group-2",
-    options: countries.slice(6),
+    options: centralEuropeanCountries,
   },
   { label: "Annet (ikke gruppert)", value: "opt-01" } satisfies MyOption,
 ];
@@ -73,111 +84,149 @@ type DefaultProps = Pick<
   | "size"
   | "defaultOpen"
   | "multiselect"
-  | "triggerId"
+  | "id"
   | "readOnly"
+  | "disabled"
+  | "error"
 >;
 
 export const Default: StoryFn<DefaultProps> = (props) => {
-  const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
-    "opt-1",
-  ]);
-
-  return (
-    <Combobox
-      defaultOpen
-      options={countries}
-      selectedOptions={selectedOptions}
-      onToggleOption={(option, newSelected) => {
-        setSelectedOptions((prev) =>
-          newSelected
-            ? [...prev, option.value]
-            : prev.filter((v) => v !== option.value),
-        );
-      }}
-      {...props}
-    />
-  );
+  return <Combobox defaultOpen options={countries} {...props} />;
 };
 Default.args = {
   label: "Velg land",
   description: "Landet hvor du er født.",
   hideLabel: false,
   defaultOpen: false,
-  //multiselect: true,
+  multiselect: false,
   readOnly: false,
+  disabled: false,
+  error: "",
 };
 Default.argTypes = {
   size: {
     control: { type: "select" },
     options: ["small", "medium"],
   },
-  triggerId: {
+  id: {
     control: { type: "text" },
   },
 };
 
-function BaseCombobox<
+function BasicCombobox<
   T extends ComboboxOptionData | ComboboxGroupData<ComboboxOptionData> =
     MyOption,
 >(props: Partial<ComboboxProps<T>>) {
-  const [selectedOptions, setSelectedOptions] = useState(["opt-1"]);
-
   return (
     <Combobox
       options={countries as T[]}
-      selectedOptions={selectedOptions}
-      onToggleOption={(option, newSelected) => {
-        setSelectedOptions((prev) =>
-          newSelected
-            ? [...prev, option.value]
-            : prev.filter((v) => v !== option.value),
-        );
-      }}
+      defaultSelectedOptions={["opt-1"]}
       label="Velg land"
       description="Landet hvor du er født."
+      multiselect={false}
       {...props}
     />
   );
 }
 
-export const HideLabel = () => <BaseCombobox hideLabel />;
+export const Small = () => <BasicCombobox size="small" error="Error" />;
 
-export const ReadOnly = () => <BaseCombobox readOnly />;
+export const Hidelabel = () => <BasicCombobox hideLabel />;
+
+export const Readonly = () => <BasicCombobox readOnly />;
+
+export const Disabled = () => <BasicCombobox disabled />;
+
+export const ErrorStory = () => <BasicCombobox error="Du må velge et land." />;
+ErrorStory.storyName = "Error";
+
+export const DefaultOpen = () => <BasicCombobox defaultOpen />;
+DefaultOpen.storyName = "DefaultOpen";
+
+export const DefaultSelectedOptions = () => (
+  <BasicCombobox defaultSelectedOptions={["opt-1"]} />
+);
+DefaultSelectedOptions.storyName = "DefaultSelectedOptions";
+
+export const Name = () => (
+  <form
+    onSubmit={(event) => {
+      event.preventDefault();
+      const formData = new FormData(event.target);
+      const land = formData.getAll("land");
+      console.log(land);
+    }}
+  >
+    <BasicCombobox name="land" />
+    <br />
+    <button type="submit">Submit</button>
+  </form>
+);
+
+export const Controlled = () => {
+  const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
+    "opt-1",
+  ]);
 
-export const SingleSelect = () => {
-  const [selectedOption, setSelectedOption] = useState<MyOption>(countries[0]);
   return (
-    <BaseCombobox
-      selectedOptions={[selectedOption.value]}
-      onToggleOption={(option) => setSelectedOption(option)}
-      multiselect={false}
-    />
+    <VStack gap="space-8" minWidth="250px">
+      <Combobox
+        options={countries}
+        selectedOptions={selectedOptions}
+        onToggleOption={(option, newSelected) => {
+          setSelectedOptions((prev) =>
+            newSelected
+              ? [...prev, option.value]
+              : prev.filter((v) => v !== option.value),
+          );
+        }}
+        label="Velg land"
+      />
+      Selected: {selectedOptions.join(", ")}
+      <div>
+        <button type="button" onClick={() => setSelectedOptions([])}>
+          Clear
+        </button>
+      </div>
+    </VStack>
   );
 };
 
-export const Groups = () => {
-  return (
-    <HStack gap="space-56" minHeight="300px">
-      <BaseCombobox
-        options={groupedCountries}
-        description="Landene du har statsborgerskap."
-      />
+export const Controlled2 = () => {
+  const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
+    "opt-1",
+  ]);
 
-      <BaseCombobox
-        options={groupedCountries}
-        description="Landene du har statsborgerskap."
-        size="small"
+  return (
+    <VStack gap="space-8" minWidth="250px">
+      <Combobox
+        options={countries}
+        selectedOptions={selectedOptions}
+        onSelectedOptionsChange={setSelectedOptions}
+        label="Velg land"
       />
-    </HStack>
+      Selected: {selectedOptions.join(", ")}
+      <div>
+        <button type="button" onClick={() => setSelectedOptions([])}>
+          Clear
+        </button>
+      </div>
+    </VStack>
   );
 };
 
+export const Groups = () => (
+  <HStack gap="space-56" minHeight="300px">
+    <BasicCombobox options={groupedCountries} />
+
+    <BasicCombobox options={groupedCountries} size="small" />
+  </HStack>
+);
+
 type ManyOptionsProps = {
   count: number;
 };
 export const ManyOptions: StoryFn<ManyOptionsProps> = ({ count }) => {
-  const [selectedOptions, setSelectedOptions] = useState(["opt-1"]);
-
   const manyOptions = useMemo(
     () =>
       Array.from({ length: count }, (_, i) => ({
@@ -189,18 +238,7 @@ export const ManyOptions: StoryFn<ManyOptionsProps> = ({ count }) => {
 
   return (
     <div style={{ minHeight: "400px", width: "250px" }}>
-      <Combobox
-        options={manyOptions}
-        selectedOptions={selectedOptions}
-        onToggleOption={(option) => {
-          setSelectedOptions((prev) =>
-            prev.includes(option.value)
-              ? prev.filter((v) => v !== option.value)
-              : [...prev, option.value],
-          );
-        }}
-        label="Test"
-      />
+      <Combobox options={manyOptions} label="Test" />
     </div>
   );
 };
@@ -212,6 +250,40 @@ ManyOptions.parameters = {
   docs: { disable: true },
 };
 
+export const LongLabels = () => (
+  <div style={{ maxWidth: "300px" }}>
+    <ComboboxRoot
+      defaultOpen
+      options={[
+        {
+          id: "group-1",
+          label:
+            "Dette er en veldig lang label for å teste hvordan lange labels håndteres",
+          options: [
+            {
+              label:
+                "Dette er en veldig lang label for å teste hvordan dette håndteres",
+              value: "opt-1",
+            },
+            {
+              label:
+                "Dette er en veldig lang label for å teste hvordan dette håndteres",
+              value: "opt-2",
+            },
+          ],
+        },
+      ]}
+      selectedOptions={["opt-1"]}
+      onToggleOption={() => {}}
+    >
+      <ComboboxField />
+      <ComboboxPopup>
+        <ComboboxList />
+      </ComboboxPopup>
+    </ComboboxRoot>
+  </div>
+);
+
 export const Composition = () => {
   const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
     "opt-1",
@@ -274,8 +346,8 @@ export const Composition = () => {
 
       <VStack>
         <ComboboxRoot {...rootProps}>
-          <ComboboxLabel>Velg land</ComboboxLabel>
-          <ComboboxTrigger>
+          <ComboboxLabel htmlFor="demo">Velg land</ComboboxLabel>
+          <ComboboxTrigger id="demo">
             <Button>Med input og label</Button>
           </ComboboxTrigger>
           <ComboboxOverlay>
@@ -293,8 +365,8 @@ export const Composition = () => {
         onToggleOption={setSelectedOption}
         multiselect={false}
       >
-        <ComboboxLabel>Velg land (single select)</ComboboxLabel>
-        <ComboboxTrigger>
+        <ComboboxLabel htmlFor="demo2">Velg land (single select)</ComboboxLabel>
+        <ComboboxTrigger id="demo2">
           <ComboboxField />
         </ComboboxTrigger>
         <ComboboxOverlay>
@@ -306,8 +378,8 @@ export const Composition = () => {
       </ComboboxRoot>
 
       <ComboboxRoot {...rootProps}>
-        <ComboboxLabel>Velg land (multiselect)</ComboboxLabel>
-        <ComboboxTrigger>
+        <ComboboxLabel htmlFor="demo3">Velg land (multiselect)</ComboboxLabel>
+        <ComboboxTrigger id="demo3">
           <ComboboxField />
         </ComboboxTrigger>
         <ComboboxOverlay>
@@ -322,9 +394,31 @@ export const Composition = () => {
 };
 Composition.parameters = { layout: "padded" };
 
-export const Testing = () => {
-  const [selectedOption, setSelectedOption] = useState<MyOption>();
+export const InDialog = () => {
+  return (
+    <Dialog defaultOpen>
+      <Dialog.Trigger>
+        <Button>Open dialog</Button>
+      </Dialog.Trigger>
+      <Dialog.Popup width="small">
+        <Dialog.Header>
+          <Dialog.Title>Dialog title</Dialog.Title>
+          <Dialog.Description>Dialog description</Dialog.Description>
+        </Dialog.Header>
+        <Dialog.Body>
+          <BasicCombobox />
+        </Dialog.Body>
+        <Dialog.Footer>
+          <Dialog.CloseTrigger>
+            <Button>Close dialog</Button>
+          </Dialog.CloseTrigger>
+        </Dialog.Footer>
+      </Dialog.Popup>
+    </Dialog>
+  );
+};
 
+export const Testing = () => {
   return (
     <VStack gap="space-32" width="300px">
       <button type="button" onClick={() => console.log("Knapp før")}>
@@ -333,8 +427,6 @@ export const Testing = () => {
 
       <Combobox
         options={countries}
-        selectedOptions={selectedOption ? [selectedOption.value] : []}
-        onToggleOption={setSelectedOption}
         multiselect={false}
         label="Velg land (Combobox)"
         description="Beskrivelse"
@@ -357,25 +449,37 @@ export const Testing = () => {
         <option value="latvia">Latvia</option>
         <option value="lithuania">Lithuania</option>
       </Select>
+
+      <Select label="Mange alternativer (vanlig select)">
+        {Array.from({ length: 100 }, (_, i) => (
+          // biome-ignore lint/suspicious/noArrayIndexKey: Don't care
+          <option key={i} value={`opt-${i + 1}`}>
+            {`Option ${String(i + 1).padStart(4, "0")}`}
+          </option>
+        ))}
+      </Select>
     </VStack>
   );
 };
 
 /* TODO:
-- Fullskjerm på mobil
+- Mobil: Vurder å ikke fokusere søkefelt automatisk.
+- Mobil: Vurder å ikke ha virtuelt fokus i det hele tatt hvis man ikke har tastatur
+    Kan kanskje bruke media query, ev. ikke gi noe fokus før man begynner å trykke (som dagens CB. Sjekk hvordan SR takler at ingenting har virtuelt fokus.)
+    Sjekk om det er mulig å flytte virtuelt fokus uten tastatur (typ med skjermleser).
+- Vurder om fokus skal låses til søkefelt (mest aktuelt ved multiselect).
+- Åpne på pil ned (og ev. opp)?
+- Vurder funksjoner fra gamle CB (ikke brukt: dropp, brukt lite: muliggjør med komposisjon, brukt mye: bygg inn støtte)
+  - allowNewValues (er dette ofte egentlig Autocomplete?)
+  - isLoading
+  - maxSelected
+- Skal den hete noe annet enn Combobox?
+- Vurder om Label og Description (og error?) skal være sub-komponenter eller ikke.
 - Følge Combobox-pattern (mer)? Kan ikke følge det slavisk uansett.
     Pil opp og ned velger
     Ikke loop
-- Skal den hete noe annet enn Combobox? Er jo på en måte ikke det...
-- Vurder om fokus skal låses til søkefelt (mest aktuelt ved multiselect).
-- Åpne på pil ned (og ev. opp)?
-- PageUp/Down
-- Error, disabled (?), readonly osv.
-- Vurder hvilke funksjoner i gamle CB vi skal ta med (maks valg, legg til osv.)
-- Tester
-- A11y-sjekk
+- A11y-sjekk (skjermleser, zoom, høykontrast...)
 - Beslutningsloggen?
-- Ikke wrappe options
 
 
 Utfordringer med komposisjon:
@@ -387,9 +491,4 @@ Forslag: Tilby enkeltkomponent for de vanligste tilfellene, men også subkompone
   Kan ev. ha slot/render-props for enkelte ting.
   Kan ev. bruke children for å kunne bytte ut/skreddersy innholdet i popup.
 
-
-Ressurser:
-- https://www.w3.org/WAI/ARIA/apg/patterns/combobox/
-- https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/combobox_role
-- https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/listbox_role
 */

@navikt/core/react/src/form/combobox2/Combobox2.tests.stories.tsx

@@ -20,31 +20,41 @@ const meta: Meta<typeof ComboboxRoot> = {
 };
 export default meta;
 
-const countries = [
-  { label: "Norge", value: "option-1" },
-  { label: "Finland", value: "option-2" },
-  { label: "Sverige", value: "option-3" },
-  { label: "Danmark", value: "option-4" },
-  { label: "Island", value: "option-5" },
-  { label: "Færøyene", value: "option-6" },
-  { label: "Åland", value: "option-7" },
-  { label: "Estland", value: "option-8" },
-  { label: "Latvia", value: "option-9" },
-  { label: "Litauenm", value: "option-10" },
+const nordicCountries = [
+  { label: "Norge", value: "opt-1" },
+  { label: "Finland", value: "opt-2" },
+  { label: "Sverige", value: "opt-3" },
+  { label: "Danmark", value: "opt-4" },
+  { label: "Island", value: "opt-5" },
+  { label: "Grønland", value: "opt-6" },
+  { label: "Færøyene", value: "opt-7" },
+  { label: "Åland", value: "opt-8" },
 ];
+const centralEuropeanCountries = [
+  { label: "Tyskland", value: "opt-9" },
+  { label: "Østerrike", value: "opt-10" },
+  { label: "Sveits", value: "opt-11" },
+  { label: "Liechtenstein", value: "opt-12" },
+  { label: "Polen", value: "opt-13" },
+  { label: "Tsjekkia", value: "opt-14" },
+  { label: "Slovakia", value: "opt-15" },
+  { label: "Ungarn", value: "opt-16" },
+  { label: "Slovenia", value: "opt-17" },
+];
+const countries = [...nordicCountries, ...centralEuropeanCountries];
 
 const groupedOptions = [
   {
-    label: "Nordiske land",
+    label: "Norden",
     id: "group-1",
-    options: countries.slice(0, 6),
+    options: nordicCountries,
   },
   {
-    label: "Baltiske land",
+    label: "Sentral-Europa",
     id: "group-2",
-    options: countries.slice(6),
+    options: centralEuropeanCountries,
   },
-  { label: "Ikke gruppert", value: "option-01" },
+  { label: "Annet (ikke gruppert)", value: "opt-01" },
 ];
 
 function BaseCombobox<
@@ -138,7 +148,7 @@ OptionMemoization.play = async ({ canvasElement }) => {
   expect(Number(countElm.textContent)).toBe(expectedCount);
 
   // Filtering should not re-render any options
-  // TODO: For this to work we must omit the filterString prop on ComboboxOption
+  // TODO: For this to work we must omit the highlightText prop on ComboboxOption
   /*await userEvent.type(combobox, "nor", { delay: 200 });
   expect(Number(countElm.textContent)).toBe(expectedCount);
   expect(canvas.getAllByRole("option").length).toBe(1);*/

@navikt/core/react/src/form/combobox2/field/ComboboxField.tsx

@@ -8,10 +8,11 @@ import {
 
 interface ComboboxFieldProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
   children?: React.ReactNode;
+  hasError?: boolean;
 }
 
 const ComboboxField = forwardRef<HTMLButtonElement, ComboboxFieldProps>(
-  ({ children, ...rest }, ref) => {
+  ({ children, hasError, ...rest }, ref) => {
     const { options, selectedOptions, size } = useComboboxRootContext();
 
     const labels = getLabels(selectedOptions, options);
@@ -21,6 +22,7 @@ const ComboboxField = forwardRef<HTMLButtonElement, ComboboxFieldProps>(
         <button
           type="button"
           ref={ref}
+          data-error={hasError}
           className={cl(
             "aksel-combobox2__field-btn",
             "aksel-body-short",

@navikt/core/react/src/form/combobox2/filter/ComboboxFilter.tsx

@@ -30,6 +30,7 @@ export const ComboboxFilter = (props: ComboboxFilterProps) => {
             }
           }}
           aria-autocomplete="list"
+          inputMode="text"
         />
       </Listbox.InputSlot>
     </div>

@navikt/core/react/src/form/combobox2/label/ComboboxLabel.tsx

@@ -4,8 +4,9 @@ import { cl } from "../../../utils/helpers";
 import { ReadOnlyIconWithTitle } from "../../ReadOnlyIcon";
 import { useComboboxRootContext } from "../root/ComboboxRoot";
 
-interface ComboboxLabelProps extends React.HTMLAttributes<HTMLLabelElement> {
+interface ComboboxLabelProps extends React.LabelHTMLAttributes<HTMLLabelElement> {
   children: string;
+  htmlFor: string;
   hide?: boolean;
   readOnly?: boolean;
 }
@@ -17,11 +18,10 @@ const ComboboxLabel = ({
   readOnly,
   ...rest
 }: ComboboxLabelProps) => {
-  const { triggerId, size } = useComboboxRootContext();
+  const { size } = useComboboxRootContext();
 
   return (
     <Label
-      htmlFor={triggerId}
       className={cl(
         "aksel-form-field__label aksel-combobox2__label",
         className,

@navikt/core/react/src/form/combobox2/list/ComboboxList.tsx

@@ -101,7 +101,7 @@ function ComboboxListContent<
             onToggleOption={localOnToggleOption}
             isSelected={selectedOptions.includes(option.value)}
             hasVirtualFocus={virtuallyFocusedOptionValue === option.value}
-            filterString={deferredFilterString}
+            highlightText={deferredFilterString}
           >
             {children as ComboboxListProps<typeof option>["children"]}
           </ComboboxOption>
@@ -114,7 +114,7 @@ function ComboboxListContent<
         onToggleOption={localOnToggleOption}
         isSelected={selectedOptions.includes(optOrGroup.value)}
         hasVirtualFocus={virtuallyFocusedOptionValue === optOrGroup.value}
-        filterString={deferredFilterString} // TODO: Vurder å kunne slå av dette for bedre ytelse
+        highlightText={deferredFilterString} // TODO: Vurder å kunne slå av dette for bedre ytelse
       >
         {children as ComboboxListProps<typeof optOrGroup>["children"]}
       </ComboboxOption>

@navikt/core/react/src/form/combobox2/option/ComboboxOption.tsx

@@ -9,7 +9,7 @@ export interface ComboboxOptionProps<T extends ComboboxOptionData> {
   onToggleOption: (option: T, isSelected: boolean) => void;
   isSelected: boolean;
   hasVirtualFocus: boolean;
-  filterString: string;
+  highlightText: string;
   children?: React.ReactNode | ComboboxListProps<T>["children"];
 }
 
@@ -18,7 +18,7 @@ function ComboboxOptionComponent<T extends ComboboxOptionData>({
   onToggleOption,
   isSelected,
   hasVirtualFocus,
-  filterString,
+  highlightText,
   children,
 }: ComboboxOptionProps<T>) {
   //console.log("Rendering option", option.value);
@@ -34,12 +34,15 @@ function ComboboxOptionComponent<T extends ComboboxOptionData>({
       <div className="aksel-combobox2__option-checkmark" aria-hidden>
         {isSelected && <CheckmarkHeavyIcon aria-hidden />}
       </div>
-      <div>
+      <div
+        className="aksel-combobox2__option-label"
+        //data-nowrap={!children || typeof children === "string"}
+      >
         {typeof children === "function"
           ? children(option)
           : (children ??
-            (filterString
-              ? highlightSubstring(option.label, filterString)
+            (highlightText
+              ? highlightSubstring(option.label, highlightText)
               : option.label))}
       </div>
     </Listbox.Option>

@navikt/core/react/src/form/combobox2/overlay/ComboboxOverlay.tsx

@@ -1,17 +1,39 @@
-import React from "react";
+import React, { useEffect } from "react";
+import { Dialog } from "../../../dialog";
 import { DismissableLayer } from "../../../utils/components/dismissablelayer/DismissableLayer";
 import {
   Floating,
   MENU_COLLISION_AVOIDANCE,
 } from "../../../utils/components/floating/Floating";
+import { useMedia, useSyncExternalStore } from "../../../utils/hooks";
 import { useComboboxRootContext } from "../root/ComboboxRoot";
 
 interface ComboboxOverlayProps {
   children: React.ReactNode;
+  mobileHeader?: React.ReactNode;
 }
 
-const ComboboxOverlay = ({ children }: ComboboxOverlayProps) => {
+function ComboboxOverlay({ children, mobileHeader }: ComboboxOverlayProps) {
   const rootContext = useComboboxRootContext();
+  const isMobile = useMedia("(max-width: 479px)");
+
+  if (isMobile) {
+    return (
+      <ComboboxModal
+        open={rootContext.open}
+        onOpenChange={(open) => {
+          rootContext.setOpen(open);
+          !open && rootContext.triggerRef.current?.focus(); // This does not work when closing with button
+        }}
+        onOpenChangeComplete={(open) =>
+          !open && rootContext.triggerRef.current?.focus()
+        }
+      >
+        {mobileHeader}
+        {children}
+      </ComboboxModal>
+    );
+  }
 
   if (!rootContext.open) {
     return null;
@@ -49,6 +71,67 @@ const ComboboxOverlay = ({ children }: ComboboxOverlayProps) => {
       </Floating.Content>
     </DismissableLayer>
   );
+}
+
+type ComboboxModalProps = {
+  children: React.ReactNode;
+  open: boolean;
+  onOpenChange: (open: boolean) => void;
+  onOpenChangeComplete: (open: boolean) => void;
 };
 
+function subscribeToResize(callback: () => void) {
+  visualViewport?.addEventListener("resize", callback);
+  return () => visualViewport?.removeEventListener("resize", callback);
+}
+
+function getVisualViewportHeight() {
+  return visualViewport?.height; // Takes into account virtual keyboard etc.
+}
+
+function ComboboxModal({
+  children,
+  open,
+  onOpenChange,
+  onOpenChangeComplete,
+}: ComboboxModalProps) {
+  const visualViewportHeight = useSyncExternalStore(
+    subscribeToResize,
+    getVisualViewportHeight,
+  );
+
+  useEffect(() => {
+    // See "Overlay" section in CSS file for context. This handles the case when
+    // the list doesn't overflow and overscroll-behavior doesn't work on iOS.
+    const scrollToTop = () => (document.documentElement.scrollTop = 0);
+    visualViewport?.addEventListener("scroll", scrollToTop);
+    return () => visualViewport?.removeEventListener("scroll", scrollToTop);
+  }, []);
+
+  return (
+    <Dialog
+      size="small"
+      open={open}
+      onOpenChange={onOpenChange}
+      onOpenChangeComplete={onOpenChangeComplete}
+    >
+      <Dialog.Popup className="aksel-combobox2__modal" position="fullscreen">
+        <div
+          className="aksel-combobox2__modal-inner"
+          // The reported height is sometimes a bit too small,
+          // so we let the dialog fill the entire normal viewport,
+          // and only limit the inner content's height.
+          style={
+            visualViewportHeight
+              ? { maxHeight: `${visualViewportHeight}px` }
+              : undefined
+          }
+        >
+          {children}
+        </div>
+      </Dialog.Popup>
+    </Dialog>
+  );
+}
+
 export { ComboboxOverlay };

@navikt/core/react/src/form/combobox2/popup/ComboboxPopup.stories.tsx

@@ -1,5 +1,6 @@
-import type { Meta } from "@storybook/react-vite";
+import type { Meta, StoryFn } from "@storybook/react-vite";
 import React, { useState } from "react";
+import { fireEvent } from "storybook/test";
 import { HStack } from "../../../primitives/stack";
 import { BodyShort } from "../../../typography";
 import { ComboboxFilter } from "../filter/ComboboxFilter";
@@ -57,7 +58,7 @@ const groupedOptions: (MyGroup | MyOption)[] = [
 
 export const Default = () => {
   const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
-    "opt-1",
+    "opt-3",
   ]);
 
   return (
@@ -82,7 +83,7 @@ export const Default = () => {
 };
 
 export const SingleSelect = () => {
-  const [selectedOption, setSelectedOption] = useState<MyOption>(options[0]);
+  const [selectedOption, setSelectedOption] = useState<MyOption>(options[2]);
 
   return (
     <ComboboxRoot
@@ -100,7 +101,7 @@ export const SingleSelect = () => {
 };
 
 export const Groups = () => {
-  const [selectedOption, setSelectedOption] = useState<MyOption>(options[0]);
+  const [selectedOption, setSelectedOption] = useState<MyOption>(options[2]);
 
   return (
     <HStack gap="space-56">
@@ -132,6 +133,42 @@ export const Groups = () => {
   );
 };
 
+export const WithoutFilter = () => {
+  const [selectedOption, setSelectedOption] = useState<MyOption>(options[0]);
+
+  return (
+    <HStack gap="space-56">
+      <ComboboxRoot
+        defaultOpen
+        options={[
+          {
+            label: "Nordiske land",
+            id: "group-1",
+            options: options.slice(0, 3),
+          },
+        ]}
+        selectedOptions={[selectedOption.value]}
+        onToggleOption={setSelectedOption}
+      >
+        <ComboboxPopup>
+          <ComboboxList />
+        </ComboboxPopup>
+      </ComboboxRoot>
+
+      <ComboboxRoot
+        defaultOpen
+        options={options.slice(0, 3)}
+        selectedOptions={[selectedOption.value]}
+        onToggleOption={setSelectedOption}
+      >
+        <ComboboxPopup>
+          <ComboboxList />
+        </ComboboxPopup>
+      </ComboboxRoot>
+    </HStack>
+  );
+};
+
 export const CustomOptionRendering = () => {
   const [selectedOptions, setSelectedOptions] = useState<MyOption["value"][]>([
     "opt-1",
@@ -245,3 +282,32 @@ export const ControlledInput = () => {
     </ComboboxRoot>
   );
 };
+
+export const States: StoryFn = () => {
+  const [selectedOption, setSelectedOption] = useState<MyOption>(options[0]);
+
+  return (
+    <ComboboxRoot
+      defaultOpen
+      options={options.slice(0, 3)}
+      selectedOptions={[selectedOption.value]}
+      onToggleOption={setSelectedOption}
+    >
+      <ComboboxPopup>
+        <ComboboxList />
+      </ComboboxPopup>
+    </ComboboxRoot>
+  );
+};
+States.play = async ({ canvasElement }) => {
+  // Selected option will get focus by default.
+  // Move focus down so that we can see the states
+  // "selected but not focused" and "focused but not selected".
+  const listbox = canvasElement.querySelector(
+    "[role='listbox']",
+  ) as HTMLElement;
+  console.log(listbox);
+  fireEvent.keyDown(listbox, { key: "ArrowDown" });
+};
+
+//export const Chromatic = renderStoriesForChromatic();

@navikt/core/react/src/form/combobox2/popup/ComboboxPopup.tsx

@@ -21,6 +21,7 @@ export interface ComboboxPopupProps {
   children: React.ReactNode;
 }
 
+// TODO: Bør den hete Dropdown eller Menu? (Og Overlay -> Popup?)
 export const ComboboxPopup = ({ children }: ComboboxPopupProps) => {
   const [virtuallyFocusedOptionValue, setVirtuallyFocusedOptionValue] =
     useState("");