Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify-docs-editor-ui-appearance-settings.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

The web editor has two layers of settings:
  • Your settings apply only to you. They control the editor layout and how the editor’s AI assists with your edits.
  • Publishing settings apply to everyone on a deployment and shape what happens when changes are committed and turned into pull requests.
You can configure both from the Settings menu in the editor.

​
UI and appearance

UI and appearance settings are scoped to your user account. Changes apply across every deployment you open in the editor and sync to your other devices. Open Settings in the editor and select UI & Appearance to update these preferences. Choose the default view for the left-hand navigation panel:
  • Docs navigation: Shows pages grouped the same way they appear on your published site, using the structure defined in docs.json. Best when you think about your docs in terms of where readers find each page.
  • File tree: Shows the underlying repository file system, including assets, snippets, and files that aren’t part of docs.json. Best for repo-level tasks like renaming files or working with images.
You can still switch between views at any time from the sidebar — this setting only controls which view opens by default.

​
Fit editor to full width

Turn this on to let the editing canvas expand to fill the available horizontal space instead of keeping the default reading-width column. Use full width when you’re working with wide tables, large code blocks, or side-by-side components. Leave it off to match the line length readers see on your published site.

​
Open live preview in a new tab

By default, the live preview opens as an overlay inside the dashboard. Turn this on to open the preview in a new browser tab instead. A separate tab is useful when you want to:
  • Keep the preview visible on a second monitor while you edit.
  • Resize the preview window independently of the dashboard.
  • Reload or share the preview URL without leaving the editor.

​
AI instructions

AI instructions are persistent guidance that the editor sends to the AI alongside your request. Use them to capture style and tone rules you don’t want to repeat every time, like voice, terminology, or formatting conventions. Your instructions apply to:
  • Edit with AI actions on a selection, such as rewrite, expand, or fix.
  • Agent sessions started from the editor.
Instructions are scoped to your user account, so each teammate maintains their own.

​
When to use AI instructions

Add AI instructions when you find yourself repeating the same guidance in prompts, for example:
  • Enforcing second-person voice or sentence case headings.
  • Preferring specific product names or terminology.
  • Banning marketing language or filler phrases.
  • Requiring certain components, like always using <Note> for callouts.
Keep instructions short and specific. The AI follows them on every request, so vague or contradictory rules degrade results.

​
Configure AI instructions

  1. Open the editor and click your avatar in the toolbar.
  2. Select Settings.
  3. In the AI instructions field, enter the guidance you want the AI to follow.
  4. Save your changes.
Example: 
- Use second person ("you") and active voice.
- Use sentence case for all headings.
- Refer to the product as "Acme" — never "Acme Inc." or "the platform".
- Wrap notes and warnings in <Note> or <Warning> components.
- Do not add introductory filler like "In this guide" or "Let's explore".
Leave the field empty to remove your instructions.

​
Publishing settings

Publishing settings are configured per deployment and apply to everyone who publishes from the editor. They control how pull requests and commits are generated, opened, and merged. You need admin access to your Mintlify deployment to change publishing settings.

​
Commit message instructions

Commit message instructions guide the AI when it generates a commit message for a publish. The editor uses them whenever you publish without typing your own message. Use commit message instructions to match an existing convention in your repository, for example:
  • Conventional Commits (docs(editor): ...).
  • A required ticket or issue prefix.
  • A maximum subject length stricter than the 72-character default.
Example: 
Follow Conventional Commits. Use the "docs" type and an "editor" scope
for content changes (for example, "docs(editor): clarify quickstart steps").
Keep the subject under 60 characters.
If your repository enforces a commit message regex, the editor still validates against it after generation.

​
Pull request instructions

Pull request instructions guide the AI when it generates a pull request title and description. They apply whenever the editor opens a pull request on your behalf, including from Create pull request and Merge and publish flows. Use pull request instructions to standardize what reviewers see, for example:
  • Required sections like Summary and Changes.
  • A description template that links to a tracking system.
  • Tone or length requirements for titles.
Example: 
Title: imperative mood, under 70 characters, no trailing period.
Description: include a "## Summary" section (one sentence) and a
"## Changes" section as a bulleted list. Link any referenced page
using its relative path.

​
Create pull requests as drafts by default

Turn this on to have the editor open every new pull request in draft state. You can’t merge a draft pull request until you mark it ready for review. This is useful when:
  • Your team requires a manual review pass before a pull request is open for approval.
  • You want to share preview URLs without signaling that the change is ready to merge.
You can still mark a pull request as ready for review from your Git provider.

​
Default merge method

Choose how the editor merges pull requests when you click Merge and publish:
  • Merge: Creates a merge commit that preserves the full branch history.
  • Squash: Combines all commits in the branch into a single commit on your deployment branch.
  • Rebase: Replays each commit from the branch onto your deployment branch without a merge commit.
The selected method is used by default. If you pass an explicit merge method through the API or your Git provider’s UI, that choice takes precedence.
Match your default merge method to your Git provider’s branch protection settings. If your deployment branch only allows squash merges, set the default to Squash to avoid failed merges from the editor.