diff --git a/client/pages/docs/DocsEditorsGuide.tsx b/client/pages/docs/DocsEditorsGuide.tsx
new file mode 100644
index 00000000..8ec44573
--- /dev/null
+++ b/client/pages/docs/DocsEditorsGuide.tsx
@@ -0,0 +1,89 @@
+import { Link } from "react-router-dom";
+import { Card, CardContent, CardHeader, CardTitle, CardDescription } from "@/components/ui/card";
+import { Badge } from "@/components/ui/badge";
+import { Button } from "@/components/ui/button";
+import { GitBranch, ExternalLink, CheckCircle2 } from "lucide-react";
+
+export default function DocsEditorsGuide() {
+ return (
+
+
+ Docs Editing
+ Editing Public Docs (Builder → GitHub PR workflow)
+ This guide explains how staff can edit public documentation using Builder CMS and publish changes through a GitHub pull request. Internal operational docs must remain under /internal-docs and are not editable from the public docs workflow.
+
+
+
+
+
+ Edit in Builder
+ Use the Builder (MCP) editor for content changes, layout tweaks, and page composition.
+
+
+
+ - Open the app and click Open MCP popover (#open-mcp-popover).
+ - Select Builder.io and edit the desired public doc entry (e.g. Getting Started, Platform).
+ - Use the preview mode to validate across themes (Brand / Professional).
+ - Save drafts and request review from the Docs team (assign reviewer in Builder).
+
+
+
+
+
+
+ Export & Publish (GitHub PR)
+ After Builder review, export or commit changes to the docs repo and open a GitHub PR.
+
+
+
+ - From Builder, use the export feature to get Markdown/JSX content, or copy the updated component code.
+ - Create a branch in the repository named
docs/{`your-change`} and add the changes under code/client/pages/docs or code/docs.
+ - Open a GitHub Pull Request describing the change, link the Builder draft, and assign the Docs reviewer team.
+ - CI will run lint & build checks. After approval, merge to main and the docs will be deployed automatically.
+
+
+
+
+
+
+
+
+ Public docs policy & safety checks
+ Ensure no internal APIs or sensitive operational details are exposed publicly.
+
+
+
+ - Do not include internal admin endpoints, service role keys, or SQL migrations in public docs.
+ - When in doubt, link to an internal doc (under
/internal-docs) instead of copying operational procedures to public docs.
+ - For partner-facing API documentation, create a gated partner docs area (contact the Docs lead).
+ - Security checklist: remove any
/api/discord/role-mappings, admin-register endpoints, or internal-only debug examples before publishing.
+
+
+
+
+
+
+
+
+ Quick checklist
+
+
+
+ - Builder draft created and reviewed.
+ - GitHub PR open with Builder draft link and reviewer assigned.
+ - CI passes (lint, build).
+ - Final review & merge by Docs lead.
+
+
+
+
+
+
+ );
+}