void 0.10.5 → 0.10.7

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/automatic-data-tracking.md

@@ -0,0 +1,145 @@
+# Automatic Data Tracking
+
+Automatic data tracking is how Vite Task learns what inputs a task needs for caching outputs without explicit config.
+
+When you run a cache-enabled task, Vite Task observes the task's execution and records what files were read and written, as well as any metadata reported by the task. On the next run, Vite Task uses the recorded fingerprint to decide whether to replay the cache or run the task.
+
+Use this page when you need to understand why a task hits or misses the cache, or when you need to decide whether to add `input`, `output`, `env`, or `untrackedEnv` config.
+
+## Tracking Tiers
+
+Automatic data tracking has two tiers:
+
+| Tier                 | Applies to                               | Records                                                                                                                                                         |
+| -------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| File system tracking | All tasks with cache enabled             | <ul><li>Files read by the command</li><li>Missing-file probes</li><li>Directory listings</li><li>Written output files</li></ul>                                 |
+| Cooperative tracking | Cache-reporting tools (`vp build` today) | <ul><li>Environment variables reported by the tool</li><li>Tool-managed paths that should not be inputs or outputs, such as `node_modules/.vite-temp`</li></ul> |
+
+Vite Task starts with file system tracking for any command. A cache-reporting tool can add information that only the tool knows while it runs.
+
+## File System Tracking
+
+File system tracking applies to every cache-enabled task. If you omit [`input`](/config/run#input), Vite Task tracks the files a command reads while it runs:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  run: {
+    tasks: {
+      build: {
+        command: 'tsc',
+      },
+    },
+  },
+});
+```
+
+For this task, Vite Task records source files, config files, missing files the command checked, and directories the command scanned. Subsequent runs re-run the task when one of those tracked inputs changes.
+
+File system tracking also tracks outputs. If you omit [`output`](/config/run#output), Vite Task archives files the command writes after a successful run and restores them on a cache hit.
+
+### Limitations
+
+Vite Task cannot track environment variable reads, and it cannot always tell which tracked paths are stable inputs, generated outputs, or tool-managed cache paths that should not become inputs or outputs.
+
+Use [Override Inputs And Outputs](#override-inputs-and-outputs) when file system tracking includes files that should not affect the cache, misses files that should, or restores the wrong outputs.
+
+Use [`env`](/config/run#env) when a command needs an environment variable and the value should affect the cache, or [`untrackedEnv`](/config/run#untrackedenv) when the value should not affect the cache.
+
+These limitations do not apply to `vp build`: Vite reports [Cooperative Tracking](#cooperative-tracking) metadata automatically, including `VITE_*`, `NODE_ENV`, and Vite-managed cache paths that should not become inputs or outputs. A standard `vp build` task does not need manual `input`, `output`, or `env`.
+
+### Override Inputs And Outputs
+
+[`input`](/config/run#input) controls what invalidates the cache. [`output`](/config/run#output) controls which files Vite Task restores on a cache hit.
+
+Both options use the same syntax and can be configured separately.
+
+- Omit the option to keep automatic tracking.
+- Add `{ auto: true }` to keep automatic tracking while adding glob rules.
+- Use string globs to include paths.
+- Use `!` globs to exclude paths.
+- Use `[]` to replace automatic tracking with an empty list.
+
+```ts [vite.config.ts]
+tasks: {
+  build: {
+    command: 'node build.mjs',
+
+    // Keep automatic input tracking, but exclude `dist` from inputs.
+    input: [{ auto: true }, '!dist/**'],
+
+    // Disable automatic output tracking and restore only `dist/**` on a cache hit.
+    output: ['dist/**'],
+  },
+}
+```
+
+Use explicit `input` globs only when you know the command's full input set. This lint task overrides inputs only, so output tracking stays automatic:
+
+```ts [vite.config.ts]
+tasks: {
+  lint: {
+    command: 'vp lint',
+    // Disable automatic input tracking and fingerprint only these files.
+    input: ['src/**', 'vite.config.ts'],
+  },
+}
+```
+
+Set `input: []` when no files should affect the cache fingerprint. This is rarely useful. For example, a download task can be cached when the same URL always serves the same file. No input files should be fingerprinted for this task, but changing the URL still invalidates the cache:
+
+```ts [vite.config.ts]
+tasks: {
+  downloadSchema: {
+    command: 'curl -O https://example.com/schema.json',
+    input: [],
+  },
+}
+```
+
+Set `output: []` when no files should be restored on a cache hit.
+
+## Cooperative Tracking
+
+File system tracking records access. It cannot know why a tool used each path.
+
+`vp build` knows more about a Vite build than Vite Task can infer from file access. When `vp build` runs with cache enabled, Vite reports that metadata to Vite Task. Vite Task merges the report with file system tracking to build a more accurate cache fingerprint.
+
+For a standard Vite build, you do not need to add these entries yourself because Vite reports them automatically at runtime:
+
+- `env: ['VITE_*']` or `env: ['NODE_ENV']`
+- `output: ['dist/**']`
+- input or output exclusions for temporary paths like `node_modules/.vite-temp`
+
+You only need to define the task with `vp build`:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  run: {
+    tasks: {
+      frontendBuild: 'vp build',
+    },
+  },
+});
+```
+
+Run this task with `vpr frontendBuild` or `vp run frontendBuild`.
+
+Manual config overrides reported metadata. Add `input`, `output`, `env`, or `untrackedEnv` when your project has behavior that Vite cannot report.
+
+Vite+ supports cooperative tracking for `vp build` today. It will extend this support to more first-party tools in the future. Third-party tools can report cache metadata with [`@voidzero-dev/vite-task-client`](https://npmx.dev/package/@voidzero-dev/vite-task-client).
+
+## When To Add Manual Config
+
+Add config when your project has behavior the command or tool cannot know.
+
+| Case                                                              | Example                                                                                         |
+| ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| Exclude an output directory from inputs                           | `input: [{ auto: true }, '!dist/**']`                                                           |
+| Exclude a temporary generated file from input and output tracking | `input: [{ auto: true }, '!.tmp/config.mjs']`<br>`output: [{ auto: true }, '!.tmp/config.mjs']` |
+| Avoid automatic file tracking for a task                          | `input: ['src/**']`<br>`output: ['dist/**']`                                                    |
+| Track and pass an env var                                         | `env: ['NODE_ENV']`                                                                             |
+| Pass an env var without fingerprinting it                         | `untrackedEnv: ['GITHUB_ACTIONS']`                                                              |

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/cache.md

@@ -4,23 +4,19 @@ Vite Task can automatically track dependencies and cache tasks run through `vp r
 
 ## Overview
 
-When a task runs successfully (exit code 0), its terminal output (stdout/stderr) is saved. On the next run, Vite Task checks if anything changed:
+When a task runs successfully (exit code 0), its terminal output (stdout/stderr) and all written files (output files) are saved. On the next run, Vite Task checks if anything changed:
 
 1. **Arguments:** did the [additional arguments](/guide/run#additional-arguments) passed to the task change?
 2. **Environment variables:** did any [fingerprinted env vars](/config/run#env) change?
-3. **Input files:** did any file that the command reads change?
+3. **Inputs:** did any input file that the command reads change?
 
-If everything matches, the cached output is replayed instantly, and the command does not run.
-
-::: info
-Currently, only terminal output is cached and replayed. Output files such as `dist/` are not cached. If you delete them, use `--no-cache` to force a re-run. Output file caching is planned for a future release.
-:::
+When all checks match, Vite Task replays the cached terminal output, restores saved output files, and skips the command.
 
 When a cache miss occurs, Vite Task tells you exactly why:
 
 ```
 $ vp lint ✗ cache miss: 'src/utils.ts' modified, executing
-$ vp build ✗ cache miss: env changed, executing
+$ vp build ✗ cache miss: env 'VITE_GREETING' changed, executing
 $ vp test ✗ cache miss: args changed, executing
 ```
 
@@ -36,7 +32,7 @@ A task can set [`cache: false`](/config/run#cache) to opt out. This cannot be ov
 
 ### 2. CLI flags
 
-`--no-cache` disables caching for everything. `--cache` enables caching for both tasks and scripts, which is equivalent to setting [`run.cache: true`](/config/run#run-cache) for that invocation.
+`--no-cache` disables caching for every task and script in that run. `--cache` enables caching for both tasks and scripts, which is equivalent to setting [`run.cache: true`](/config/run#run-cache) for that invocation.
 
 ### 3. Workspace config
 
@@ -47,29 +43,21 @@ The [`run.cache`](/config/run#run-cache) option in your root `vite.config.ts` co
 | `cache.tasks`   | `true`  | Cache tasks defined in `vite.config.ts` |
 | `cache.scripts` | `false` | Cache `package.json` scripts            |
 
-## Automatic File Tracking
-
-Vite Task tracks which files each command reads during execution. When a task runs, it records which files the process opens, such as your `.ts` source files, `vite.config.ts`, and `package.json`, and records their content hashes. On the next run, it re-checks those hashes to determine if anything changed.
-
-This means caching works out of the box for most commands without any configuration. Vite Task also records:
-
-- **Missing files:** if a command probes for a file that doesn't exist, such as `utils.ts` during module resolution, creating that file later correctly invalidates the cache.
-- **Directory listings:** if a command scans a directory, such as a test runner looking for `*.test.ts`, adding or removing files in that directory invalidates the cache.
-
-### Avoiding Overly Broad Input Tracking
+## Automatic Data Tracking
 
-Automatic tracking can sometimes include more files than necessary, causing unnecessary cache misses:
+Vite Task uses [automatic data tracking](/guide/automatic-data-tracking) to learn what each task needs for caching so you don't have to configure it manually. Automatic data tracking has two tiers:
 
-- **Tool cache files:** some tools maintain their own cache, such as TypeScript's `.tsbuildinfo` or Cargo's `target/`. These files may change between runs even when your source code has not, causing unnecessary cache invalidation.
-- **Directory listings:** when a command scans a directory, such as when globbing for `**/*.js`, Vite Task sees the directory read but not the glob pattern. Any file added or removed in that directory, even unrelated ones, invalidates the cache.
+- **File system tracking:** Vite Task records file reads, missing-file probes, directory listings, and written output files for every task with cache enabled.
+- **Cooperative tracking:** cache-reporting tools can report metadata that file system tracking cannot infer. Vite+ supports this for `vp build` today.
 
-Use the [`input`](/config/run#input) option to exclude files or to replace automatic tracking with explicit file patterns:
+Use [`input`](/config/run#input) or [`output`](/config/run#output) when a task needs manual tracking rules. `input` controls what invalidates the cache. `output` controls which files Vite Task restores on a cache hit.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
-    command: 'tsc',
-    input: [{ auto: true }, '!**/*.tsbuildinfo'],
+    command: 'node build.mjs',
+    input: [{ auto: true }, '!dist/**'],
+    output: ['dist/**'],
   },
 }
 ```
@@ -80,7 +68,7 @@ By default, tasks run in a clean environment. Only a small set of common variabl
 
 To add an environment variable to the cache key, add it to [`env`](/config/run#env). Changing its value then invalidates the cache:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
     command: 'webpack --mode production',
@@ -89,7 +77,7 @@ tasks: {
 }
 ```
 
-To pass a variable to the task **without** affecting cache behavior, use [`untrackedEnv`](/config/run#untracked-env). This is useful for variables like `CI` or `GITHUB_ACTIONS` that should be available in the task, but do not generally affect caching behavior.
+To pass a variable to the task **without** affecting cache behavior, use [`untrackedEnv`](/config/run#untrackedenv). This is useful for variables like `CI` or `GITHUB_ACTIONS` that should be available in the task, but do not affect caching behavior.
 
 See [Run Config](/config/run#env) for details on wildcard patterns and the full list of automatically passed-through variables.
 

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/check.md

@@ -42,3 +42,19 @@ export default defineConfig({
   },
 });
 ```
+
+### Disabling a step by default
+
+To make `vp check` skip formatting or linting without passing a flag every time, set the [`check`](/config/check) block in `vite.config.ts`. This is handy when a project wants the rest of the toolchain but not, say, formatting:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  check: {
+    fmt: false, // `vp check` lints (and type-checks) but does not format
+  },
+});
+```
+
+These options only affect `vp check`; standalone `vp fmt` and `vp lint` still run normally. A step is skipped if it is disabled in config or the matching `--no-fmt` / `--no-lint` flag is passed. Because the defaults apply to every `vp check` run, a pre-commit hook that calls `vp check` will skip the disabled step too. See [Check config](/config/check) for the full reference.

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/ci.md

@@ -10,10 +10,10 @@ That means you usually do not need separate `setup-node`, package-manager setup,
 
 ## GitHub Actions
 
-```yaml
+```yaml [.github/workflows/ci.yml]
 - uses: voidzero-dev/setup-vp@v1
   with:
-    node-version: '22'
+    node-version: '24'
     cache: true
 - run: vp install
 - run: vp check
@@ -23,36 +23,34 @@ That means you usually do not need separate `setup-node`, package-manager setup,
 
 With `cache: true`, `setup-vp` handles dependency caching for you automatically.
 
+::: tip
+`setup-vp` caches package-manager data. To reuse Vite Task results across CI runs, add a separate [GitHub Actions cache for Vite Task](/guide/github-actions-cache).
+:::
+
 ## Simplifying Existing Workflows
 
 If you are migrating an existing GitHub Actions workflow, you can often replace large blocks of Node, package-manager, and cache setup with a single `setup-vp` step.
 
 #### Before:
 
-```yaml
-- uses: actions/setup-node@v4
+```yaml [.github/workflows/ci.yml]
+- uses: pnpm/action-setup@v6
   with:
-    node-version: '24'
+    version: 11
 
-- uses: pnpm/action-setup@v4
+- uses: actions/setup-node@v6
   with:
-    version: 10
-
-- name: Get pnpm store path
-  run: pnpm store path
-
-- uses: actions/cache@v4
-  with:
-    path: ~/.pnpm-store
-    key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
+    node-version: '24'
+    cache: pnpm
 
-- run: pnpm install && pnpm dev:setup
+- run: pnpm ci && pnpm dev:setup
+- run: pnpm check
 - run: pnpm test
 ```
 
 #### After:
 
-```yaml
+```yaml [.github/workflows/ci.yml]
 - uses: voidzero-dev/setup-vp@v1
   with:
     node-version: '24'

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/commit-hooks.md

@@ -22,8 +22,17 @@ If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+
 ```bash
 vp config
 vp config --hooks-dir .vite-hooks
+vp config --no-hooks
+vp config --no-agent
 ```
 
+Use `--no-hooks` when you want `vp config` to leave existing Git hook setup unchanged. Use
+`--no-agent` when you want it to skip updates to existing coding agent instruction files. You
+can pass both flags when you want `vp config` to skip both setup steps.
+
+You can also set `VITE_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
+`prepare` or `postinstall`.
+
 ### `vp staged`
 
 `vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. If you set up Vite+ to handle your commit hooks, it will automatically run when you commit your local changes.

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/create.md

@@ -27,7 +27,7 @@ Vite+ ships with these built-in templates:
 - `vite:monorepo` creates a new monorepo
 - `vite:application` creates a new application
 - `vite:library` creates a new library
-- `vite:generator` creates a new generator
+- `vite:generator` creates a new code generator (monorepo only, see [Code Generators](#code-generators))
 
 ## Template Sources
 
@@ -35,7 +35,7 @@ Vite+ ships with these built-in templates:
 
 - Use shorthand templates like `vite`, `@tanstack/start`, `svelte`, `next-app`, `nuxt`, `react-router`, and `vue`
 - Use full package names like `create-vite` or `create-next-app`
-- Use local templates such as `./tools/create-ui-component` or `@acme/generator-*`
+- Use local monorepo templates declared in [`create.templates`](#code-generators) (for example an internal component or service generator)
 - Use remote templates such as `github:user/repo` or `https://github.com/user/template-repo`
 
 Run `vp create --list` to see the built-in templates and the common shorthand templates Vite+ recognizes.
@@ -44,13 +44,29 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 
 - `--directory <dir>` writes the generated project into a specific target directory
 - `--agent <name>` creates agent instructions files during scaffolding
+- `--no-agent` skips agent instruction setup
 - `--editor <name>` writes editor config files
+- `--no-editor` skips editor config setup
+- `--git` initialize a git repository
+- `--no-git` skips git repository initialization
 - `--hooks` enables pre-commit hook setup
 - `--no-hooks` skips hook setup
+- `--package-manager <name>` uses a specified package manager (`pnpm`, `npm`, `yarn`, or `bun`)
+- `--approve-builds` approves and runs gated dependency build scripts without prompting
 - `--no-interactive` runs without prompts
 - `--verbose` shows detailed scaffolding output
 - `--list` prints the available built-in and popular templates
 
+### Dependency build scripts
+
+For security, pnpm, bun, and yarn (Berry) do not run a dependency's build scripts (`install` / `postinstall`, e.g. native builds like `better-sqlite3`) until you approve them. When a template adds such a dependency directly, `vp create` surfaces it after installing instead of leaving the project in a half-built state:
+
+- Interactive: you are asked which of those dependencies to approve and build (nothing is selected by default).
+- Non-interactive: a note lists them and points at `vp pm approve-builds`.
+- `--approve-builds`: approves and builds them automatically, so non-interactive runs (CI) can produce a ready-to-use project.
+
+Approval is recorded the way each package manager expects: pnpm's `allowBuilds`, bun's `trustedDependencies`, or yarn's `dependenciesMeta.<pkg>.built` (in the workspace root manifest). Transitive build scripts you did not choose (e.g. `esbuild` pulled in by Vite) are left at the package manager's defaults and are not surfaced. npm runs build scripts by default, so there is nothing to approve there.
+
 ## Template Options
 
 Arguments after `--` are passed directly to the selected template.
@@ -86,3 +102,240 @@ vp create create-next-app
 vp create github:user/repo
 vp create https://github.com/user/template-repo
 ```
+
+## Code Generators
+
+Monorepos often need to scaffold their own building blocks: a UI component, a service, or an internal package that follows house conventions. Vite+ supports this through generator packages powered by [Bingo](https://www.create.bingo/) templates.
+
+### Scaffold a generator
+
+Inside a Vite+ monorepo, run:
+
+```bash
+vp create vite:generator
+```
+
+This requires a monorepo workspace. If you don't have one yet, create it first with `vp create vite:monorepo`.
+
+The scaffolded generator package contains:
+
+- `src/template.ts` defines the template using `createTemplate` from `bingo`: an options schema built with [Zod](https://zod.dev/) and a `produce()` function that returns the files to generate
+- `bin/index.ts` is the CLI entry, powered by Bingo's `runTemplateCLI`
+
+If the monorepo has a parent directory matching `generators` or `tools`, the new package is placed there by default.
+
+### Registration
+
+Local generators are declared in [`create.templates`](/config/create#create-templates) in the monorepo's `vite.config.ts`. This is the source of truth: only registered templates appear in the `vp create` picker.
+
+`vp create vite:generator` registers the generator for you, adding an entry to `create.templates` in the root `vite.config.ts`:
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    templates: [
+      { name: 'my-generator', description: 'Generate new components', template: 'my-generator' },
+    ],
+  },
+});
+```
+
+Re-running is idempotent (no duplicate entries), and an existing `create.defaultTemplate` is preserved. You can also add entries by hand, for example to register a template you didn't scaffold this way. The `template` value is the generator's workspace package name, or a relative `./path` to it.
+
+### Run a generator
+
+Inside the monorepo, run `vp create` and pick the generator from the template list, or pass its entry `name` directly:
+
+```bash
+# Interactive mode lists registered local templates alongside the built-ins
+vp create
+
+# Run a registered template by its name
+vp create component
+
+# Pass options to the generator after --
+vp create component -- --name @your-org/button
+```
+
+When the generator depends on `bingo`, Vite+ appends `--skip-requests` automatically so it skips Bingo's outbound network requests (such as GitHub API calls).
+
+After the generator runs, the created package goes through the regular monorepo integration: workspace registration, dependency installation, and formatting.
+
+### Customize a generator
+
+Edit `src/template.ts` to define the options and the files to produce:
+
+```ts
+import { createTemplate } from 'bingo';
+import { z } from 'zod';
+
+export default createTemplate({
+  options: {
+    name: z.string().describe('Package name'),
+  },
+  async produce({ options }) {
+    return {
+      files: {
+        'package.json': JSON.stringify({ name: options.name, version: '0.0.0' }, null, 2),
+        src: {
+          'index.ts': `export const name = '${options.name}';\n`,
+        },
+      },
+    };
+  },
+});
+```
+
+- `options` defines the generator's prompts and flags using Zod schemas
+- `produce()` returns the [files](https://www.create.bingo/build/concepts/creations#files) to create, plus optional [scripts](https://www.create.bingo/build/concepts/creations#scripts) to run after generation and [suggestions](https://www.create.bingo/build/concepts/creations#suggestions) to print for the user
+
+See the [Bingo documentation](https://www.create.bingo/) for the full template API.
+
+## Organization Templates
+
+An organization can publish a curated set of templates under a single npm scope by shipping an `@org/create` package whose `package.json` carries a `createConfig.templates` manifest. Once published, `vp create @org` opens an interactive picker over those templates.
+
+### Pick from an org
+
+```bash
+# Open an interactive picker over @your-org/create's manifest
+vp create @your-org
+
+# Run a specific manifest entry directly
+vp create @your-org:web
+
+# Pin to an exact version or a dist-tag
+vp create @your-org@1.2.3
+vp create @your-org:web@next
+
+# Set the org as the default for a repo (see create.defaultTemplate config)
+vp create
+```
+
+Behind the scenes, `vp create @org` maps to `@org/create` (the existing npm `create-*` convention). If that package has no `createConfig.templates` field, Vite+ falls back to running the package normally — so adopting the manifest is zero-risk for orgs that already publish `@org/create`.
+
+Private registries work automatically: Vite+ reads `.npmrc` files from the project root and `~/`, honoring `@your-org:registry=...` scope mappings and `//host/:_authToken=...` credentials.
+
+### Authoring `@org/create`
+
+There are two common layouts. Pick the one that matches the org's template count and release cadence.
+
+**Bundled (recommended for most orgs).** All templates live as subdirectories of `@org/create` itself. Manifest entries use relative `./path` values. One repo, one publish, one versioning story — the same pattern used by `create-vite` and `create-next-app`.
+
+```
+@your-org/create/
+├── package.json              # "createConfig": { "templates": [{ "template": "./templates/web" }, ...] }
+├── templates/
+│   ├── web/
+│   │   ├── package.json
+│   │   └── src/...
+│   └── library/...
+└── README.md
+```
+
+**Manifest-only.** When the org already publishes independent `@org/template-*` packages (or hosts them on GitHub), `@org/create` stays a thin index.
+
+```
+@your-org/create/
+├── package.json              # "createConfig": { "templates": [{ "template": "@your-org/template-web" }, ...] }
+└── README.md
+```
+
+The two layouts can be mixed — a manifest can point most entries at external packages and keep a few as bundled subdirectories.
+
+Optionally, provide a `bin` script so `npm create @org` (the legacy path) keeps working for non-Vite+ users. `vp create @org` reads the manifest directly and never runs the `bin`.
+
+### Manifest schema
+
+The manifest lives at `createConfig.templates` in `@org/create`'s `package.json`:
+
+```json
+{
+  "name": "@your-org/create",
+  "version": "1.0.0",
+  "createConfig": {
+    "templates": [
+      {
+        "name": "monorepo",
+        "description": "Monorepo",
+        "template": "@your-org/template-monorepo",
+        "monorepo": true
+      },
+      {
+        "name": "web",
+        "description": "Web app template (Vite + React)",
+        "template": "@your-org/template-web"
+      },
+      {
+        "name": "demo",
+        "description": "Bundled demo template",
+        "template": "./templates/demo"
+      }
+    ]
+  }
+}
+```
+
+Each entry supports:
+
+| Field         | Required | Notes                                                                                                                                                                                                                                      |
+| ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `name`        | yes      | Kebab-case identifier. Used by `vp create @org:<name>` for direct selection. Must be unique within the array.                                                                                                                              |
+| `description` | yes      | One-line description shown in the picker.                                                                                                                                                                                                  |
+| `template`    | yes      | An npm specifier (`@org/template-foo`, optionally `@version`), a GitHub URL (`github:user/repo`), a `vite:*` builtin, a local workspace package name, or a relative path (`./templates/foo`) that resolves against the `@org/create` root. |
+| `monorepo`    | no       | If `true`, marks this entry as a monorepo-creating template. Hidden from the picker when `vp create` runs inside an existing monorepo, mirroring the built-in `vite:monorepo` filter.                                                      |
+
+An invalid manifest is a hard error, not a silent fall-through — a maintainer who shipped a manifest should hear about the offending field, e.g. `@your-org/create: createConfig.templates[2].template must be a non-empty string`.
+
+### Bundled subdirectory templates
+
+Relative `./...` paths resolve against the enclosing `@org/create` package root — **not** the user's cwd. The referenced directory is copied into the target project as-is (no template-engine processing); the only exception is that a small set of underscore-prefixed scaffold files (`_gitignore`, `_npmrc`, `_yarnrc.yml`) are renamed to their dotfile equivalents. Paths that escape the package root are rejected.
+
+### Make the org the default in a repo
+
+Commit this in `vite.config.ts` at the project root:
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: { defaultTemplate: '@your-org' },
+});
+```
+
+Now `vp create` (with no argument) drops straight into the `@your-org` picker. See [`create.defaultTemplate`](/config/create) for details.
+
+The picker always appends a trailing **Vite+ built-in templates** entry so `vite:monorepo` / `vite:application` / `vite:library` / `vite:generator` stay reachable from the picker — selecting it routes to the standard built-in flow. For scripts and CI, explicit specifiers (`vp create vite:library`) bypass the configured default.
+
+### Non-interactive inspection
+
+`vp create @org --no-interactive` prints the manifest as a table and exits 1:
+
+```
+A template name is required when running `vp create @your-org` in non-interactive mode.
+
+Available templates in @your-org/create:
+
+  NAME     DESCRIPTION                          TEMPLATE
+  web      Web app template (Vite + React)      @your-org/template-web
+  library  TypeScript library template          @your-org/template-library
+  demo     Bundled demo template                ./templates/demo
+
+Examples:
+  # Scaffold a specific template from the org
+  vp create @your-org:web --no-interactive
+
+  # Or use a Vite+ built-in template
+  vp create vite:application --no-interactive
+```
+
+### Publishing checklist
+
+1. Create `@org/create` (scoped npm package) if you don't already have one.
+2. Add a `createConfig.templates` array to `package.json`. (Bundle the templates under `./templates/...` or point at external packages.)
+3. (Optional) Provide a `bin` launcher for `npm create @org` compatibility.
+4. Publish.
+5. Verify: `vp create @org --no-interactive` prints the manifest table; `vp create @org` opens the picker.
+6. (Optional) Commit `create: { defaultTemplate: '@org' }` in your internal template repos.