# Editor settings for AI and publishing (/editor/settings) Related: [How to use the editor](/editor/tutorial.md), [Git essentials for the editor](/editor/git-essentials.md), [Create and edit pages](/editor/pages.md), [Organize navigation](/editor/navigation.md), [Live preview](/editor/live-preview.md), [Branching and publishing](/editor/branching-and-publishing.md) The web editor has two layers of settings: * **Your settings** apply only to you and control how the editor's AI assists with your edits. * **Publishing settings** apply to everyone on a deployment and shape what happens when you commit changes and turn them into pull requests. You can configure both from the settings panel. To open it, click the settings icon in the editor toolbar. ## AI instructions [#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. Each teammate maintains their own instructions, scoped to their user account. ### When to use AI instructions [#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 `` for callouts. Keep instructions short and specific. The AI follows them on every request, so vague or contradictory rules degrade results. ### Configure AI instructions [#configure-ai-instructions] 1. Click the settings icon in the editor toolbar. 2. In the **AI instructions** field, enter the guidance you want the AI to follow. 3. Save your changes. Example: ```text - 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 or 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] You configure publishing settings per deployment, and they apply to everyone who publishes from the editor. They control how the editor generates, opens, and merges pull requests and commits. You need admin access to your Mintlify deployment to change publishing settings. ### Lock the deployment branch [#lock-the-deployment-branch] To make your deployment branch (usually `main`) read-only in the editor, lock the deployment branch. Use this setting when your team wants all editor changes to create pull requests from feature branches. ### Pull request instructions [#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: ```text 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 [#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 [#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 editor uses the selected method 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. ## Danger zone [#danger-zone] The **Danger zone** section of the editor settings panel contains actions that can't be undone. Click the settings icon in the editor toolbar then scroll to **Danger zone**. ### Reset editor [#reset-editor] **Reset editor** forces the editor to discard its local state and sync with your Git repository. If the editor gets stuck out of sync with your repo, reset the editor. For example, if the file tree is empty or shows errors like `Unable to find docs.json` even though the file exists on your deployment branch and your live site builds normally. If you reset the editor, you discard any unpublished changes that you haven't committed to Git. If you have pending edits you want to keep, publish them first. To reset the editor: 1. Click the settings icon in the editor toolbar. 2. Scroll to **Danger zone**. 3. Click **Reset editor** and confirm. The editor reloads and pulls the latest state from your repository. ## Related [#related] * [Branching and publishing](/editor/branching-and-publishing) * [Configurations](/editor/configurations)