> ## Documentation Index
> Fetch the complete documentation index at: https://livingcontext.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Editing and change requests
> Draft, review, and merge documentation changes on a real git branch.
A change request (CR) is an editing session backed by a real git branch. It is the review unit for everything that changes your docs — your own edits, a teammate's draft, or a batch of agent proposals. Nothing in a CR touches published docs until you merge.
Quick single-page fixes don't need a CR — the docs viewer supports [direct editing in place](/guides/docs-viewer#editing-in-place). Reach for a CR when the change spans files, restructures navigation, or should be reviewed before it ships.
## Starting a change request
Three ways in:
* **The Edit button on Docs** — if drafts are already open, a **Continue an edit** dialog lists your drafts and your team's, with a **Start a new edit** button; otherwise a fresh draft starts immediately.
* **The branch switcher** in the top bar — pick any open draft by branch name, or create a new one.
* **From the Inbox** — ship accepted agent proposals with **Open as a change request instead**. See [Inbox](/guides/inbox).
## Anatomy of a change request
The CR header shows:
* **Back to Docs** — return to the viewer at any time.
* **Branch switcher** — jump between open branches; the hover shows `your-branch → default-branch`.
* **Title** — editable while the CR is a draft.
* **Status chip** — **Draft**, **Merged**, or **Closed**.
* **View tabs** — **Overview**, **Editor**, and **Preview**.
* **Merge button** and the **Agent** panel toggle.
## Editor modes
Inside the Editor view, each file offers three modes:
| Mode | What you see |
| --------------- | ----------------------------------------------------------------------------------------- |
| **Visual mode** | A rich WYSIWYG editor — headings, tables, callouts, diagrams |
| **Source mode** | The raw markdown |
| **View diff** | An old-vs-new comparison against the base branch (a **Back to editing** pill returns you) |
The sidebar also toggles between two layouts: **Navigation** (tabs and sections, as readers will see them) and **Files** (every file on the branch).
## Working on the branch
Everything you'd expect from a branch is available:
* Create, rename, and delete files — the changes stay on the branch until merge.
* Edit sections and tabs: create, rename, and reorder them, and move files across tabs. Moving between tabs has an explicit menu option, so you never have to rely on drag alone.
* Saving is **explicit** — there is no autosave in a CR. A saving/saved indicator shows exactly where you stand.
Unsaved changes block destructive operations. If you try to delete or move something while an edit is pending, save first — this prevents losing work you haven't committed to the branch.
## The doc agent in a CR
The **Agent** toggle opens the same doc agent you get on Docs. Describe the change you want — "add a troubleshooting section for the login flow", "update this diagram to include the new approval step" — and the agent proposes targeted edits.
Proposals appear as **inline tracked-change suggestions**, Google-Docs style. A review bar counts the pending agent edits and steps you through them:
* **Accept** or **reject** each suggestion individually — clicking a suggestion shows a card describing the addition, deletion, or rewrite.
* **Accept all** or **reject all** in one action.
* Nothing is written to the branch until you accept.
See [Doc editor agent](/agents/doc-editor-agent) for mentions, pinned selections, and skills.
## Merging
The **Merge** button opens a change manifest — every changed file badged **Added**, **Modified**, or **Deleted**, with one-click access to each diff — and two ways to apply:
| Option | What happens |
| -------------------- | ---------------------------------------------------------------------- |
| **Merge now** | Apply the changes to the default branch straight away |
| **Request a review** | Open a pull request in your git provider for teammates to review first |
Merging asks you to confirm — **"Publish these changes?"** — because it makes your edits live for everyone and closes the draft. On success you land back in the [docs viewer](/guides/docs-viewer) with the fresh content already live.
What you can do here follows your [role](/admin/roles-and-permissions): Editors see only **Request a review**; Reviewers, Creators, and Administrators can merge directly.
## Managing your change requests
The **Change requests** page lists every CR across your tracked repos — filter by repo or by **All / Drafts / Merged / Closed**. Each row shows the author, the branch, a `PR #N` chip when a pull request exists, and a menu to **Open**, **Rename**, or **Close** a draft (closing deletes the branch, after a confirmation).
## Reviewing and sharing
Share a CR link with anyone in your organization. Viewers without edit rights get a **read-only view** — they can read the pages and browse the diffs, but the editor and destructive actions are disabled.
## Typical flow
Start one from the docs viewer's Edit button, from the [Inbox](/guides/inbox) when shipping agent proposals, or from [Commits](/guides/commits) after generating drafts.
Work in Visual or Source mode, use the agent for targeted edits, and save explicitly as you go.
Switch to View diff on any file, or open the Merge manifest to step through every change.
Click **Merge now** — or **Request a review** to finish in a pull request. Either way, you land back in the docs viewer with the content published once it merges.