CLAUDE.md — Mintlify Documentation

Content Accuracy

Never invent steps, options, field names, descriptions, or any other content. Only document what is confirmed from code, the OpenAPI spec, or screenshots provided by the user.
When anything is not 100% clear and defined — a page’s content, a feature’s behaviour, a field name, a UI flow — stop and ask the user before writing anything. This applies to stub pages, descriptions, frontmatter, and prose alike.
Never state a count of supported models or entities without reading it from the actual data source. If unsure, omit the count and link to the relevant page instead.
Do not add “Coming Soon” sections unless explicitly instructed.

NEVER use em dashes (—) anywhere, in any context, including prose. This is a hard rule with no exceptions. Rewrite the sentence using commas, colons, or by splitting into two sentences.
After every edit to any file, grep the modified file for — before moving on. If any match is found, fix it before proceeding.
Never use hyphens as separators between a term and its description (e.g. **Term** - description). Use a colon instead: **Term**: description.
Bold all product name mentions inline (e.g. Orq.ai, AI Router, AI Chat).
Capitalize orq.ai product entity names in prose and links: Evaluators, Identities, Deployments, Agents, Prompts, Threads, etc.
Page titles follow the pattern: "Product | Page Name" (e.g. "AI Router | Credits").
Use Mintlify <Icon /> components instead of describing icons in prose (e.g. <Icon icon="ellipsis" /> instead of “click the three dots”).
No warnings or disclaimers about AI making mistakes.
No self-referential comments in any output.

Be as brief as possible. High signal-to-noise ratio. No complete sentences needed, no filler, no summaries of what was just done.

Do not agree with suggestions just because they are made. Verify claims independently before accepting them. If something is debatable or unverified, say so clearly and push back with evidence or honest uncertainty.
Never present opinions as facts.