docs: link to reference pages instead of restating their content

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

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.)?
 

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
 

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'

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'

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.
 

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
 

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
 

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'

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'

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'

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

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
 

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.

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
 

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
 

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: