diff --git a/peach/README.md b/peach/README.md
new file mode 100644
index 0000000..ecd4ae7
--- /dev/null
+++ b/peach/README.md
@@ -0,0 +1,36 @@
+# Peach Theme (Help Center)
+
+Example Help Center site using the Peach theme.
+
+## Structure
+
+```
+├── index.mdx # Homepage (hero + search + group tiles)
+├── getting-started/
+│ ├── index.mdx # Directory page (frontmatter-only)
+│ ├── quick-setup.mdx # Article
+│ ├── first-project.mdx # Article
+│ └── invite-team.mdx # Article
+├── billing/
+│ ├── index.mdx # Directory page
+│ ├── change-plan.mdx # Article
+│ ├── invoices.mdx # Article
+│ └── payment/
+│ ├── index.mdx # Sub-category directory page
+│ ├── add-card.mdx # Article
+│ └── bank-transfer.mdx # Article
+├── integrations/
+│ ├── index.mdx # Directory page
+│ ├── slack.mdx # Article
+│ └── github.mdx # Article
+└── docs.json
+```
+
+## Key differences from docs themes
+
+- `root` is **required** on every group (every category is visitable)
+- Directory pages (group root pages with empty body) auto-render a `` of children
+- If a root page has content, the directory listing is shown alongside it (like API playground pages)
+- `description` and `image` for categories come from the root page's **frontmatter**, not `docs.json`
+- Breadcrumbs default to on (`styling.eyebrows: "breadcrumbs"`)
+- Navigation is tile/list-based instead of sidebar
diff --git a/peach/account-security/audit-logs.mdx b/peach/account-security/audit-logs.mdx
new file mode 100644
index 0000000..f213e69
--- /dev/null
+++ b/peach/account-security/audit-logs.mdx
@@ -0,0 +1,23 @@
+---
+title: "Audit logs"
+description: "Track who changed settings, published updates, or modified access-sensitive parts of the workspace."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "history"
+---
+
+Audit logs help security, support, and content owners answer an important question quickly: **what changed, and who changed it?**
+
+## Common events to review
+
+- user invitations and removals
+- permission changes
+- authentication setting changes
+- production publishes
+- integration updates
+
+
+ Audit logs are especially useful during incident review. When a site changes unexpectedly, start
+ by confirming whether the cause was a content publish, a settings change, or an access update.
+
diff --git a/peach/account-security/data-privacy.mdx b/peach/account-security/data-privacy.mdx
new file mode 100644
index 0000000..0de005d
--- /dev/null
+++ b/peach/account-security/data-privacy.mdx
@@ -0,0 +1,31 @@
+---
+title: "Data privacy"
+description: "Understand how to handle customer-facing content, user access, and vendor review processes responsibly."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "shield-check"
+---
+
+Privacy questions usually come up during procurement, security review, or when teams start embedding product-specific information into their docs workflows.
+
+
+
+ Do not place secrets, raw credentials, or customer-specific private information in published
+ docs content. Treat the docs repository like a product surface that needs the same security
+ discipline as application code.
+
+
+ Restrict internal content using your authentication model, group membership, or separate sites if
+ the audience differs significantly.
+
+
+ Keep a short, stable internal checklist for privacy, data handling, subprocessors, and retention
+ so support and security teams can answer consistently.
+
+
+
+
+ A help center should be easy to browse, but that does not mean every page should be public. Keep
+ audience boundaries explicit.
+
diff --git a/peach/account-security/index.mdx b/peach/account-security/index.mdx
new file mode 100644
index 0000000..7cba2ba
--- /dev/null
+++ b/peach/account-security/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Account & Security"
+description: "Control who can access the workspace, what they can do, and how activity is audited."
+icon: "shield"
+---
+
+Security settings should support collaboration without making the content workflow brittle.
+
+
+ Start with sign-in and permissions. Audit logs and privacy workflows become much easier to reason
+ about once access boundaries are already clear.
+
diff --git a/peach/account-security/login-and-sso.mdx b/peach/account-security/login-and-sso.mdx
new file mode 100644
index 0000000..7be3c1c
--- /dev/null
+++ b/peach/account-security/login-and-sso.mdx
@@ -0,0 +1,35 @@
+---
+title: "Login & SSO"
+description: "Set up sign-in rules that are easy for employees to use and straightforward for admins to enforce."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "lock-keyhole"
+---
+
+Enterprise
+
+Single sign-on helps teams centralize access, enforce offboarding, and reduce ad hoc password management.
+
+
+
+ Confirm which identity provider will own the user lifecycle and what attributes must be passed
+ during sign-in.
+
+
+ Add the provider details in your security settings and verify the callback values before you
+ save the configuration.
+
+
+ Validate sign-in with a limited set of internal users before you enforce SSO for everyone.
+
+
+ Communicate the change to teammates, document the new login flow, and keep a fallback admin path
+ available until the rollout is stable.
+
+
+
+
+ If your team uses SCIM or automated user provisioning, make sure the expected roles and group
+ mappings are agreed on before you enable sign-in enforcement.
+
diff --git a/peach/account-security/roles-and-permissions.mdx b/peach/account-security/roles-and-permissions.mdx
new file mode 100644
index 0000000..aa4a162
--- /dev/null
+++ b/peach/account-security/roles-and-permissions.mdx
@@ -0,0 +1,30 @@
+---
+title: "Roles and permissions"
+description: "Give each teammate the level of access they need without expanding the blast radius of mistakes."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "users"
+---
+
+Use permissions to separate ownership, publishing authority, and review access.
+
+
+
+ Admins can manage workspace settings, integrations, authentication, billing, and content.
+ Reserve Admin for a small set of owners.
+
+
+ Editors are the primary content operators. They can write, review, and publish without needing
+ access to billing or sensitive security settings.
+
+
+ Viewers can inspect content and collaborate in lightweight ways without making production
+ changes.
+
+
+
+
+ Least-privilege access works best when roles are boring and predictable. Avoid one-off exceptions
+ whenever you can.
+
diff --git a/peach/billing/change-plan.mdx b/peach/billing/change-plan.mdx
new file mode 100644
index 0000000..41764e3
--- /dev/null
+++ b/peach/billing/change-plan.mdx
@@ -0,0 +1,42 @@
+---
+title: "Change Your Plan"
+description: "Upgrade, downgrade, or switch plans with a clear understanding of billing timing and access changes."
+author:
+ name: "Sofia Kim"
+createdDate: "2026-03-10"
+icon: "refresh-cw"
+---
+
+Billing
+
+Use plan changes when you need more seats, advanced collaboration, deeper security controls, or a different support model.
+
+
+
+ Check seats, traffic, integrations, and any advanced features your team is already using before
+ you switch plans.
+
+
+ Open **Settings > Billing** and confirm the plan includes the limits and features you need.
+
+
+ Upgrades usually take effect immediately, while downgrades may wait until the next billing
+ cycle. Review the confirmation screen before you submit the change.
+
+
+ If the change affects approvals, invoicing, or security features, tell your finance and IT
+ teams before the new plan goes live.
+
+
+
+## What changes after you switch
+
+- Billing totals may be prorated depending on your current cycle
+- Seat allowances and advanced features update to match the new plan
+- Existing content and URLs remain in place
+- Invoice format and payment collection timing may change for Enterprise contracts
+
+
+ Downgrading can affect seat limits or advanced features such as SSO. Audit your current setup
+ before you confirm the change.
+
diff --git a/peach/billing/index.mdx b/peach/billing/index.mdx
new file mode 100644
index 0000000..b1236b4
--- /dev/null
+++ b/peach/billing/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Billing & Plans"
+description: "Manage subscriptions, payment methods, invoices, and the billing contacts tied to your workspace."
+icon: "credit-card"
+---
+
+Use this section for everything related to renewals, payment collection, invoices, taxes, and plan changes.
+
+
+ If you need invoice-based billing or bank transfer support, check the **Payment Methods** section
+ first. It covers the Enterprise-only workflow and what information support needs from you.
+
diff --git a/peach/billing/invoices.mdx b/peach/billing/invoices.mdx
new file mode 100644
index 0000000..774a049
--- /dev/null
+++ b/peach/billing/invoices.mdx
@@ -0,0 +1,40 @@
+---
+title: "Invoices"
+description: "Download invoices, confirm tax details, and understand what to do when a payment fails."
+author:
+ name: "Sofia Kim"
+createdDate: "2026-03-10"
+icon: "receipt"
+---
+
+Invoices are available from your billing settings and provide the source of truth for charges, taxes, credits, and payment status.
+
+## Download invoice history
+
+Go to **Settings > Billing > Invoices** to view the full billing history for your workspace. Each
+invoice can be opened and downloaded as a PDF for internal record keeping.
+
+## Check tax and billing details
+
+Before forwarding an invoice to finance, confirm:
+
+- the billing entity name is correct
+- the tax ID or VAT information is current
+- the invoice address matches your finance system
+- the payment method listed is still active
+
+## If an invoice shows as unpaid
+
+
+
+ Update the card on file and retry collection from the billing page if that option is available.
+
+
+ Bank transfers and invoice-based payments can take longer to reconcile. Wait until the payment
+ clears before assuming the invoice is overdue.
+
+
+ Contact support with the invoice number and describe exactly what needs to change before your
+ finance team processes payment.
+
+
diff --git a/peach/billing/payment/add-card.mdx b/peach/billing/payment/add-card.mdx
new file mode 100644
index 0000000..f32b45c
--- /dev/null
+++ b/peach/billing/payment/add-card.mdx
@@ -0,0 +1,37 @@
+---
+title: "Add a Card"
+description: "Add or replace the credit card used for automatic billing on your workspace."
+author:
+ name: "Sofia Kim"
+createdDate: "2026-03-10"
+icon: "credit-card"
+---
+
+
+
+
+
+
+
+ Go to **Settings > Billing > Payment Methods**.
+
+
+ Select **Add card** or **Replace card** depending on whether you already have a payment method
+ on file.
+
+
+ Add the card number, expiration date, CVC, and the billing address associated with the card.
+
+
+ Save the payment method and verify it appears as the default card for future invoices and seat
+ changes.
+
+
+
+
+ If your finance team requires invoice-based billing instead of a card on file, use
+ [Bank transfer](/billing/payment/bank-transfer) instead.
+
diff --git a/peach/billing/payment/bank-transfer.mdx b/peach/billing/payment/bank-transfer.mdx
new file mode 100644
index 0000000..32a593a
--- /dev/null
+++ b/peach/billing/payment/bank-transfer.mdx
@@ -0,0 +1,45 @@
+---
+title: "Bank Transfer"
+description: "Set up ACH or wire transfers for invoice-based billing on eligible plans."
+author:
+ name: "Sofia Kim"
+createdDate: "2026-03-10"
+icon: "landmark"
+---
+
+Enterprise
+
+Bank transfer billing is a good fit when your finance team needs purchase-order workflows, invoice approvals, or payment collection outside of a card network.
+
+## How to get started
+
+
+
+ Make sure your contract supports invoice-based billing and bank transfer payments.
+
+
+ Contact [support@mintlify.com](mailto:support@mintlify.com) with your billing entity, billing
+ address, and any tax information your invoices require.
+
+
+ Mintlify will provide the invoice workflow and remittance instructions tied to your contract.
+
+
+ Use the invoice number in your remittance reference so the payment can be reconciled quickly.
+
+
+
+
+
+ If your company requires a PO, send it before your first invoice is issued so it can be added
+ to the billing workflow.
+
+
+ Yes. Some teams keep a backup card for smaller overages while using bank transfer for primary
+ subscription invoices.
+
+
+ If your finance team expects a delay, notify support and include the invoice number so the
+ workspace can be reviewed before renewal or suspension logic runs.
+
+
diff --git a/peach/billing/payment/billing-email.mdx b/peach/billing/payment/billing-email.mdx
new file mode 100644
index 0000000..347b950
--- /dev/null
+++ b/peach/billing/payment/billing-email.mdx
@@ -0,0 +1,22 @@
+---
+title: "Billing contact email"
+description: "Update the email address that receives invoices, renewal notices, and payment follow-up."
+author:
+ name: "Sofia Kim"
+createdDate: "2026-03-10"
+icon: "mail"
+---
+
+Keep your billing contact current so invoice reminders and renewal notices reach the right team.
+
+
+
+ Go to **Settings > Billing**.
+
+
+ Replace the old finance or operations email with the address your team actually monitors.
+
+
+ Make sure the new contact receives invoice copies, failed-payment notices, and renewal alerts.
+
+
diff --git a/peach/billing/payment/index.mdx b/peach/billing/payment/index.mdx
new file mode 100644
index 0000000..4ec7c7d
--- /dev/null
+++ b/peach/billing/payment/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Payment Methods"
+description: "Add a card, switch to invoice-based billing, or update the contact details used for billing communications."
+icon: "wallet"
+---
+
+Choose the payment setup that matches your team. Most workspaces use a card on file, while larger teams may move to invoice-based billing and bank transfer.
+
+
+ Keep your billing contact current even if you pay by card. That is where failed-payment and
+ renewal notifications are sent.
+
diff --git a/peach/changelog/deprecations.mdx b/peach/changelog/deprecations.mdx
new file mode 100644
index 0000000..9925390
--- /dev/null
+++ b/peach/changelog/deprecations.mdx
@@ -0,0 +1,28 @@
+---
+title: "Deprecations"
+description: "Track changes that require action before an older workflow, endpoint, or pattern is removed."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "triangle-alert"
+---
+
+
+ Deprecations are easiest to manage when you communicate the timeline, the replacement path, and
+ the exact action required from customers.
+
+
+
+
+ State when the deprecated behavior stops being recommended, when support ends, and when removal
+ is expected.
+
+
+ Link directly to the new workflow or setting so customers do not have to search for the answer
+ after learning something is changing.
+
+
+ Some deprecations affect only admins, while others affect all authors or all API consumers.
+ Make the audience explicit.
+
+
diff --git a/peach/changelog/index.mdx b/peach/changelog/index.mdx
new file mode 100644
index 0000000..d4626f4
--- /dev/null
+++ b/peach/changelog/index.mdx
@@ -0,0 +1,7 @@
+---
+title: "Changelog"
+description: "Review recent product improvements and keep track of upcoming or active deprecations."
+icon: "calendar"
+---
+
+Use the changelog to communicate product movement clearly without forcing users to infer what changed from docs updates alone.
diff --git a/peach/changelog/recent-updates.mdx b/peach/changelog/recent-updates.mdx
new file mode 100644
index 0000000..57f9662
--- /dev/null
+++ b/peach/changelog/recent-updates.mdx
@@ -0,0 +1,34 @@
+---
+title: "Recent updates"
+description: "A lightweight timeline of recent improvements across writing, review, and help-center workflows."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "sparkles"
+---
+
+
+ ## Category root pages now feel more intentional
+
+ Root pages now work better as browsable directories, making it easier to guide readers through a
+ sequence of categories before they reach a specific answer.
+
+ ### What changed
+ - clearer category entry points
+ - better support for nested groups
+ - more predictable page discovery in Help Center themes
+
+
+
+ ## Review and publishing flows are easier to follow
+
+ We tightened the content workflow so teams can preview changes more confidently before they go
+ live.
+
+
+
+ ## Teams have more control over access and account administration
+
+ Billing and security workflows are easier to reason about when ownership is distributed across a
+ larger team.
+
diff --git a/peach/docs.json b/peach/docs.json
new file mode 100644
index 0000000..754046a
--- /dev/null
+++ b/peach/docs.json
@@ -0,0 +1,158 @@
+{
+ "$schema": "https://mintlify.com/docs.json",
+ "theme": "peach",
+ "name": "Mintlify Help Center",
+ "colors": {
+ "primary": "#E85D3A",
+ "light": "#E85D3A",
+ "dark": "#E85D3A"
+ },
+ "icons": {
+ "library": "lucide"
+ },
+ "favicon": "/favicon.svg",
+ "navigation": {
+ "groups": [
+ {
+ "group": "Getting Started",
+ "icon": "rocket",
+ "root": "getting-started/index",
+ "pages": [
+ "getting-started/quick-setup",
+ "getting-started/first-project",
+ "getting-started/invite-team",
+ "getting-started/migrate-existing-docs",
+ "getting-started/understand-project-structure"
+ ]
+ },
+ {
+ "group": "Using the Product",
+ "icon": "blocks",
+ "root": "using-the-product/index",
+ "pages": [
+ "using-the-product/projects-and-environments",
+ "using-the-product/editor-basics",
+ "using-the-product/search-and-navigation",
+ {
+ "group": "Customization",
+ "icon": "palette",
+ "root": "using-the-product/customization/index",
+ "pages": [
+ "using-the-product/customization/branding",
+ "using-the-product/customization/navigation-structure",
+ "using-the-product/customization/custom-components"
+ ]
+ }
+ ]
+ },
+ {
+ "group": "Billing & Plans",
+ "icon": "credit-card",
+ "root": "billing/index",
+ "pages": [
+ "billing/change-plan",
+ "billing/invoices",
+ {
+ "group": "Payment Methods",
+ "icon": "wallet",
+ "root": "billing/payment/index",
+ "pages": [
+ "billing/payment/add-card",
+ "billing/payment/bank-transfer",
+ "billing/payment/billing-email"
+ ]
+ }
+ ]
+ },
+ {
+ "group": "Integrations & API",
+ "icon": "plug",
+ "root": "integrations/index",
+ "pages": [
+ "integrations/slack",
+ "integrations/github",
+ "integrations/vercel",
+ {
+ "group": "API basics",
+ "icon": "key-round",
+ "root": "integrations/api/index",
+ "pages": [
+ "integrations/api/api-tokens",
+ "integrations/api/webhooks",
+ "integrations/api/rate-limits"
+ ]
+ }
+ ]
+ },
+ {
+ "group": "Account & Security",
+ "icon": "shield",
+ "root": "account-security/index",
+ "pages": [
+ "account-security/login-and-sso",
+ "account-security/roles-and-permissions",
+ "account-security/audit-logs",
+ "account-security/data-privacy"
+ ]
+ },
+ {
+ "group": "Troubleshooting",
+ "icon": "wrench",
+ "root": "troubleshooting/index",
+ "pages": [
+ "troubleshooting/build-failures",
+ "troubleshooting/broken-links",
+ "troubleshooting/search-issues",
+ "troubleshooting/deployment-delays"
+ ]
+ },
+ {
+ "group": "Policies & Legal",
+ "icon": "scroll-text",
+ "root": "policies-legal/index",
+ "pages": [
+ "policies-legal/privacy",
+ "policies-legal/terms",
+ "policies-legal/subprocessors"
+ ]
+ },
+ {
+ "group": "Changelog",
+ "icon": "calendar",
+ "root": "changelog/index",
+ "pages": [
+ "changelog/recent-updates",
+ "changelog/deprecations"
+ ]
+ }
+ ]
+ },
+ "logo": {
+ "light": "/logo/light.svg",
+ "dark": "/logo/dark.svg"
+ },
+ "navbar": {
+ "links": [
+ {
+ "label": "Contact support",
+ "href": "mailto:support@mintlify.com"
+ },
+ {
+ "label": "Status",
+ "href": "https://mintlify.com/docs/status"
+ }
+ ],
+ "primary": {
+ "type": "button",
+ "label": "Dashboard",
+ "href": "https://dashboard.mintlify.com"
+ }
+ },
+ "footer": {
+ "socials": {
+ "x": "https://x.com/mintlify",
+ "github": "https://github.com/mintlify",
+ "linkedin": "https://linkedin.com/company/mintlify"
+ }
+ }
+}
diff --git a/peach/favicon.svg b/peach/favicon.svg
new file mode 100644
index 0000000..ff1a915
--- /dev/null
+++ b/peach/favicon.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/peach/getting-started/first-project.mdx b/peach/getting-started/first-project.mdx
new file mode 100644
index 0000000..54957c5
--- /dev/null
+++ b/peach/getting-started/first-project.mdx
@@ -0,0 +1,48 @@
+---
+title: "Create your first site"
+description: "Publish a complete documentation or help-center site from your first repository and content tree."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "file"
+---
+
+
+ Keep your first launch small. A clear homepage, a few category pages, and a short set of core
+ articles are enough to go live confidently.
+
+
+
+
+ In the dashboard, create a new project and connect the repository or folder that contains your
+ docs.
+
+
+ Update `docs.json` with your site name, logo, favicon, colors, and navigation structure. This
+ is the foundation that powers both your homepage and your category hierarchy.
+
+
+ Create a homepage that directs users into your most important sections. Then add category root
+ pages for the areas you expect users to browse most often.
+
+
+ Focus on a small set of high-value pages such as setup, billing, permissions, and
+ troubleshooting. Those pages usually answer the majority of early support questions.
+
+
+ Use local preview or a branch preview deployment to confirm search behavior, page order, links,
+ and styling.
+
+
+ Publish when the core paths are working and your navigation is easy to scan. You can continue
+ expanding the site after launch without restructuring everything later.
+
+
+
+## Launch checklist
+
+- Homepage points to your highest-traffic categories
+- Every navigation group has a clear root page
+- Key support articles are searchable and internally linked
+- Billing, security, and troubleshooting pages are easy to find
+- Contact or escalation guidance exists somewhere on the site
diff --git a/peach/getting-started/index.mdx b/peach/getting-started/index.mdx
new file mode 100644
index 0000000..a11f184
--- /dev/null
+++ b/peach/getting-started/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Getting Started"
+description: "Set up your first site, invite collaborators, migrate existing docs, and understand how your content is organized."
+icon: "rocket"
+---
+
+If you are new to Mintlify, start here. This section covers the fastest path from a repository full of content to a live, searchable help center.
+
+
+ Start with **Quick setup** if you already have content in GitHub or GitLab. If you are migrating
+ from another docs platform, jump to **Migrate existing docs** first.
+
diff --git a/peach/getting-started/invite-team.mdx b/peach/getting-started/invite-team.mdx
new file mode 100644
index 0000000..1dc7f64
--- /dev/null
+++ b/peach/getting-started/invite-team.mdx
@@ -0,0 +1,51 @@
+---
+title: "Invite Your Team"
+description: "Bring teammates into your docs workflow and assign the right level of access from the start."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "users"
+---
+
+The best docs workflows are collaborative. Invite technical writers, engineers, support teammates,
+and reviewers early so feedback happens before content reaches production.
+
+## Assign the right role
+
+
+
+ Use Admin for owners who need to manage billing, authentication, integrations, and workspace
+ settings in addition to content.
+
+
+ Editors can create, review, and publish content. This is the right default for most day-to-day
+ contributors.
+
+
+ Viewers can review work and access the project without making publishing changes.
+
+
+
+## Invite teammates
+
+
+
+ In the dashboard, go to **Settings > Team**.
+
+
+ Enter one or more email addresses and choose the appropriate role for each person.
+
+
+ Decide whether content changes should go through branch previews, editor suggestions, or direct
+ updates to the default branch.
+
+
+ Ask new teammates to sign in, open the project, and verify they can view the correct pages and
+ settings.
+
+
+
+
+ If you use SSO, finish [Login & SSO](/account-security/login-and-sso) before you invite a large
+ group. That way, access rules are already enforced when teammates join.
+
diff --git a/peach/getting-started/migrate-existing-docs.mdx b/peach/getting-started/migrate-existing-docs.mdx
new file mode 100644
index 0000000..f146068
--- /dev/null
+++ b/peach/getting-started/migrate-existing-docs.mdx
@@ -0,0 +1,54 @@
+---
+title: "Migrate existing docs"
+description: "Move content from another docs platform into Mintlify without losing structure, searchability, or key URLs."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "arrow-right-left"
+---
+
+
+ Preserve your existing URLs where possible. If paths need to change, plan redirects before you
+ publish the migrated site.
+
+
+
+
+ Identify the pages, groups, assets, and redirects you need to carry over. This is the best time
+ to remove outdated pages and merge duplicate content.
+
+
+ Organize content into directories that reflect the categories you want users to browse. Create
+ root pages for each category so the structure reads cleanly in both the sidebar and category
+ views.
+
+
+ Rebuild the navigation tree so your groups, subgroups, and article order match the experience
+ you want in Mintlify.
+
+
+ Run a local preview or a branch preview. Click through the site as if you were a new customer
+ and look for missing assets, broken links, or category pages that feel sparse.
+
+
+ After launch, watch incoming support requests and search queries to catch any gaps in the
+ migration quickly.
+
+
+
+## Source-specific notes
+
+
+
+ Pay extra attention to docs versions, autogenerated sidebars, and plugin-specific pages. Those
+ concepts often need to be mapped into explicit `docs.json` navigation.
+
+
+ GitBook content usually maps well to MDX, but navigation and cards often need to be rebuilt
+ manually so the homepage feels intentional.
+
+
+ Audit every custom component before launch. If a component is not available in Mintlify, decide
+ whether to rebuild it, simplify the page, or convert it to a built-in pattern.
+
+
diff --git a/peach/getting-started/quick-setup.mdx b/peach/getting-started/quick-setup.mdx
new file mode 100644
index 0000000..52c08c9
--- /dev/null
+++ b/peach/getting-started/quick-setup.mdx
@@ -0,0 +1,78 @@
+---
+title: "Quick Setup"
+description: "Launch a new Mintlify site from GitHub, GitLab, or a local folder in a few guided steps."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "rocket"
+---
+
+
+ Quick setup is the fastest path when you already have a repository or a folder of Markdown and
+ MDX files ready to organize.
+
+
+
+
+
+
+ In the dashboard, create a new project and choose **Import from GitHub**.
+
+
+ Select the repository that will store your docs. Mintlify reads the content, builds preview
+ deployments, and opens pull requests from the editor when needed.
+
+
+ Point Mintlify at the folder that contains your `docs.json` and content files. If you are
+ starting from scratch, choose the starter layout and customize it after import.
+
+
+ Open the site preview and confirm that the homepage, categories, and article order match the
+ structure you expect.
+
+
+
+
+
+
+ Start a new project and choose **Import from GitLab**.
+
+
+ Make sure the account you connect can read the branch that stores your content.
+
+
+ Use your default branch for production and let Mintlify create previews for merge requests.
+
+
+ Check page titles, descriptions, and any nested groups before publishing.
+
+
+
+
+
+
+ ```bash
+ npm install -g mint
+ ```
+
+
+ Move into the folder that contains `docs.json` and your MDX files.
+
+
+ ```bash
+ mint dev
+ ```
+
+
+ Use local preview to test navigation, search behavior, and page formatting before you wire
+ the site into your production workflow.
+
+
+
+
+
+## What to do next
+
+- Continue to [Create your first site](/getting-started/first-project) to publish a production-ready structure.
+- Read [Understand the project structure](/getting-started/understand-project-structure) if you want to know how `docs.json`, folders, and category pages work together.
+- If you are moving from another platform, use [Migrate existing docs](/getting-started/migrate-existing-docs) before you finalize redirects.
diff --git a/peach/getting-started/understand-project-structure.mdx b/peach/getting-started/understand-project-structure.mdx
new file mode 100644
index 0000000..5a3ce2e
--- /dev/null
+++ b/peach/getting-started/understand-project-structure.mdx
@@ -0,0 +1,45 @@
+---
+title: "Understand the project structure"
+description: "See how docs.json, category folders, assets, and article pages fit together in a typical Mintlify site."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "folder-tree"
+---
+
+Mintlify sites are easiest to maintain when your folders mirror the way users browse the site.
+
+The most important file is `docs.json`. It tells Mintlify how pages should be grouped and which category roots are visitable.
+
+## Example structure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## How the pieces fit together
+
+- `index.mdx` at the site root becomes the homepage
+- category folders usually include their own `index.mdx` root pages
+- article files live alongside the category they belong to
+- assets such as logos and screenshots live in shared folders like `/logo` or `/images`
+
+
+ In Help Center themes, category root pages are especially important because they act as visitable
+ directories. Even if the page body is short, the page can still present the child articles and
+ nested categories automatically.
+
diff --git a/peach/images/billing-settings.svg b/peach/images/billing-settings.svg
new file mode 100644
index 0000000..f0a21be
--- /dev/null
+++ b/peach/images/billing-settings.svg
@@ -0,0 +1,18 @@
+
diff --git a/peach/images/branding-settings.svg b/peach/images/branding-settings.svg
new file mode 100644
index 0000000..ce0e377
--- /dev/null
+++ b/peach/images/branding-settings.svg
@@ -0,0 +1,20 @@
+
diff --git a/peach/images/editor-overview.svg b/peach/images/editor-overview.svg
new file mode 100644
index 0000000..c8c2a6c
--- /dev/null
+++ b/peach/images/editor-overview.svg
@@ -0,0 +1,23 @@
+
diff --git a/peach/index.mdx b/peach/index.mdx
new file mode 100644
index 0000000..6fe2b71
--- /dev/null
+++ b/peach/index.mdx
@@ -0,0 +1,5 @@
+---
+title: "How can we help?"
+description: "Browse setup guides, publishing workflows, billing help, troubleshooting steps, and product updates for Mintlify."
+sidebarTitle: "Home"
+---
diff --git a/peach/integrations/api/api-tokens.mdx b/peach/integrations/api/api-tokens.mdx
new file mode 100644
index 0000000..f77957a
--- /dev/null
+++ b/peach/integrations/api/api-tokens.mdx
@@ -0,0 +1,30 @@
+---
+title: "API tokens"
+description: "Create and manage tokens safely for integrations, automation, and internal tooling."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "key-round"
+---
+
+API tokens let external systems authenticate without using a full interactive sign-in flow.
+
+
+ Treat tokens like passwords. Store them in a secrets manager, avoid committing them to Git, and
+ rotate them when a team member or integration no longer needs access.
+
+
+
+
+ Use the dashboard when you want to generate a token manually, confirm who created it, and rotate
+ it later from a single place.
+
+
+ Use a token in CI, internal scripts, or service-to-service workflows where a human sign-in is
+ not practical.
+
+
+ Review token ownership, scope, and last-known usage regularly so stale credentials do not remain
+ active indefinitely.
+
+
diff --git a/peach/integrations/api/index.mdx b/peach/integrations/api/index.mdx
new file mode 100644
index 0000000..249b716
--- /dev/null
+++ b/peach/integrations/api/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "API basics"
+description: "Use tokens, webhooks, and operational limits to connect Mintlify to the rest of your support and content workflow."
+icon: "key-round"
+---
+
+The API-oriented workflows in this section help you automate content operations, react to events, and integrate Mintlify with internal tooling.
+
+
+ Start with token management first. Once authentication is in place, add webhooks and other
+ automations one at a time.
+
diff --git a/peach/integrations/api/rate-limits.mdx b/peach/integrations/api/rate-limits.mdx
new file mode 100644
index 0000000..8810731
--- /dev/null
+++ b/peach/integrations/api/rate-limits.mdx
@@ -0,0 +1,21 @@
+---
+title: "Rate limits"
+description: "Design automation workflows that stay reliable even when request throughput is constrained."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "gauge"
+---
+
+Rate limits protect the platform and keep one noisy integration from affecting everyone else.
+
+## Good practices
+
+- batch work when possible instead of making one request per small change
+- retry with backoff instead of immediately retrying failures
+- log request volume so you can see when your automation patterns change
+
+
+ If an integration starts hitting limits unexpectedly, inspect whether the workflow is polling too
+ frequently or re-running the same requests after soft failures.
+
diff --git a/peach/integrations/api/webhooks.mdx b/peach/integrations/api/webhooks.mdx
new file mode 100644
index 0000000..2347ac3
--- /dev/null
+++ b/peach/integrations/api/webhooks.mdx
@@ -0,0 +1,35 @@
+---
+title: "Webhooks"
+description: "Receive change events from Mintlify and hand them off to internal automation or support tooling."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "webhook"
+---
+
+Webhooks are useful when another system needs to react to publishing events, feedback submissions, or operational changes without polling constantly.
+
+## What a webhook event usually includes
+
+```json
+{
+ "event": "page.published",
+ "site": "mintlify-help-center",
+ "path": "/getting-started/quick-setup",
+ "timestamp": "2026-03-10T18:42:00Z"
+}
+```
+
+
+
+ Validate the webhook signature and reject requests that do not match the signing secret stored
+ in your environment.
+
+
+ Capture the delivery in your logs and make sure your endpoint can handle retries idempotently.
+
+
+ Start with notifications, internal dashboards, or analytics workflows before moving into
+ production-critical automations.
+
+
diff --git a/peach/integrations/github.mdx b/peach/integrations/github.mdx
new file mode 100644
index 0000000..5eef24f
--- /dev/null
+++ b/peach/integrations/github.mdx
@@ -0,0 +1,38 @@
+---
+title: "GitHub Integration"
+description: "Connect your content repository to Mintlify for previews, publishing, and collaborative review workflows."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "github"
+---
+
+GitHub is the most common source of truth for Mintlify sites. Once connected, it becomes the backbone for previews, edits, and controlled publishing.
+
+
+
+ Open **Settings > Integrations > GitHub** and choose the repository that contains your docs.
+
+
+ Confirm the branch and content root are pointing at the folder that contains `docs.json` and
+ your MDX pages.
+
+
+ Edit a page or open a pull request to confirm Mintlify creates a preview deployment and reflects
+ the update correctly.
+
+
+ Decide whether your team will publish directly from the editor, merge content via pull requests,
+ or use both depending on the type of change.
+
+
+
+## Branch previews
+
+Each pull request can generate a preview deployment so you can review navigation, formatting, and
+search behavior before you merge.
+
+
+ If previews are not updating, check branch permissions, repository visibility, and any required
+ checks blocking the connected workflow.
+
diff --git a/peach/integrations/index.mdx b/peach/integrations/index.mdx
new file mode 100644
index 0000000..0ab0666
--- /dev/null
+++ b/peach/integrations/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Integrations"
+description: "Connect repositories, notifications, deployment targets, and API workflows to your docs site."
+icon: "plug"
+---
+
+Integrations help your documentation stay connected to the systems your team already uses to write, review, deploy, and support content.
+
+
+ Start with your source-control integration first. Once previews and publishing are stable, layer
+ in notifications and API-based automations.
+
diff --git a/peach/integrations/slack.mdx b/peach/integrations/slack.mdx
new file mode 100644
index 0000000..aa19bfa
--- /dev/null
+++ b/peach/integrations/slack.mdx
@@ -0,0 +1,39 @@
+---
+title: "Slack Integration"
+description: "Route publishing, feedback, and workflow alerts into the Slack channels your team already monitors."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "message-square"
+---
+
+Slack works best when you separate high-signal publishing alerts from general team chatter. Start with one channel for launches and one channel for content review or support handoff.
+
+
+
+ Go to **Settings > Integrations > Slack**.
+
+
+ Connect the Slack workspace that should receive Mintlify notifications.
+
+
+ Send publishing alerts to one channel and route editorial or support notifications to a second
+ channel if your team prefers clearer separation.
+
+
+ Trigger a small content update or preview deployment to confirm Slack is receiving the right
+ messages.
+
+
+
+## Good notifications to start with
+
+- New article notifications
+- Feedback alerts or support handoff notifications
+- Preview deployment creation
+- Weekly digest or usage summaries
+
+
+ Keep notification volume low at the start. Too many channels or message types make it harder for
+ people to trust the alerts that matter.
+
diff --git a/peach/integrations/vercel.mdx b/peach/integrations/vercel.mdx
new file mode 100644
index 0000000..6c62be8
--- /dev/null
+++ b/peach/integrations/vercel.mdx
@@ -0,0 +1,30 @@
+---
+title: "Vercel"
+description: "Connect deployment workflows and preview checks so site updates are reviewed before they reach production."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "globe"
+---
+
+Vercel is a common deployment layer for teams that want preview environments, routing control, or a custom docs subpath in front of Mintlify.
+
+
+
+ Decide whether Mintlify should be the primary site host or whether Vercel will sit in front of
+ the site for routing and proxy behavior.
+
+
+ Make sure preview deployments are easy for writers, engineers, and reviewers to open from pull
+ requests.
+
+
+ Test custom domains, docs subpaths, and any authentication layers before you push the setup to
+ production.
+
+
+
+
+ Treat deployment configuration as part of the docs experience. If routing, headers, or previews
+ are unreliable, users will feel the instability even when the content itself is strong.
+
diff --git a/peach/logo/dark.svg b/peach/logo/dark.svg
new file mode 100644
index 0000000..d8c18e6
--- /dev/null
+++ b/peach/logo/dark.svg
@@ -0,0 +1,21 @@
+
+
\ No newline at end of file
diff --git a/peach/logo/light.svg b/peach/logo/light.svg
new file mode 100644
index 0000000..7801468
--- /dev/null
+++ b/peach/logo/light.svg
@@ -0,0 +1,21 @@
+
+
\ No newline at end of file
diff --git a/peach/policies-legal/index.mdx b/peach/policies-legal/index.mdx
new file mode 100644
index 0000000..27e03d4
--- /dev/null
+++ b/peach/policies-legal/index.mdx
@@ -0,0 +1,7 @@
+---
+title: "Policies & Legal"
+description: "Keep a small set of public-facing legal and privacy references easy to find from the help center."
+icon: "scroll-text"
+---
+
+This section is for stable reference pages customers and procurement teams may need when reviewing your product.
diff --git a/peach/policies-legal/privacy.mdx b/peach/policies-legal/privacy.mdx
new file mode 100644
index 0000000..f6e5f86
--- /dev/null
+++ b/peach/policies-legal/privacy.mdx
@@ -0,0 +1,15 @@
+---
+title: "Privacy"
+description: "Answer common privacy questions and point customers to the official policy when they need legal wording."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "shield"
+---
+
+Use this page to summarize your privacy posture in plain language and link to the authoritative legal policy when a customer needs formal wording.
+
+
+ Keep the legal policy itself in one canonical location. This page should make it easier to find,
+ not create a second competing source of truth.
+
diff --git a/peach/policies-legal/subprocessors.mdx b/peach/policies-legal/subprocessors.mdx
new file mode 100644
index 0000000..f0ef51a
--- /dev/null
+++ b/peach/policies-legal/subprocessors.mdx
@@ -0,0 +1,17 @@
+---
+title: "Subprocessors"
+description: "Provide a stable place for customers to review third-party vendors involved in delivering the service."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "database"
+---
+
+Subprocessor disclosures are often requested during vendor review. Keep this page current and easy to share.
+
+## What to include
+
+- vendor name
+- category of service
+- high-level purpose
+- link to the vendor's privacy or security materials when appropriate
diff --git a/peach/policies-legal/terms.mdx b/peach/policies-legal/terms.mdx
new file mode 100644
index 0000000..dc5fcf2
--- /dev/null
+++ b/peach/policies-legal/terms.mdx
@@ -0,0 +1,14 @@
+---
+title: "Terms"
+description: "Direct customers to the current terms of service and explain when to use that reference during procurement."
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+icon: "file-text"
+---
+
+Your terms page should be easy to find during security review, procurement, and renewal conversations.
+
+- link to the current terms of service
+- explain which entity the terms apply to
+- note where enterprise customers can expect contract-specific language instead
diff --git a/peach/troubleshooting/broken-links.mdx b/peach/troubleshooting/broken-links.mdx
new file mode 100644
index 0000000..547cafb
--- /dev/null
+++ b/peach/troubleshooting/broken-links.mdx
@@ -0,0 +1,34 @@
+---
+title: "Broken links"
+description: "Find and fix links that stopped working after a content move, rename, or migration."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "link-2-off"
+---
+
+Broken links usually appear after a page has been renamed, moved to a new category, or removed without redirect planning.
+
+
+
+ Open the exact URL that fails and note whether the target page moved, changed names, or no
+ longer exists.
+
+
+ Look through nearby pages, homepage cards, and category root content to find where the old link
+ is still referenced.
+
+
+ If the page still exists under a new path, update the link and consider adding a redirect if the
+ old path may still be shared externally.
+
+
+ Verify the updated link from the page, the navigation, and any homepage cards or category
+ directories that point to it.
+
+
+
+
+ Migrations and information-architecture cleanups are the most common source of broken links. Plan
+ redirect coverage before publishing large moves.
+
diff --git a/peach/troubleshooting/build-failures.mdx b/peach/troubleshooting/build-failures.mdx
new file mode 100644
index 0000000..8ec843c
--- /dev/null
+++ b/peach/troubleshooting/build-failures.mdx
@@ -0,0 +1,34 @@
+---
+title: "Build failures"
+description: "Work through the most common reasons a docs build fails before a change reaches production."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "bug"
+---
+
+Build failures usually come down to invalid configuration, broken content references, or syntax errors in MDX.
+
+
+
+ Confirm the JSON is valid and every navigation group has the fields required by the current
+ theme, especially `root` for Help Center groups.
+
+
+ If `docs.json` points at a page that does not exist, the build can fail or the navigation can
+ resolve incorrectly. Double-check file names and folder paths.
+
+
+ Unclosed tags, malformed frontmatter, or unsupported JSX patterns can prevent pages from
+ compiling. Start with the newest edited page.
+
+
+ Missing local images, imported snippets, or components can also break the build. Make sure every
+ referenced asset exists at the expected path.
+
+
+
+
+ Fix one problem at a time. Re-running the build after a focused change is faster than making many
+ speculative edits at once.
+
diff --git a/peach/troubleshooting/deployment-delays.mdx b/peach/troubleshooting/deployment-delays.mdx
new file mode 100644
index 0000000..bceaab4
--- /dev/null
+++ b/peach/troubleshooting/deployment-delays.mdx
@@ -0,0 +1,29 @@
+---
+title: "Deployment delays"
+description: "Understand what to check when content changes or preview deployments take longer than expected."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "clock-3"
+---
+
+Most deployment delays come from queue time, upstream repository events, or a build that is retrying after failure.
+
+
+
+ Confirm the repository event, editor publish action, or manual deployment action was recorded.
+
+
+ If a build is still queued, wait for capacity to clear. If it failed, fix the root issue before
+ you retry.
+
+
+ A preview delay and a production delay do not always share the same cause. Check both before you
+ assume the issue is global.
+
+
+
+
+ When you contact support, include the repository, branch, and approximate time of the expected
+ deployment. That makes it much easier to trace the event.
+
diff --git a/peach/troubleshooting/index.mdx b/peach/troubleshooting/index.mdx
new file mode 100644
index 0000000..3054dde
--- /dev/null
+++ b/peach/troubleshooting/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Troubleshooting"
+description: "Resolve the most common publishing, navigation, search, and deployment issues without guessing."
+icon: "wrench"
+---
+
+Troubleshooting is easier when you reduce the problem to one layer at a time: content, navigation, build, search, or deployment.
+
+
+ Start with the article that matches the symptom you can observe clearly. Avoid changing multiple
+ moving parts at once until you know where the failure actually lives.
+
diff --git a/peach/troubleshooting/search-issues.mdx b/peach/troubleshooting/search-issues.mdx
new file mode 100644
index 0000000..225d385
--- /dev/null
+++ b/peach/troubleshooting/search-issues.mdx
@@ -0,0 +1,25 @@
+---
+title: "Search issues"
+description: "Troubleshoot stale titles, missing pages, and confusing search results after content changes."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "search"
+---
+
+Search problems are frustrating because they often show up after the content itself already looks correct on the page.
+
+
+
+ Confirm the page is published, referenced in navigation if needed, and not intentionally hidden.
+ New or renamed pages may also need time for search indexing to refresh.
+
+
+ Make sure the updated frontmatter is actually deployed. If it is, wait for the search index to
+ catch up before assuming the metadata change was ignored.
+
+
+ Improve the page title, category placement, and the terms used in the description or body copy.
+ Search quality often improves when the article is named closer to the language users type.
+
+
diff --git a/peach/using-the-product/customization/branding.mdx b/peach/using-the-product/customization/branding.mdx
new file mode 100644
index 0000000..7c68523
--- /dev/null
+++ b/peach/using-the-product/customization/branding.mdx
@@ -0,0 +1,35 @@
+---
+title: "Branding"
+description: "Update colors, logos, favicon, and supporting metadata so the help center feels native to your product."
+icon: "palette"
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+---
+
+
+
+
+
+## Recommended order
+
+
+
+ Start with your primary, light, and dark theme colors in `docs.json`.
+
+
+ Add both light and dark logo variants if your brand requires different contrast treatment.
+
+
+ Make sure the site name, descriptions, and any per-page imagery match the product voice and
+ support motion of the site.
+
+
+
+
+ Small branding details add up quickly. Even a lightweight help center feels more trustworthy when
+ the name, colors, and favicon all match the product a customer just came from.
+
diff --git a/peach/using-the-product/customization/custom-components.mdx b/peach/using-the-product/customization/custom-components.mdx
new file mode 100644
index 0000000..9f3b7ea
--- /dev/null
+++ b/peach/using-the-product/customization/custom-components.mdx
@@ -0,0 +1,34 @@
+---
+title: "Custom components"
+description: "Decide when a built-in Mintlify component is enough and when a custom React component is worth the maintenance cost."
+icon: "puzzle"
+author:
+ name: "Maya Patel"
+createdDate: "2026-03-10"
+---
+
+Most support articles can be built with Mintlify-native MDX components. Reach for a custom component only when the built-in patterns cannot express the experience you need.
+
+
+
+ Start with built-in components such as `Steps`, `Accordion`, `Callout`, `Card`, and `Tabs`.
+ They are easier to maintain, easier for teammates to reuse, and already match the surrounding
+ site styles.
+
+
+ Use a custom component when you need deeply product-specific UI, dynamic rendering, or a richer
+ interaction than MDX alone can provide.
+
+
+
+
+ Every custom component adds maintenance cost. Confirm that the design pattern is stable before you
+ turn it into a reusable building block.
+
+
+## Good candidates for a custom component
+
+- reusable onboarding checklists
+- product-specific comparison tables
+- custom embeds that need live data or authenticated state
+- branded content modules used across many articles
diff --git a/peach/using-the-product/customization/index.mdx b/peach/using-the-product/customization/index.mdx
new file mode 100644
index 0000000..53d8c5b
--- /dev/null
+++ b/peach/using-the-product/customization/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Customization"
+description: "Adjust branding, navigation, and custom components so the site matches the product and audience it supports."
+icon: "palette"
+---
+
+Use customization settings to make the site feel like a natural extension of your product instead of a disconnected documentation surface.
+
+
+ Start with branding and navigation first. Those changes improve the user experience immediately
+ and usually require less maintenance than heavier custom component work.
+
diff --git a/peach/using-the-product/customization/navigation-structure.mdx b/peach/using-the-product/customization/navigation-structure.mdx
new file mode 100644
index 0000000..97b60f9
--- /dev/null
+++ b/peach/using-the-product/customization/navigation-structure.mdx
@@ -0,0 +1,47 @@
+---
+title: "Navigation structure"
+description: "Design a category tree that matches how users search for answers instead of how your team names internal workstreams."
+icon: "waypoints"
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+---
+
+Navigation should feel obvious to the person asking the question, not just to the team maintaining the docs.
+
+## A simple help-center pattern
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Use the main questions customers ask, such as setup, billing, security, or troubleshooting.
+
+
+ A nested group is useful when a category has a distinct sub-area, such as payment methods under
+ billing.
+
+
+ Root pages act as visitable category directories in Help Center themes, so keep them concise and
+ useful.
+
+
+
+
+ Avoid deep nesting unless users truly need it. Two clear levels are usually easier to browse than
+ a long stack of narrowly named subcategories.
+
diff --git a/peach/using-the-product/editor-basics.mdx b/peach/using-the-product/editor-basics.mdx
new file mode 100644
index 0000000..70e1861
--- /dev/null
+++ b/peach/using-the-product/editor-basics.mdx
@@ -0,0 +1,42 @@
+---
+title: "Editor basics"
+description: "Learn the everyday editing workflow for pages, media, comments, previews, and publishing."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "pen"
+---
+
+
+
+
+
+## The core workflow
+
+1. Open a page from the navigation
+2. Edit content or frontmatter
+3. Preview the change
+4. Request review or publish
+
+## What to learn first
+
+
+
+ Create new pages, move them into the right folders, and keep the `docs.json` structure aligned
+ with how users should browse the site.
+
+
+ Add images, videos, and reusable content without breaking page performance or layout.
+
+
+ Use comments for feedback and suggestions for line-level edits when multiple people are shaping
+ the same article.
+
+
+ Preview first whenever you touch structure, reusable components, or page metadata. Publish only
+ after the page reads cleanly on desktop and mobile.
+
+
diff --git a/peach/using-the-product/index.mdx b/peach/using-the-product/index.mdx
new file mode 100644
index 0000000..8e20f70
--- /dev/null
+++ b/peach/using-the-product/index.mdx
@@ -0,0 +1,12 @@
+---
+title: "Using the Product"
+description: "Learn the core publishing workflow, editor basics, search behavior, and customization options that shape your site."
+icon: "blocks"
+---
+
+This section covers the day-to-day work of running a docs site after the initial setup is complete.
+
+
+ Start with **Projects and environments** if you want a high-level mental model. Jump straight to
+ **Editor basics** if your team is already writing content and wants to move faster.
+
diff --git a/peach/using-the-product/projects-and-environments.mdx b/peach/using-the-product/projects-and-environments.mdx
new file mode 100644
index 0000000..b68112a
--- /dev/null
+++ b/peach/using-the-product/projects-and-environments.mdx
@@ -0,0 +1,36 @@
+---
+title: "Projects and environments"
+description: "Understand the difference between local preview, branch previews, and production publishing."
+author:
+ name: "Jordan Lee"
+createdDate: "2026-03-10"
+icon: "folders"
+---
+
+Most teams work in three environments: local preview for fast iteration, branch previews for review, and production for live documentation.
+
+
+
+ Use local preview when you are still shaping content, navigation, or component usage. It is the
+ fastest feedback loop and the safest place to test large restructuring changes.
+
+
+ Use preview deployments for peer review. They are ideal for checking search behavior, layout
+ changes, redirects, and pages that depend on real repository workflows.
+
+
+ Production is the source your users see. Keep it stable, searchable, and easy to navigate.
+ Publish to production only after the content and navigation have been reviewed in a preview.
+
+
+
+## Good defaults for small teams
+
+- Use local preview while writing
+- Use pull requests or branch previews for review
+- Publish to production from the default branch
+
+
+ If your team is small, keep the workflow simple first. You can always add more approvals,
+ environments, and automation later.
+
diff --git a/peach/using-the-product/search-and-navigation.mdx b/peach/using-the-product/search-and-navigation.mdx
new file mode 100644
index 0000000..178aaec
--- /dev/null
+++ b/peach/using-the-product/search-and-navigation.mdx
@@ -0,0 +1,37 @@
+---
+title: "Search and navigation"
+description: "Keep articles discoverable by organizing categories clearly and understanding how search responds to changes."
+author:
+ name: "Avery Chen"
+createdDate: "2026-03-10"
+icon: "search"
+---
+
+Good search starts with good information architecture. Clear page titles, category roots, and descriptive summaries make both browsing and search more effective.
+
+## Make pages easier to discover
+
+- Use specific page titles instead of broad labels like `Overview`
+- Add short, useful descriptions to important pages
+- Group related articles under category roots that users already understand
+- Cross-link articles that answer adjacent questions
+
+
+
+ The file may exist, but it will not appear until it is referenced in `docs.json` and placed in
+ the correct group or subgroup.
+
+
+ Search results may take time to refresh after you rename or move a page. Confirm the latest
+ version is published before you assume indexing is stuck.
+
+
+ Hide pages only when you intentionally want them excluded from navigation. Avoid using hidden
+ pages as a substitute for a cleaner information architecture.
+
+
+
+
+ If users repeatedly search for the same term and still fail to find the right article, that is a
+ signal to rename the page, add aliases in the copy, or move it into a clearer category.
+
+
+
+
+
+
+## Recommended order
+
+
+
+
+## The core workflow
+
+1. Open a page from the navigation
+2. Edit content or frontmatter
+3. Preview the change
+4. Request review or publish
+
+## What to learn first
+
+