> ## Documentation Index
> Fetch the complete documentation index at: https://docs.octen.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# CLAUDE

# Octen Documentation

Mintlify-based product docs for Octen (docs.octen.ai).

## Setup

* Local preview: `mint dev --port 3000` (run from repo root)
* Navigation, theme, and redirects live in `docs.json`
* Check links before publishing: `mint broken-links`

## Core rules

1. **Never fabricate.** Do not guess URLs, slugs, parameters, product behavior, or numbers. Verify against source files (`api-reference/openapi.json`, existing pages) or ask. If unsure, leave a `{/* TODO: ... */}` and ask; never invent.
2. **Be concise.** No redundancy. If one sentence is enough, don't write two.
3. **Match existing docs.** Before writing a page, read similar existing pages and follow their structure, terminology, and formatting.
4. **No unrequested changes.** Do not restructure navigation, rename pages, or touch files beyond the current task without explicit approval.

## Product names (never change these)

Broad Search, Web Search, Image Search, Video Search, Extract, Model Gateway, Embedding, VL Embedding, Answer, Deep Research.

## OpenAPI

* `api-reference/openapi.json` is the source of truth for endpoints, parameters, and responses.
* API Reference page slugs come from each operation's `operationId` (e.g. `/api-reference/deep-research`).
* Never edit `openapi.json` with scripts or reformatters. Only precise, minimal manual edits, confirmed beforehand.

## MDX rules

* Comments must use `{/* ... */}`. HTML comments (`<!-- -->`) silently break the entire page: it renders as an empty fallback.
* Every page needs frontmatter with `title`. `description` is optional; omit it when it would just repeat the opening paragraph.
* Internal links use relative paths (`/capabilities/extract`), not absolute URLs.
* All code blocks declare a language tag. Only include code examples you have verified work.

## Writing style

* Imperative mood for steps and instructions ("Send one query", not "You send one query"). Second person ("your query", "when you need…") only where natural. No "users", "developers", or "we".
* Keep paragraphs short: one idea per paragraph. If a paragraph states a problem and then the solution, split it in two.
* Never use the em dash (—) as a connector in prose. Use a comma, colon, semicolon, period, or parentheses instead.
* Lead with what the reader gets; put prerequisites before procedures.
* US English, sentence-style capitalization in body text.
* Section headings (H2) use Title Case ("How It Works", "Next Steps", "Model Choices"); keep it consistent across same-level headings. Scenario H3 titles stay sentence case.