vite-plugin-zephyr 1.4.2 → 1.5.0

package/README.md

@@ -38,6 +38,31 @@ bun add --dev vite-plugin-zephyr
 
 ## Usage
 
+### Agent guidance
+
+This package ships the `zephyr-vite` Agent Skill alongside its implementation.
+Use the installed package's guidance for configuration and build lifecycle
+behavior rather than a repository skill from a different SDK release.
+
+Install Intent as a development dependency when adding agent tooling is appropriate:
+
+```sh
+pnpm add -D @tanstack/intent@0.5.0
+pnpm exec intent install
+pnpm exec intent list
+pnpm exec intent load 'vite-plugin-zephyr#zephyr-vite'
+```
+
+Select `vite-plugin-zephyr` during setup. The consumer's `intent.skills` allowlist
+controls which installed packages appear in the agent's catalog. Intent is agent
+tooling; the Zephyr plugin does not require it at runtime.
+
+Every published Zephyr package also bundles `zephyr-core` and
+`zephyr-module-federation` from the canonical guides in this repository.
+Plugin setup and cross-bundler configuration no longer live in the separate
+skills repository. Maintainers run `pnpm skills:check` at the
+workspace root after updating the guidance and recording source reviews.
+
 ### Basic Configuration
 
 Add the plugin to your Vite configuration:

package/package.json

@@ -1,11 +1,12 @@
 {
   "$schema": "https://raw.githubusercontent.com/vitejs/vite-plugin-registry/refs/heads/main/data/schema/extended-package-json.schema.json",
   "name": "vite-plugin-zephyr",
-  "version": "1.4.2",
+  "version": "1.5.0",
   "description": "Vite plugin for Zephyr",
   "keywords": [
     "deploy",
     "module-federation",
+    "tanstack-intent",
     "vite",
     "vite-plugin",
     "zephyr"
@@ -24,6 +25,9 @@
     "dist",
     "README.md",
     "LICENSE",
+    "skills",
+    "!skills/_artifacts",
+    "!skills/**/.zephyr-generated",
     "!dist/**/*.map"
   ],
   "type": "commonjs",
@@ -51,12 +55,13 @@
     "acorn": "^8.18.0",
     "acorn-walk": "^8.3.5",
     "magic-string": "1.2.3",
-    "zephyr-agent": "1.4.2"
+    "zephyr-agent": "1.5.0"
   },
   "devDependencies": {
     "@module-federation/vite": "1.21.2",
     "@rslib/core": "1.0.0",
     "@rstest/core": "0.11.12",
+    "@tanstack/intent": "0.5.0",
     "@types/node": "^24.13.3",
     "rollup": "^4.63.1",
     "typescript": "~7.0.0",

package/skills/zephyr-core/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026-present Zephyr Cloud and contributors
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/skills/zephyr-core/README.md

@@ -0,0 +1,13 @@
+# zephyr-core
+
+Skill for general Zephyr frontend setup and deployment workflows.
+
+Includes:
+
+- `SKILL.md` for the main trigger and workflow
+- `references/sdk-setup.md` for plugin and codemod setup
+- `references/deployment-model.md` for versions, snapshots, tags, and environments
+- `references/env-vars.md` for `ZE_PUBLIC_*` and environment overrides
+- `references/examples-resume.md` for concrete starter examples
+- `references/docs-map.md` for docs links and `llms.txt`
+- `references/troubleshooting.md` for common setup issues

package/skills/zephyr-core/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: zephyr-core
+description: Use when the user asks about Zephyr setup, with-zephyr, SDK selection, versions, tags, environments, snapshot/version URLs, dashboard workflows, docs, or public env vars.
+license: Apache-2.0
+metadata:
+  author: Zephyr Cloud IO
+  purpose: Use when the user asks about Zephyr setup, with-zephyr, SDK selection, versions, tags, environments, snapshot/version URLs, dashboard workflows, docs, or public env vars.
+  domain: sdk
+  type: core
+sources:
+  - ZephyrCloudIO/zephyr-packages:**/skills/zephyr-core/references/*.md
+  - ZephyrCloudIO/zephyr-packages:**/scripts/sync-package-skills.mjs
+---
+
+# Zephyr Core
+
+Use this skill for Zephyr SDK adoption and build-integrated deployment. It ships
+with every published Zephyr package, including supporting libraries that are not
+themselves build plugins. Do not assume the package containing this guide exports
+`withZephyr`; choose the actual integration for the application's stack.
+
+Prefer a more specific skill shipped alongside this one for its supported task,
+such as `zephyr-vite` or `create-zephyr-apps`. Check the installed integration's
+README, exported types, and peer compatibility before applying code examples.
+
+Zephyr is a build-integrated deployment platform for frontend and frontend-adjacent apps: it plugs into the build, publishes immutable versions, and lets users route traffic through tags and environments.
+
+## What to cover
+
+- Start with the smallest useful answer.
+- Prefer Zephyr's user-facing model first: setup -> build -> version URL -> tags/envs -> promote/rollback.
+- Use repo/code-path nuance only when it clarifies behavior or corrects docs drift.
+- If the question is really about remote resolution, hosts/remotes, `zephyr:dependencies`, or multi-bundler Module Federation, switch to `../zephyr-module-federation/SKILL.md`.
+- First-time users usually need: a supported stack or fallback upload path, Zephyr auth/account access, and git metadata for repo/branch/commit identity.
+
+## What Zephyr does
+
+- Zephyr integrates with the build and publishes immutable frontend versions.
+- Zephyr gives users permanent version URLs plus mutable tags and environments.
+- Zephyr can manage public runtime config overrides and deployment routing.
+- Zephyr does not replace the app's own framework/bundler config; it integrates into it.
+- Zephyr does not make public `ZE_PUBLIC_*` values secret.
+
+## Core mental model
+
+- Zephyr plugs into the app build through a bundler/framework integration.
+- A build creates an immutable version/snapshot and a permanent version URL.
+- Tags and environments are mutable pointers on top of immutable builds.
+- Promotion and rollback are mostly pointer changes, not rebuilds.
+- `ZE_PUBLIC_*` values can be captured at build time and overridden per environment later.
+
+## Answer flow
+
+1. Identify the user's stack and deployment goal.
+2. Read `references/sdk-setup.md` for setup guidance.
+3. Read `references/deployment-model.md` for versions, snapshots, tags, envs, and dashboard workflows.
+4. Read `references/env-vars.md` if the task mentions env vars, runtime config, build once deploy everywhere, or `ZE_PUBLIC_*`.
+5. Read `references/examples-resume.md` when the user wants concrete starter patterns.
+6. Read `references/docs-map.md` when deeper docs links are useful.
+7. Read `references/troubleshooting.md` when setup/build/auth/git issues appear.
+
+## Source priorities
+
+- Canonical public docs: `https://docs.zephyr-cloud.io`
+- Raw docs path pattern: `https://docs.zephyr-cloud.io/<path>.md`
+- Docs index: `https://docs.zephyr-cloud.io/llms.txt`
+- Community help: `https://discord.gg/zephyrcloud`
+- Architecture docs: `https://docs.zephyr-cloud.io/reference/architecture.md`
+- Public docs source: `https://docs.zephyr-cloud.io`
+- Examples source: `https://github.com/ZephyrCloudIO/zephyr-examples`
+
+## Guardrails
+
+- Do not invent SDK names; verify against `references/sdk-setup.md`.
+- Do not blur version vs tag vs environment; explain the distinction plainly.
+- Do not present `ZE_PUBLIC_*` as secret storage. They are public client-facing values.
+- Call out docs drift when relevant instead of silently repeating conflicting details.

package/skills/zephyr-core/references/deployment-model.md

@@ -0,0 +1,123 @@
+# Deployment Model
+
+Use this file when the user asks what Zephyr builds produce, what a snapshot is, how version URLs relate to tags/envs, what the dashboard deploy model is, or how rollback/promotion works.
+
+## Plain-English model
+
+- Build integration creates an immutable build artifact.
+- The user gets a permanent version URL for that exact build.
+- Tags and environments are mutable routing layers on top of immutable builds.
+- Rollback is fast because Zephyr changes pointers, not app artifacts.
+
+## Quick glossary
+
+| Term        | Meaning                                                        | Best use                                            |
+| ----------- | -------------------------------------------------------------- | --------------------------------------------------- |
+| Build       | The bundler/framework build that Zephyr observes and publishes | The starting action                                 |
+| Version     | Immutable deployed build state with a permanent URL            | Exact preview, debugging, rollback target           |
+| Snapshot    | Underlying stored artifact record for what was built on edge   | Internal precision when explaining architecture     |
+| Tag         | Mutable named selector, rule-based or manually pinned          | Moving channel like `main`, `beta`, `stable`        |
+| Environment | Mutable deployment target with config/domains/overrides        | Stable deploy target like `staging` or `production` |
+
+## Terms
+
+### Version
+
+- Immutable build state.
+- Has a permanent version URL.
+- Good for previewing, sharing, debugging, and exact rollback targets.
+
+### Snapshot
+
+- Edge-side record of what was built: assets + build identity.
+- In the architecture docs, snapshot and build-stats are different.
+- Snapshot is the immutable artifact record; build-stats are the metadata used by the async publish flow.
+
+Source: `https://docs.zephyr-cloud.io/reference/architecture.md`
+
+### Tag
+
+- Mutable named selector.
+- Usually resolves to the newest matching version based on rules, but can also be pinned manually to a fixed version.
+- Good for dynamic channels like `main`, `beta`, `release`, `stable`.
+
+### Environment
+
+- Mutable deployment target with its own config, domains, and optional overrides.
+- Can point to a tag or a fixed version.
+- Good for `development`, `staging`, `production`, previews, and white-label targets.
+- Can also be locked/protected in stricter production workflows.
+
+## Stage 0 vs Stage 1
+
+Use this if the user asks why a build returns before publish work is fully done.
+
+- Stage 0: upload files and snapshot fast; produce the version URL.
+- Stage 1: async publish flow computes and updates tags/envs/cnames.
+- `build-stats` acceptance does not mean every mutable target already switched.
+
+## URLs
+
+Version URL mental model:
+
+```text
+https://{username}-{buildId}-{app-name}-{project}-{hash}.{edge-domain}
+```
+
+Tag URL mental model:
+
+```text
+https://t-{tagname}-{app-uid}-{hash}.{domain}
+```
+
+Environment URL mental model:
+
+```text
+https://{env-name}-{app-uid}-{hash}.{domain}
+```
+
+Which URL to share:
+
+| URL             | Share when                                                     | Why                                 |
+| --------------- | -------------------------------------------------------------- | ----------------------------------- |
+| Version URL     | You need an exact build preview or debugging link              | Immutable                           |
+| Tag URL         | You want a moving channel like `main` or `beta`                | Follows tag resolution              |
+| Environment URL | You want the stable deployment target users or QA should visit | Carries environment behavior/config |
+
+## Dashboard workflow
+
+- Build creates versions automatically.
+- Dashboard lets users inspect versions and their metadata.
+- Users create tags with matching rules.
+- Users create environments that point to a tag or a fixed version.
+- Promotion usually means moving an environment or tag pointer to a chosen version.
+- Rollback usually means repointing back to an older known-good version.
+- Tags and environments can also be locked/protected to prevent accidental changes.
+
+## Built output notes worth calling out
+
+- Zephyr is deployment-first and build-integrated; it observes bundler output and uploads assets after build.
+- Docs describe a permanent version URL, and example/build output commonly surfaces that URL after build completes.
+- The public mental model should stay on version URL first; mention snapshot internals only when useful.
+
+## Smallest first-time path
+
+1. Identify the stack and pick the right SDK or fallback upload path.
+2. Run `with-zephyr` or add the correct Zephyr integration.
+3. Build the app.
+4. Start by using the version URL for exact preview/testing.
+5. Add tags or environments later when the user needs moving channels or stable deploy targets.
+
+## Correctness notes
+
+- Do not say tags are immutable; they are not.
+- Do not say environments are just aliases; they also carry config and custom-domain behavior.
+- Do not say snapshot is the same thing as version URL; the URL points at the immutable build, while snapshot is the stored artifact record underneath.
+
+## Best docs to link
+
+- Versions: `https://docs.zephyr-cloud.io/features/versions.md`
+- Tags & environments: `https://docs.zephyr-cloud.io/features/tags-environments.md`
+- Instant rollbacks: `https://docs.zephyr-cloud.io/features/instant-rollbacks.md`
+- Architecture: `https://docs.zephyr-cloud.io/reference/architecture.md`
+- Core concepts: `https://docs.zephyr-cloud.io/reference/concepts.md`

package/skills/zephyr-core/references/docs-map.md

@@ -0,0 +1,27 @@
+# Docs Map
+
+Use this file when you need to send the user to the right Zephyr docs quickly.
+
+## Main docs site
+
+- Site: `https://docs.zephyr-cloud.io`
+- Raw markdown path pattern: `https://docs.zephyr-cloud.io/<path>.md`
+- Up-to-date index: `https://docs.zephyr-cloud.io/llms.txt`
+- Discord help: `https://discord.gg/zephyrcloud`
+
+## Best first links
+
+- Quick start: `https://docs.zephyr-cloud.io/getting-started/quick-start.md`
+- SDK picker: `https://docs.zephyr-cloud.io/getting-started/find-your-sdk.md`
+- Core concepts: `https://docs.zephyr-cloud.io/reference/concepts.md`
+- Architecture: `https://docs.zephyr-cloud.io/reference/architecture.md`
+- Versions: `https://docs.zephyr-cloud.io/features/versions.md`
+- Tags & environments: `https://docs.zephyr-cloud.io/features/tags-environments.md`
+- Environment overrides: `https://docs.zephyr-cloud.io/features/environment-overrides.md`
+- Existing app integration: `https://docs.zephyr-cloud.io/integrations/existing-app.md`
+
+## When to route elsewhere
+
+- MF setup and remote resolution -> `../../zephyr-module-federation/SKILL.md`
+- BYOC/provider setup -> docs cloud section from `llms.txt`
+- Errors -> docs error encyclopedia

package/skills/zephyr-core/references/env-vars.md

@@ -0,0 +1,75 @@
+# Environment Variables
+
+Use this file when the user asks about `ZE_PUBLIC_*`, runtime config, build once deploy everywhere, or per-environment variable overrides.
+
+## Core rule
+
+- `ZE_PUBLIC_*` variables are public client-facing values captured at build time.
+- They are not secret storage.
+- Zephyr can override them per environment at runtime.
+- Public docs currently describe environment-level overrides as beta.
+
+## How it works
+
+1. Build-time capture: Zephyr records variables prefixed with `ZE_PUBLIC_`.
+2. Manifest generation: captured values are written into `zephyr-manifest.json`.
+3. Runtime override: an environment can inject different values without rebuilding.
+
+Why this matters: the same built artifact can run in development, staging, and production with different public config.
+
+This applies to public client-facing values. Secure server-only values are a separate concern and should not be modeled as `ZE_PUBLIC_*`.
+
+If the user asks where secrets should go instead, route them to the server-side environment variable path rather than public runtime overrides.
+
+## Example
+
+Build-time `.env`:
+
+```bash
+DATABASE_URL=postgres://localhost/myapp
+ZE_PUBLIC_API_URL=https://api.development.example.com
+ZE_PUBLIC_FEATURE_FLAGS=beta-ui,new-checkout
+ZE_PUBLIC_ANALYTICS_KEY=dev_analytics_12345
+```
+
+Application usage:
+
+```ts
+export const config = {
+  apiUrl: process.env.ZE_PUBLIC_API_URL,
+  flags: process.env.ZE_PUBLIC_FEATURE_FLAGS,
+  analyticsKey: process.env.ZE_PUBLIC_ANALYTICS_KEY,
+};
+```
+
+Environment-level overrides example:
+
+| Environment | ZE_PUBLIC_API_URL                 | ZE_PUBLIC_FEATURE_FLAGS          |
+| ----------- | --------------------------------- | -------------------------------- |
+| Development | `https://api.dev.example.com`     | `beta-ui,new-checkout,analytics` |
+| Staging     | `https://api.staging.example.com` | `new-checkout,analytics`         |
+| Production  | `https://api.example.com`         | `analytics`                      |
+
+## Remote overrides relationship
+
+The same environment-level override system also supports remote dependency overrides. If the user is asking about both env vars and remotes together, also read `../../zephyr-module-federation/references/remote-resolution.md`.
+
+## Dashboard flow
+
+- Go to the Zephyr dashboard DevOps section.
+- Select the environment.
+- Set override values for the `ZE_PUBLIC_*` entries.
+- Requests served from that environment use the environment values, not the original build-time values.
+
+## Guardrails
+
+- Keep secrets out of `ZE_PUBLIC_*`.
+- Do not tell users they need a rebuild for normal per-environment public config changes.
+- If the value is server-only or sensitive, Zephyr public env var overrides are the wrong tool.
+- If the user needs secure server-side environment variables, explain that this is a different path than public runtime overrides.
+
+## Best docs to link
+
+- Environment overrides: `https://docs.zephyr-cloud.io/features/environment-overrides.md`
+- Tags & environments: `https://docs.zephyr-cloud.io/features/tags-environments.md`
+- Architecture manifest section: `https://docs.zephyr-cloud.io/reference/architecture.md`

package/skills/zephyr-core/references/examples-resume.md

@@ -0,0 +1,81 @@
+# Examples Resume
+
+Use this file when the user wants concrete Zephyr setup examples for frontend stacks.
+
+## Fast starting points
+
+- Vite SPA: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/bundlers/react-vite`
+- Rspack SPA: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/bundlers/react-rspack`
+- TanStack Start: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/frameworks/tanstack-start`
+- Astro: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/frameworks/astro`
+- Cross-bundler MF: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/module-federation/react-vite-rspack-webpack`
+- Monorepo MF: `https://github.com/ZephyrCloudIO/zephyr-examples/tree/main/build-systems/turborepo-rspack-mf`
+
+Repo root: `https://github.com/ZephyrCloudIO/zephyr-examples`
+
+## Core pattern
+
+- Install the Zephyr integration that matches the stack.
+- Add `withZephyr()` to the plugin list or wrap the final config with it. Placement is stack-specific, not always last; follow the installed package's dedicated skill.
+- For special frameworks, use the framework-specific Zephyr integration instead of the generic bundler plugin.
+
+## Good references
+
+### Minimal Vite
+
+File: `https://github.com/ZephyrCloudIO/zephyr-examples/blob/main/bundlers/react-vite/vite.config.ts`
+
+```ts
+import { defineConfig } from 'vite';
+import react from '@vitejs/plugin-react';
+import { withZephyr } from 'vite-plugin-zephyr';
+
+export default defineConfig({
+  plugins: [react(), withZephyr()],
+});
+```
+
+### Minimal Rspack
+
+File: `https://github.com/ZephyrCloudIO/zephyr-examples/blob/main/bundlers/react-rspack/rspack.config.ts`
+
+```ts
+import { defineConfig } from '@rspack/cli';
+import { withZephyr } from 'zephyr-rspack-plugin';
+
+const config = defineConfig({
+  entry: { main: './src/main.tsx' },
+});
+
+export default withZephyr()(config);
+```
+
+### TanStack Start
+
+File: `https://github.com/ZephyrCloudIO/zephyr-examples/blob/main/frameworks/tanstack-start/vite.config.ts`
+
+```ts
+import { withZephyr } from 'vite-plugin-tanstack-start-zephyr';
+
+plugins: [tanstackStart(), viteReact(), withZephyr()];
+```
+
+### Astro
+
+File: `https://github.com/ZephyrCloudIO/zephyr-examples/blob/main/frameworks/astro/astro.config.mjs`
+
+```js
+import { defineConfig } from 'astro/config';
+import { withZephyr } from 'zephyr-astro-integration';
+
+export default defineConfig({
+  integrations: [mdx(), sitemap(), withZephyr()],
+});
+```
+
+## Gotchas worth reusing
+
+- Use the framework-specific integration when one exists.
+- Build remotes before hosts in MF setups.
+- Do not assume every example uses the same remote manifest format.
+- Cross-bundler MF hosts may need explicit remote `type` values.