diff --git a/docs/5.x/ai/mcp.md b/docs/5.x/ai/mcp.md
index 1295e38b..d6dc9bc7 100644
--- a/docs/5.x/ai/mcp.md
+++ b/docs/5.x/ai/mcp.md
@@ -20,8 +20,8 @@ generation, validates schemas, and scaffolds configuration from the chat.
 
 ## Starting the server
 
-Run the server with one command. It communicates over stdio, the transport that every major LLM
-client speaks.
+Run the server with one command. See [`kubb mcp`](/docs/5.x/reference/commands/mcp#usage) for the
+stdio transport it uses.
 
 ```shell [Terminal]
 kubb mcp
diff --git a/docs/5.x/community/faq.md b/docs/5.x/community/faq.md
index 3886c2a0..58a801fb 100644
--- a/docs/5.x/community/faq.md
+++ b/docs/5.x/community/faq.md
@@ -61,16 +61,9 @@ Yes. Each plugin exposes a `resolver` option to rename operations and types, and
 
 ### Can I run multiple configs in one command?
 
-Yes. Pass an array to `defineConfig`. Each entry has its own `input`, `output`, and `plugins`.
-
-```typescript twoslash [kubb.config.ts]
-import { defineConfig } from 'kubb/config'
-
-export default defineConfig([
-  { input: './specs/users.yaml', output: { path: './src/gen/users' }, plugins: [] },
-  { input: './specs/orders.yaml', output: { path: './src/gen/orders' }, plugins: [] },
-])
-```
+Yes. Pass an array to `defineConfig` and each entry generates from its own `input`, `output`, and
+`plugins`. See [multiple configurations](/docs/5.x/reference/configuration#multiple-configurations-array)
+for the shape and how to combine it with the function form.
 
 ### Does Kubb work inside a bundler (Vite, webpack, etc.)?
 
diff --git a/docs/5.x/getting-started/basic-usage.md b/docs/5.x/getting-started/basic-usage.md
index 1239c2f6..53152a14 100644
--- a/docs/5.x/getting-started/basic-usage.md
+++ b/docs/5.x/getting-started/basic-usage.md
@@ -22,7 +22,7 @@ export default defineConfig({
 })
 ```
 
-`input` accepts a local file path, a URL, inline OpenAPI content, or a parsed object. `output.clean: true` wipes the output directory before each run, so stale files don't pile up.
+[`input`](/docs/5.x/reference/configuration#input) accepts a file path, URL, inline spec, or parsed object, and [`output.clean: true`](/docs/5.x/reference/configuration#output-clean) wipes the output directory before each run so stale files don't pile up.
 
 ## 2. Pick your plugins
 
diff --git a/docs/5.x/getting-started/installation.md b/docs/5.x/getting-started/installation.md
index 54c84480..33ca97c7 100644
--- a/docs/5.x/getting-started/installation.md
+++ b/docs/5.x/getting-started/installation.md
@@ -107,7 +107,7 @@ See the [plugins](/plugins) page for a complete list.
 
 ### 3. Create `kubb.config.ts`
 
-Create a `kubb.config.ts` file in your project root. The config points Kubb at your spec and your output directory, and `defineConfig` wires up the OpenAPI adapter, the default parsers, and a barrel plugin for you. Here is a minimal starting point:
+Create a `kubb.config.ts` file in your project root. The config points Kubb at your spec and your output directory, and `defineConfig` wires up the [OpenAPI adapter, the default parsers, and a barrel plugin](/docs/5.x/reference/kit/engine#defaults-applied-for-omitted-fields) for you. Here is a minimal starting point:
 
 ```typescript twoslash [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/docs/5.x/guide/concepts/architecture.md b/docs/5.x/guide/concepts/architecture.md
index f2b25a5a..3ef4895d 100644
--- a/docs/5.x/guide/concepts/architecture.md
+++ b/docs/5.x/guide/concepts/architecture.md
@@ -25,7 +25,7 @@ Every run moves through four stages. Select one to see what it does, or watch it
 
 ## Config
 
-`defineConfig` from `kubb/config` pre-wires [`adapterOas`](/docs/5.x/guide/concepts/adapters), the default parsers [`parserTs`, `parserTsx`, `parserMd`](/docs/5.x/guide/concepts/parsers), and [`pluginBarrel`](/plugins/plugin-barrel/). A minimal config only needs `input` and `output`.
+`defineConfig` from `kubb/config` pre-wires the [adapter](/docs/5.x/guide/concepts/adapters), the default [parsers](/docs/5.x/guide/concepts/parsers), and the [barrel plugin](/plugins/plugin-barrel/), so a minimal config only needs `input` and `output`. See the [defaults table](/docs/5.x/reference/kit/engine#defaults-applied-for-omitted-fields) for exactly what each field resolves to.
 
 ```typescript twoslash [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/docs/5.x/guide/concepts/generators.md b/docs/5.x/guide/concepts/generators.md
index a7d2c101..24a4fc4c 100644
--- a/docs/5.x/guide/concepts/generators.md
+++ b/docs/5.x/guide/concepts/generators.md
@@ -19,11 +19,7 @@ A plugin registers its generators during [plugin setup](/docs/5.x/guide/concepts
 
 ## What each method handles
 
-A generator implements up to three methods, and each maps to a slice of the spec:
-
-- `schema` runs once per data schema. It is where types, validators, and mock factories come from.
-- `operation` runs once per API operation. It builds request hooks, clients, and route handlers.
-- `operations` runs a single time with the whole set at once. Reach for it when an index or a router has to see every operation before it writes anything.
+A generator implements up to three methods, each for a different slice of the spec: `schema` for one data schema at a time, `operation` for one API operation at a time, and `operations` once with the whole set, for output like an index or a router that needs to see everything before it writes anything. See the [generator methods table](/docs/5.x/reference/kit/generators#generator-methods) for what each one returns and exactly when it runs.
 
 Each method receives the generator context and returns the files that node becomes. It can hand back file nodes directly, return a renderer element, or write through the context and return nothing. The [generator reference](/docs/5.x/reference/kit/generators) lists every field on that context.
 
diff --git a/docs/5.x/guide/concepts/plugins.md b/docs/5.x/guide/concepts/plugins.md
index 98c25cde..27f0c10f 100644
--- a/docs/5.x/guide/concepts/plugins.md
+++ b/docs/5.x/guide/concepts/plugins.md
@@ -57,7 +57,7 @@ Plugins rarely work alone. A client plugin leans on the types a TypeScript plugi
 
 ## Post-enforced plugins
 
-Most plugins run in one normal pass, but some need to see what everyone else produced first. A barrel generator can only write its index files once the other plugins have emitted what it re-exports. `enforce: 'post'` moves a plugin to the end of every event it listens to, and `enforce: 'pre'` moves it to the front. Neither overrides dependencies: a declared dependency always runs first. [`@kubb/plugin-barrel`](/plugins/plugin-barrel/) is the one to read when this fits your case.
+Most plugins run in one normal pass, but some need to see what everyone else produced first. A barrel generator can only write its index files once the other plugins have emitted what it re-exports. Setting a plugin's [`enforce`](/docs/5.x/reference/kit/plugins#plugin-shape) field moves it to the front or the back of every event it listens to, though a declared dependency always runs first regardless. [`@kubb/plugin-barrel`](/plugins/plugin-barrel/) is the one to read when this fits your case.
 
 ## Built-in plugins
 
diff --git a/docs/5.x/guide/concepts/renderers.md b/docs/5.x/guide/concepts/renderers.md
index bbc1cfe6..f22a71fe 100644
--- a/docs/5.x/guide/concepts/renderers.md
+++ b/docs/5.x/guide/concepts/renderers.md
@@ -15,7 +15,7 @@ A renderer is the step between what a generator returns and the `FileNode`s the
 
 Building files by hand with `ast.factory` is precise, but it gets verbose once a file has imports, several declarations, and JSDoc. JSX reads better for that, letting a generator describe output as components and nesting instead of a flat list of `create*` calls. Keeping the renderer separate means the generator does not care which style produced the file, since the engine gets `FileNode`s either way.
 
-Kubb ships [`kubb/jsx`](/docs/5.x/reference/jsx) for the JSX path. Its `jsxRenderer` is React-free: components run as plain functions, so hooks and suspense are not available. A generator turns it on by setting its `renderer` field.
+Kubb ships [`kubb/jsx`](/docs/5.x/reference/jsx) for the JSX path, turned on per generator through its `renderer` field. See [`jsxRenderer`](/docs/5.x/reference/kit/renderers#jsxrenderer-via-kubb-jsx) for why it runs without React.
 
 ## When you write your own
 
diff --git a/docs/5.x/guide/going-further/barrel-files.md b/docs/5.x/guide/going-further/barrel-files.md
index ed4006ae..10605113 100644
--- a/docs/5.x/guide/going-further/barrel-files.md
+++ b/docs/5.x/guide/going-further/barrel-files.md
@@ -44,7 +44,7 @@ export default defineConfig({
 
 ## Choose an export style
 
-`type` is required whenever `output.barrel` is set to an object, and accepts `'named'` or `'all'`. Use `'named'` to re-export each symbol by name, which keeps tree-shaking accurate and imports explicit. Use `'all'` for a smaller barrel that re-exports everything with `export *`.
+`type` picks the export style: `'named'` re-exports each symbol by name for accurate tree-shaking, `'all'` re-exports everything with `export *`. See [`type`](/plugins/plugin-barrel/reference/options#type) for when it's required and its full type.
 
 ::: code-group
 
@@ -68,7 +68,7 @@ export * from './api/types/User'
 
 A plugin inherits `output.barrel` from `config.output.barrel` when it sets none of its own. Override it on the plugin to change or drop that plugin's barrel.
 
-Set `barrel: { type, nested: true }` on a plugin to write an `index.ts` in every subdirectory, so callers can import from any depth. The root `output.barrel` has no `nested` field and always stays flat.
+Set `barrel: { type, nested: true }` on a plugin to write an `index.ts` in every subdirectory instead of one flat barrel. See [`nested`](/plugins/plugin-barrel/reference/options#nested) for what each barrel re-exports at that setting. The root `output.barrel` has no `nested` field.
 
 ```typescript twoslash [Nested barrels]
 import { defineConfig } from 'kubb/config'
@@ -97,7 +97,7 @@ export default defineConfig({
 
 ## Turn barrels off
 
-`barrel: false` is already the default, so a fresh config needs no change. Set it explicitly on `defineConfig` to override a root barrel enabled elsewhere, for example a shared base config. Every plugin without its own `output.barrel` inherits the `false`, while a plugin that sets its own non-false `output.barrel` keeps its barrel.
+`barrel: false` is already the default, so a fresh config needs no change. Set it explicitly on `defineConfig` to override a root barrel enabled elsewhere, for example a shared base config. See [`output.barrel`](/plugins/plugin-barrel/reference/options#output-barrel) for how a plugin's own setting overrides that inherited value.
 
 ```typescript twoslash [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/docs/5.x/guide/going-further/creating-plugins.md b/docs/5.x/guide/going-further/creating-plugins.md
index ba501c45..c91c6b3a 100644
--- a/docs/5.x/guide/going-further/creating-plugins.md
+++ b/docs/5.x/guide/going-further/creating-plugins.md
@@ -273,7 +273,7 @@ A generator walks the [AST](/docs/5.x/guide/concepts/ast) produced by the [adapt
 | `operation`  | Each `OperationNode` in the AST                         | `Array<FileNode>`, an element, or `null`/`undefined` |
 | `operations` | Once with all `OperationNode`s after the operation walk | `Array<FileNode>`, an element, or `null`/`undefined` |
 
-Each handler can return a Promise of any of these.
+Each handler can return a Promise of any of these. See the [generator methods table](/docs/5.x/reference/kit/generators#generator-methods) for the full reference entry.
 
 ### Emit roles
 
@@ -361,6 +361,8 @@ Users override your plugin's resolver through its `resolver` option in `kubb.con
 | `config`          | The resolved `Config` at setup time.                                              |
 | `options`         | The user-supplied plugin options.                                                 |
 
+See the [`KubbPluginSetupContext` methods table](/docs/5.x/reference/kit/plugins#kubbpluginsetupcontext-methods-passed-to-kubb-plugin-setup) for the full reference entry.
+
 ```typescript twoslash [setup-context.ts]
 import { fileURLToPath } from 'node:url'
 import { ast, definePlugin, defineGenerator } from 'kubb/kit'
diff --git a/docs/5.x/guide/recipes.md b/docs/5.x/guide/recipes.md
index 9933548f..dfdc622b 100644
--- a/docs/5.x/guide/recipes.md
+++ b/docs/5.x/guide/recipes.md
@@ -176,7 +176,7 @@ export default defineConfig({
 
 ## Run a command after generation
 
-Use [`output.postGenerate`](/docs/5.x/reference/configuration#output-postgenerate) to run shell commands once the generated files are formatted and linted. Pass a command string, or `{ name, command }` to label a step. Commands run relative to the project root, in sequence.
+Use [`output.postGenerate`](/docs/5.x/reference/configuration#output-postgenerate) to run shell commands, such as a formatter pass or a type check, once the generated files are formatted and linted.
 
 ```typescript twoslash [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
@@ -252,9 +252,7 @@ export default defineConfig({
 
 ## Programmatic build
 
-Drive Kubb from a script with [`createKubb`](/docs/5.x/reference/kit/engine#createkubb) from the `kubb` package, paired with `Diagnostics` from `kubb/kit`. This fits monorepo orchestration and custom build pipelines.
-
-Unlike `defineConfig`, `createKubb` adds no defaults. Pass `adapter`, `parsers`, and your plugins yourself.
+Drive Kubb from a script with [`createKubb`](/docs/5.x/reference/kit/engine#createkubb) from the `kubb` package, paired with `Diagnostics` from `kubb/kit`. This fits monorepo orchestration and custom build pipelines. Unlike `defineConfig`, `createKubb` takes no defaults, so the script below passes `adapter`, `parsers`, and plugins explicitly.
 
 ```typescript twoslash [generate.ts]
 import { createKubb } from 'kubb'
diff --git a/docs/5.x/migration.md b/docs/5.x/migration.md
index 18655504..7d62b93a 100644
--- a/docs/5.x/migration.md
+++ b/docs/5.x/migration.md
@@ -246,12 +246,12 @@ The [adapter page](/docs/5.x/migration/adapter-oas) has the full table and befor
 
 ### Formatting and linting are off by default
 
-`output.format` and `output.lint` both default to `false` in v5, so generation skips formatting and linting unless you opt in (v4 defaulted `format` to `'prettier'` and `lint` to `'auto'`). The accepted values are unchanged (`'auto'`, `'prettier'`, `'biome'`, `'oxfmt'`, `false` for format; `'auto'`, `'eslint'`, `'biome'`, `'oxlint'`, `false` for lint), but `'auto'` now prefers the oxc tools first.
+`output.format` and `output.lint` both default to `false` in v5, so generation skips formatting and linting unless you opt in (v4 defaulted `format` to `'prettier'` and `lint` to `'auto'`). The accepted values are unchanged, but `'auto'` now prefers the oxc tools first. See [`output.format`](/docs/5.x/reference/configuration#output-format) and [`output.lint`](/docs/5.x/reference/configuration#output-lint) for the full value lists and detection order.
 
-| Option          | v4 default   | v5 default | `'auto'` detection order                                                                 |
-| --------------- | ------------ | ---------- | ---------------------------------------------------------------------------------------- |
-| `output.format` | `'prettier'` | `false`    | [oxfmt](https://oxc.rs) → [biome](https://biomejs.dev) → [prettier](https://prettier.io) |
-| `output.lint`   | `'auto'`     | `false`    | [oxlint](https://oxc.rs) → [biome](https://biomejs.dev) → [eslint](https://eslint.org)   |
+| Option          | v4 default   | v5 default |
+| --------------- | ------------ | ---------- |
+| `output.format` | `'prettier'` | `false`    |
+| `output.lint`   | `'auto'`     | `false`    |
 
 ### `output.barrelType` → `output.barrel` {#output-barreltype-output-barrel}
 
@@ -435,13 +435,7 @@ export default defineConfig({
 
 ### `--debug` becomes reporters
 
-The `--debug` flag and the `debug` value of `--logLevel` are gone. v5 renders a run through reporters. The `--reporter` flag (comma-separated) selects which run, defaulting to `cli`, and the config `reporters` key registers the ones available. `defineConfig` registers the three built-ins for you.
-
-| Reporter          | Output                                                                  |
-| ----------------- | ----------------------------------------------------------------------- |
-| `cli` _(default)_ | The end-of-run summary in the terminal.                                 |
-| `json`            | A stable machine-readable report on stdout, for CI.                     |
-| `file`            | A log written to `.kubb/kubb-<name>-<timestamp>.log`. This replaces `--debug`. |
+The `--debug` flag and the `debug` value of `--logLevel` are gone. v5 renders a run through reporters instead, registered by the config `reporters` key (`defineConfig` registers the three built-ins for you) and selected at the CLI with `--reporter`, defaulting to `cli`. The `file` reporter replaces `--debug`, writing the same kind of log to `.kubb/kubb-<name>-<timestamp>.log`. See [Reporters](/docs/5.x/reference/commands/generate#reporters) for what `cli`, `json`, and `file` each output.
 
 ```diff [Terminal]
 -kubb generate --debug
diff --git a/docs/5.x/migration/plugin-client.md b/docs/5.x/migration/plugin-client.md
index 72e57c82..8c766e4f 100644
--- a/docs/5.x/migration/plugin-client.md
+++ b/docs/5.x/migration/plugin-client.md
@@ -68,7 +68,7 @@ pluginAxios({ sdk: { name: 'petStore' } })
 
 :::
 
-With `sdk` set, `mode: 'tag'` (the default) emits one class per tag, and a `name` composes them into a root class that builds every tag client from one config. Use `mode: 'flat'` for a single class with every operation as a direct method.
+`sdk.mode: 'tag'` (the default) emits one class per tag, and adding `sdk.name` composes them into a root class that builds every tag client from one config. See [`sdk`](/plugins/plugin-axios/reference/options#sdk) for the full option, including the single-class `mode: 'flat'`.
 
 ## Remove `dataReturnType` and read the result
 
@@ -81,7 +81,7 @@ With `sdk` set, `mode: 'tag'` (the default) emits one class per tag, and a `name
 
 ## `parser` is renamed to `validator`
 
-v4 `parser` took `'client'` or `'zod'` and defaulted to `'client'`. v5 renames the option to `validator`. It defaults to `false` and accepts `'zod'` or `{ request, response }` to validate request and response bodies with schemas from `@kubb/plugin-zod`. The `'client'` value is gone, so `parser: 'zod'` becomes `validator: 'zod'`, and `parser: 'client'` becomes the default `false`.
+v4 `parser` took `'client'` or `'zod'` and defaulted to `'client'`. v5 renames the option to `validator`, drops the `'client'` value, and defaults to `false`: `parser: 'zod'` becomes `validator: 'zod'`, and `parser: 'client'` becomes the default `false`. See [`validator`](/plugins/plugin-axios/reference/options#validator) (the same option on `@kubb/plugin-fetch`) for what `'zod'` and the per-direction `{ request, response }` form check.
 
 ## Authentication comes from the spec
 
diff --git a/docs/5.x/migration/plugin-react-query.md b/docs/5.x/migration/plugin-react-query.md
index d0ead817..3f9114b1 100644
--- a/docs/5.x/migration/plugin-react-query.md
+++ b/docs/5.x/migration/plugin-react-query.md
@@ -174,4 +174,4 @@ The `hooks` option controls whether `use*` functions are emitted alongside the f
   })
 ```
 
-With `hooks: false` (the default) the plugin still emits `queryOptions`, `mutationOptions`, `queryKey`, and `mutationKey`. Only the `useQuery`, `useSuspenseQuery`, `useInfiniteQuery`, `useSuspenseInfiniteQuery`, and `useMutation` wrappers are skipped.
+With `hooks: false` (the default) the plugin still emits the `queryOptions`/`mutationOptions` factories and their keys. Only the `use*` wrapper hooks are skipped. See [`hooks`](/plugins/plugin-react-query/reference/options#hooks) for exactly which functions each setting emits.
diff --git a/docs/5.x/migration/plugin-ts.md b/docs/5.x/migration/plugin-ts.md
index 32c2f326..022d6085 100644
--- a/docs/5.x/migration/plugin-ts.md
+++ b/docs/5.x/migration/plugin-ts.md
@@ -113,20 +113,13 @@ export default defineConfig({
 :::
 
 > [!TIP]
-> Set `constCasing: 'pascalCase'` with `typeSuffix: ''` to emit a const and a type that share the schema's exact name. Most hand-written codebases use this convention, so existing annotations and value references keep working.
+> Set `constCasing: 'pascalCase'` with `typeSuffix: ''` to emit a const and a type that share the schema's exact name, the convention most hand-written codebases already use, so existing annotations and value references keep working.
 >
 > ```typescript [v5 kubb.config.ts]
 > pluginTs({ enum: { type: 'asConst', constCasing: 'pascalCase', typeSuffix: '' } })
 > ```
 >
-> ```typescript [Generated output]
-> export const VehicleType = {
->   Sedan: 'Sedan',
->   SUV: 'SUV',
-> } as const
->
-> export type VehicleType = (typeof VehicleType)[keyof typeof VehicleType]
-> ```
+> See [`enum.typeSuffix`](/plugins/plugin-ts/reference/options#enum-typesuffix) for why an empty suffix merges the const and type names.
 
 ## Generated output
 
diff --git a/docs/5.x/migration/plugin-vue-query.md b/docs/5.x/migration/plugin-vue-query.md
index 9f216800..2df99587 100644
--- a/docs/5.x/migration/plugin-vue-query.md
+++ b/docs/5.x/migration/plugin-vue-query.md
@@ -55,7 +55,7 @@ Same grouped-options change as [React Query](/docs/5.x/migration/plugin-react-qu
 
 ## `hooks` defaults to `false`
 
-As on [React Query](/docs/5.x/migration/plugin-react-query#hooks-defaults-to-false), the `hooks` default changed from `true` to `false`. Set `hooks: true` to keep the `use*` composables. With the default, Vue Query still emits `queryOptions`, `queryKey`, and `mutationKey`, skipping only the `useQuery`, `useInfiniteQuery`, and `useMutation` composables.
+As on [React Query](/docs/5.x/migration/plugin-react-query#hooks-defaults-to-false), the `hooks` default changed from `true` to `false`, so existing configs that relied on generated composables must now opt in with `hooks: true`. See [`hooks`](/plugins/plugin-vue-query/reference/options#hooks) for exactly which composables each setting emits.
 
 ## Generated output
 
diff --git a/docs/5.x/reference/commands/generate.md b/docs/5.x/reference/commands/generate.md
index 63069206..96409727 100644
--- a/docs/5.x/reference/commands/generate.md
+++ b/docs/5.x/reference/commands/generate.md
@@ -65,7 +65,7 @@ A reporter decides how a run is rendered. The config registers available reporte
 | Reporter | Output                                                                          |
 | -------- | ------------------------------------------------------------------------------- |
 | `cli`    | The end-of-run summary in the terminal. This runs when you pass no flag.        |
-| `json`   | A machine-readable report on stdout (`status`, `counts`, `timings`, `diagnostics`) for CI. |
+| `json`   | A machine-readable report on stdout for CI. See [Diagnostics](/docs/5.x/reference/diagnostics#machine-readable-output) for the full JSON shape. |
 | `file`   | The run's diagnostics, written to `.kubb/kubb-<name>-<timestamp>.log`.          |
 
 Write a log file:
diff --git a/parsers/parser-ts/index.md b/parsers/parser-ts/index.md
index 3862b932..7ace5988 100644
--- a/parsers/parser-ts/index.md
+++ b/parsers/parser-ts/index.md
@@ -46,7 +46,7 @@ The package exports two parser factories, and Kubb selects one by the file exten
 - `parserTs()` handles `.ts` and `.js` files.
 - `parserTsx()` handles `.tsx` and `.jsx` files. Use it for React projects so JSX in generated components is preserved.
 
-Both accept an `extension` option that rewrites the extensions emitted in `import`/`export` statements, for example `parserTs({ extension: { '.ts': '.js' } })` to emit `.js` imports from `.ts` sources for an ESM dual package. A custom `parsers` array replaces the default set (`parserTs`, `parserTsx`, `parserMd`), and files whose extension has no registered parser are written by joining their sources verbatim, so list every parser your plugins need.
+Both accept the same [`extension`](/parsers/parser-ts/reference/options#extension) option to rewrite the import and export extensions they emit, for example to emit `.js` imports from `.ts` sources in an ESM dual package. A custom `parsers` array replaces the default set (`parserTs`, `parserTsx`, `parserMd`), and files whose extension has no registered parser are written by joining their sources verbatim, so list every parser your plugins need.
 
 ## Installation
 
diff --git a/plugins/plugin-axios/index.md b/plugins/plugin-axios/index.md
index 427071c9..958d2601 100644
--- a/plugins/plugin-axios/index.md
+++ b/plugins/plugin-axios/index.md
@@ -72,10 +72,10 @@ From your spec, the generated client gives you:
 - A [status-keyed result](/plugins/plugin-axios/guide/error-handling) on every call, or a thrown `ResponseError`.
 - [Auth](/plugins/plugin-axios/guide/authentication) resolved from your OpenAPI security schemes.
 - [Serialization](/plugins/plugin-axios/guide/serialization) of parameters and bodies across content types, including `multipart/form-data` uploads and binary downloads.
-- Runtime [validation](#validator) against [`@kubb/plugin-zod`](/plugins/plugin-zod/) schemas.
+- Runtime [validation](/plugins/plugin-axios/reference/options#validator) against [`@kubb/plugin-zod`](/plugins/plugin-zod/) schemas.
 - Typed [server-sent events](/plugins/plugin-fetch/guide/server-sent-events) you read with `for await`.
 - [Interceptors](/plugins/plugin-axios/guide/interceptors) and a [custom transport](/plugins/plugin-axios/guide/transport) for the send.
-- Standalone functions or a class-based [SDK](#sdk).
+- Standalone functions or a class-based [SDK](/plugins/plugin-axios/reference/options#sdk).
 
 It builds on `@kubb/plugin-ts` for the types, so add that to your config, and axios is a runtime dependency to install next to your app.
 
diff --git a/plugins/plugin-barrel/index.md b/plugins/plugin-barrel/index.md
index c6122f92..6656998b 100644
--- a/plugins/plugin-barrel/index.md
+++ b/plugins/plugin-barrel/index.md
@@ -48,7 +48,7 @@ resources:
 
 `@kubb/plugin-barrel` writes the `index.ts` barrel files. It adds one barrel per plugin output directory and one root barrel at `output.path/index.ts`. This runs after the build finishes, so you import everything from one entry point, like `import { Pet, usePetByIdQuery, petMock } from './gen'`.
 
-The plugin is registered by default in `defineConfig`, but `output.barrel` defaults to `false`, so no barrels are written until you set it, root or per-plugin. A plugin inherits `output.barrel` from `config.output.barrel` when it sets none of its own. Set `barrel: false` on a plugin to skip its barrel and drop its files from the root barrel.
+The plugin is registered by default in `defineConfig`, but barrels stay off until you configure [`output.barrel`](/plugins/plugin-barrel/reference/options#output-barrel), root or per-plugin. See that reference entry for how the default, inheritance, and overrides work.
 
 ## Installation
 
diff --git a/plugins/plugin-mcp/index.md b/plugins/plugin-mcp/index.md
index 9e2efed8..d7d48545 100644
--- a/plugins/plugin-mcp/index.md
+++ b/plugins/plugin-mcp/index.md
@@ -86,7 +86,7 @@ This plugin needs three other plugins. `@kubb/plugin-ts` and `@kubb/plugin-zod`
 - [`@kubb/plugin-zod`](/plugins/plugin-zod/) for the schemas that validate each tool call.
 - [`@kubb/plugin-axios`](/plugins/plugin-axios/) or [`@kubb/plugin-fetch`](/plugins/plugin-fetch/) for the HTTP client the handlers call.
 
-A client plugin is required, since the handlers call its generated functions. Register one of them and set [`client`](#client) only when both are present.
+A client plugin is required, since the handlers call its generated functions. Register one of them and set [`client`](/plugins/plugin-mcp/reference/options#client) only when both are present.
 
 ## Example
 
diff --git a/plugins/plugin-mcp/recipes/choose-the-client-when-two-are-registered.md b/plugins/plugin-mcp/recipes/choose-the-client-when-two-are-registered.md
index 93e88805..68df3850 100644
--- a/plugins/plugin-mcp/recipes/choose-the-client-when-two-are-registered.md
+++ b/plugins/plugin-mcp/recipes/choose-the-client-when-two-are-registered.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Choose the client when two are registered
 
-Set [`client`](/plugins/plugin-mcp/reference/options#client) to `'axios'` or `'fetch'` when both client plugins are present, so the handlers know which one to call. `pluginAxios` and `pluginFetch` both default `output.path` to `clients`, so give each its own path here too, otherwise the second one registered overwrites the first's generated files.
+Set [`client`](/plugins/plugin-mcp/reference/options#client) to `'axios'` or `'fetch'` when both client plugins are present, so the handlers know which one to call. [`pluginAxios`](/plugins/plugin-axios/reference/options#output-path) and [`pluginFetch`](/plugins/plugin-fetch/reference/options#output-path) both default `output.path` to `clients`, so give each its own path here too, otherwise the second one registered overwrites the first's generated files.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/plugins/plugin-msw/index.md b/plugins/plugin-msw/index.md
index 0e5a3f32..31a4421d 100644
--- a/plugins/plugin-msw/index.md
+++ b/plugins/plugin-msw/index.md
@@ -51,7 +51,7 @@ resources:
 
 `@kubb/plugin-msw` turns your OpenAPI spec into [MSW](https://mswjs.io/) request handlers you drop into a test setup or a service worker to mock the API. Each handler matches the spec's path, method, status, and response body.
 
-By default a handler returns an empty typed payload you fill in from tests. Set `parser: 'faker'` to return generated data from `@kubb/plugin-faker` instead.
+By default a handler returns an empty typed payload you fill in from tests. Set [`parser: 'faker'`](/plugins/plugin-msw/reference/options#parser) to return generated data from `@kubb/plugin-faker` instead.
 
 ## Installation
 
diff --git a/plugins/plugin-react-query/recipes/custom-query-keys.md b/plugins/plugin-react-query/recipes/custom-query-keys.md
index 31768752..fb0121c8 100644
--- a/plugins/plugin-react-query/recipes/custom-query-keys.md
+++ b/plugins/plugin-react-query/recipes/custom-query-keys.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Custom query keys
 
-Pass a [`queryKey`](/plugins/plugin-react-query/reference/options#querykey) builder to control the array TanStack Query uses to cache and invalidate a hook's data. The callback receives the operation node and returns the key array, and string values are inlined verbatim, so wrap a literal in `JSON.stringify(...)`.
+Pass a [`queryKey`](/plugins/plugin-react-query/reference/options#querykey) builder to control the array TanStack Query uses to cache and invalidate a hook's data.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/plugins/plugin-react-query/recipes/wrap-hooks-with-shared-options.md b/plugins/plugin-react-query/recipes/wrap-hooks-with-shared-options.md
index 5a37757d..8a3f781e 100644
--- a/plugins/plugin-react-query/recipes/wrap-hooks-with-shared-options.md
+++ b/plugins/plugin-react-query/recipes/wrap-hooks-with-shared-options.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Wrap every hook with shared options
 
-Set [`customOptions`](/plugins/plugin-react-query/reference/options#customoptions) to route every generated hook through your own function, so shared behavior like `onSuccess` or `select` stays in one place instead of repeated per call. The plugin also emits a `HookOptions` type so your wrapper stays in sync with the generated hooks.
+Set [`customOptions`](/plugins/plugin-react-query/reference/options#customoptions) to route every generated hook through your own function, so shared behavior like `onSuccess` or `select` stays in one place instead of repeated per call. It also emits a `HookOptions` type, used below to type the wrapper's return value.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/plugins/plugin-ts/recipes/tree-shakeable-enums.md b/plugins/plugin-ts/recipes/tree-shakeable-enums.md
index c8f4494e..805a7dde 100644
--- a/plugins/plugin-ts/recipes/tree-shakeable-enums.md
+++ b/plugins/plugin-ts/recipes/tree-shakeable-enums.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Tree-shakeable enums
 
-Set [`enum.type`](/plugins/plugin-ts/reference/options#enum-type) to `'asConst'` to emit each enum as an `as const` object plus a companion key type. The object carries no runtime beyond its values, so bundlers drop what you do not use. Switch the value to `'enum'`, `'literal'`, or `'inlineLiteral'` for the other shapes.
+Set [`enum.type`](/plugins/plugin-ts/reference/options#enum-type) to `'asConst'` to emit each enum as an `as const` object plus a companion key type. The object carries no runtime beyond its values, so bundlers drop what you do not use. See the [option reference](/plugins/plugin-ts/reference/options#enum-type) for the other representations `enum.type` can produce.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/plugins/plugin-vue-query/recipes/custom-query-keys.md b/plugins/plugin-vue-query/recipes/custom-query-keys.md
index 5ef330b6..86530769 100644
--- a/plugins/plugin-vue-query/recipes/custom-query-keys.md
+++ b/plugins/plugin-vue-query/recipes/custom-query-keys.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Custom query keys
 
-Pass a [`queryKey`](/plugins/plugin-vue-query/reference/options#querykey) builder to control the array TanStack Query uses to cache and invalidate a hook's data. The callback receives the operation node and returns the key array, and string values are inlined verbatim, so wrap a literal in `JSON.stringify(...)`.
+Pass a [`queryKey`](/plugins/plugin-vue-query/reference/options#querykey) builder to control the array TanStack Query uses to cache and invalidate a hook's data, wrapping string literals in `JSON.stringify(...)` since the builder inlines values verbatim.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'
diff --git a/plugins/plugin-zod/recipes/validate-every-api-response.md b/plugins/plugin-zod/recipes/validate-every-api-response.md
index 245a2b65..947eb52a 100644
--- a/plugins/plugin-zod/recipes/validate-every-api-response.md
+++ b/plugins/plugin-zod/recipes/validate-every-api-response.md
@@ -7,7 +7,7 @@ outline: deep
 
 # Validate every API response
 
-Generate the Zod schemas, then point a client at them. Setting the Fetch client's [`validator`](/plugins/plugin-fetch/reference/options#validator) to `'zod'` runs every response body through the matching schema at runtime. To validate request bodies too, use the object form `{ request: 'zod', response: 'zod' }`.
+Generate the Zod schemas, then point a client at them. Setting the Fetch client's [`validator`](/plugins/plugin-fetch/reference/options#validator) to `'zod'` runs every response body through the matching schema at runtime. The option also accepts an object form to validate request bodies too.
 
 ```typescript [kubb.config.ts]
 import { defineConfig } from 'kubb/config'