diff --git a/es/agent/workflows.mdx b/es/agent/workflows.mdx
deleted file mode 100644
index 7c120c0174..0000000000
--- a/es/agent/workflows.mdx
+++ /dev/null
@@ -1,346 +0,0 @@
----
-title: "Flujos de trabajo"
-description: "Automatiza el mantenimiento de la documentación con tareas del agente programadas o activadas por eventos mediante cron y webhooks."
-keywords: ["automation", "automate", "cron", "auto-update"]
----
-
-Los flujos de trabajo ejecutan el agente automáticamente según una programación o cuando se hace un push a un repositorio. Cada flujo de trabajo define un prompt para el agente y un desencadenante para indicar cuándo ejecutarlo. Los flujos de trabajo son compatibles con repositorios de GitHub y GitLab.
-
-Cuando se ejecuta un flujo de trabajo, el agente clona los repositorios especificados como contexto, sigue el prompt y abre una solicitud de extracción (o solicitud de fusión en GitLab) o puede enviar los cambios directamente a tu rama de implementación.
-
-Cada flujo de trabajo puede ejecutarse hasta 50 veces al día. Las ejecuciones que fallan no cuentan para este límite.
-
-
-Usa flujos de trabajo que se ejecutan según una programación para automatizar tareas recurrentes, como publicar registros de cambios o comprobar problemas de gramática y estilo.
-
-Usa flujos de trabajo que se ejecutan en eventos de push para automatizar tareas de mantenimiento reactivas, como actualizar referencias de API o identificar actualizaciones de documentación necesarias para nuevas funciones.
-
-
-
-## Crear un flujo de trabajo
-
-
-1. Abre la página [Workflows](https://dashboard.mintlify.com/products/workflows).
-2. Haz clic en **New workflow**.
-3. Configura el nombre del flujo de trabajo, el tipo de disparador, los repositorios y la programación.
-4. Escribe las instrucciones del agente y elige si deseas fusionar automáticamente las solicitudes de extracción.
-5. Opcionalmente, habilita las notificaciones de Slack para cuando el flujo de trabajo se complete.
-6. Haz clic en **Create workflow**.
-
-
-
-
-
-
-
-## Configuración
-
-
-| Campo | Obligatorio | Descripción |
-|-------|-------------|-------------|
-| **Name** | Sí | Nombre para mostrar que se muestra en el dashboard. |
-| **Trigger** | Sí | Configuración del disparador. |
-| **Context** | No | Repositorios clonados como referencia cuando se ejecuta el flujo de trabajo. |
-| **Automerge** | No | Desactivado de forma predeterminada, lo que abre una solicitud de extracción para revisión. Si se habilita, abre una solicitud de extracción y la fusiona automáticamente. |
-| **Notify** | No | Configuración de notificaciones. Envía mensajes de Slack cuando se completen los flujos de trabajo. |
-
-Para repositorios de GitHub, debes tener instalada la aplicación de GitHub de Mintlify en cada repositorio enumerado en los campos de contexto o disparador. Agrega nuevos repositorios en la página de la [aplicación de GitHub](https://dashboard.mintlify.com/settings/organization/github-app) de tu dashboard de Mintlify.
-
-Para repositorios de GitLab, debes conectar tu cuenta de GitLab en la página de [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) de tu dashboard de Mintlify. Luego agrega los repositorios que deseas usar con los flujos de trabajo. Debes tener al menos el rol de Maintainer en cada proyecto para conectar GitLab OAuth.
-
-
- 
- 
-
-
-
-### Disparadores
-
-
-Cada flujo de trabajo debe definir un único disparador.
-
-
-#### Según programación (cron)
-
-
-Ejecuta un flujo de trabajo de forma recurrente usando una expresión cron. Todas las ejecuciones programadas se realizan en UTC.
-
-Los flujos de trabajo se ponen en cola dentro de los 10 minutos siguientes a la hora programada y pueden tardar hasta 10 minutos en ejecutarse.
-
-El valor es una expresión cron estándar de 5 campos con el formato `minute hour day-of-month month day-of-week`. Utiliza una herramienta como [crontab.guru](https://crontab.guru) para crear y validar los horarios.
-
-| Expresión | Programación |
-|-----------|-------------|
-| `0 9 * * 1` | Todos los lunes a las 9:00 AM UTC |
-| `0 0 1 * *` | El primer día de cada mes a medianoche UTC |
-| `0 8 * * 1-5` | Días laborables a las 8:00 AM UTC |
-
-
-#### En eventos de push
-
-
-Ejecuta un flujo de trabajo cuando se envían cambios a un repositorio o branch específicos. Esto incluye tanto fusiones de solicitudes de extracción como envíos directos al branch.
-
-Especifica cada repositorio en formato `owner/repo`. Opcionalmente, especifica un branch a supervisar. Si no especificas un branch, el flujo de trabajo se activa cuando se realizan pushes al branch predeterminado del repositorio.
-
-Un flujo de trabajo puede supervisar pushes en hasta 10 repositorios o branches.
-
-
-### Repositorios de contexto
-
-
-Los repositorios de contexto otorgan al agente acceso de lectura a repositorios adicionales cuando se ejecuta el flujo de trabajo. Esto es útil cuando tu prompt requiere revisar código o contenido fuera de tu repositorio de documentación. Puedes especificar hasta cinco repositorios de contexto por flujo de trabajo.
-
-
-### Combinación automática de cambios
-
-
-De forma predeterminada, el agente abre una solicitud de extracción por cada ejecución del flujo de trabajo para que puedas revisar los cambios antes de que se publiquen. Habilita la combinación automática para fusionar automáticamente la solicitud de extracción sin necesidad de aprobación manual. Esto te proporciona un registro de los cambios en el historial de solicitudes de extracción de tu repositorio, a la vez que automatiza el paso de fusión.
-
-
- Para repositorios de GitHub, la función automerge requiere que la aplicación GitHub de Mintlify tenga permisos de bypass en todos los rulesets que apunten a tu rama de implementación, incluyendo rulesets a nivel de organización y a nivel de repositorio. Consulta [Configurar automerge](/es/guides/configure-automerge) para ver las instrucciones de configuración.
-
- Para repositorios de GitLab, la función automerge utiliza la conexión GitLab OAuth configurada en la página de [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) de tu dashboard de Mintlify. Debes tener al menos el rol de Maintainer en cada proyecto para conectar GitLab OAuth.
-
-
-
-### Notificaciones de Slack
-
-
-Envía mensajes de Slack cuando un flujo de trabajo finalice o falle. Las notificaciones incluyen el estado del flujo de trabajo, un enlace a la solicitud de extracción y un resumen de los cambios.
-
-
-Las notificaciones de Slack requieren la aplicación Mintlify Slack en el espacio de trabajo de Slack de tu organización. Instala la aplicación de Slack desde tu [dashboard](https://dashboard.mintlify.com/products/agent).
-
-
-Al crear o editar un flujo de trabajo en el dashboard, habilita las notificaciones de Slack en el interruptor **Notify on completion**:
-
-1. Si aún no has conectado Slack, haz clic en **Install Slack app**.
-2. Haz clic en el interruptor **Notify on completion**.
-3. Busca y selecciona los canales a los que deseas notificar.
-4. Guarda tu flujo de trabajo.
-
-
-## Gestionar flujos de trabajo
-
-
-Edita, elimina, deshabilita o activa flujos de trabajo desde la página [Workflows](https://dashboard.mintlify.com/products/workflows) en tu dashboard.
-
-
-### Activar un flujo de trabajo manualmente
-
-
-Puedes ejecutar flujos de trabajo basados en cron bajo demanda sin esperar a la siguiente hora programada. Las ejecuciones activadas manualmente cuentan para el límite diario de ejecuciones.
-
-1. Ve a la página [Workflows](https://dashboard.mintlify.com/products/workflows) en tu dashboard.
-2. Haz clic en **View workflows** para ver todos los flujos de trabajo.
-3. Haz clic en el flujo de trabajo que deseas ejecutar.
-4. Haz clic en el botón de activación manual del flujo de trabajo para ejecutarlo.
-
-
-### Deshabilitar un flujo de trabajo
-
-
-Deshabilita un flujo de trabajo para detenerlo temporalmente sin eliminarlo. Los flujos de trabajo deshabilitados conservan su configuración e historial de ejecuciones, pero no se ejecutan según su programación ni en respuesta a eventos push. No se puede activar manualmente un flujo de trabajo deshabilitado.
-
-Para activar o desactivar un flujo de trabajo:
-
-1. Ve a la página [Workflows](https://dashboard.mintlify.com/products/workflows) en tu dashboard.
-2. Haz clic en **View workflows** para ver todos los flujos de trabajo.
-3. Haz clic en el flujo de trabajo que deseas deshabilitar o habilitar.
-4. Haz clic en el interruptor **Active** para desactivar el flujo de trabajo, o actívalo para habilitarlo.
-5. Haz clic en **Save changes**.
-
-Cuando vuelves a habilitar un flujo de trabajo basado en cron, Mintlify recalcula el próximo tiempo de ejecución a partir de la hora actual.
-
-
-## Configuración de GitLab
-
-
-Para usar repositorios de GitLab en un flujo de trabajo, conecta cada proyecto a través de la integración OAuth de GitLab en la página de configuración OAuth de GitLab. Debes conectar todos los repositorios que utilice el flujo de trabajo, incluyendo tu repositorio de documentación y cualquier repositorio de activación o contexto.
-
-
- Los flujos de trabajo requieren un plan de pago de GitLab. El agente utiliza tokens de acceso de proyecto de corta duración para acceder al repositorio, algo que el plan gratuito de GitLab no admite.
-
-
-
-## Prompts
-
-
-Los prompts eficaces se centran en una sola tarea y buscan un resultado concreto. Los flujos de trabajo siempre presentan cierta variabilidad debido a la naturaleza no determinista de los agentes, pero puedes mejorar la consistencia de sus resultados siguiendo estas buenas prácticas:
-
-- Describe el resultado que quieres que el agente consiga.
-- Incluye criterios de éxito.
-- Especifica el contexto que quieres que el agente utilice.
-- Divide las tareas complejas en pasos o en varios flujos de trabajo.
-
-
-### Entorno del agente
-
-
-El agente se ejecuta en un sandbox aislado. Al redactar prompts, solo haz referencia a las herramientas disponibles para el agente.
-
-- Utilidades estándar de shell (`grep`, `sed`, `awk`, `curl` y otras)
-- `git` y la CLI de GitHub (`gh`)
-- La CLI de Mintlify (`mint`)
-- Node.js y Bun
-- **Búsqueda web** para encontrar información actualizada fuera de tu documentación
-- **Obtención web** para recuperar y leer el contenido de una página web
-
-El agente no puede instalar paquetes ni herramientas adicionales en tiempo de ejecución. No se puede acceder a los repositorios de paquetes desde el sandbox.
-
-Los prompts que indican al agente que ejecute herramientas no disponibles pueden producir resultados inesperados o fallar.
-
-
-## Ejemplos de prompts
-
-
-Estos ejemplos de prompts demuestran patrones comunes de flujos de trabajo. Crea un flujo de trabajo en el dashboard y pega el prompt en el campo de instrucciones.
-
-
-### Borrador de documentación para nuevas funcionalidades
-
-
-
- Si utilizas sugerencias del agente en tu dashboard, este flujo de trabajo replica ese comportamiento.
-
- Añade este flujo de trabajo, con las modificaciones que necesites para tu proyecto, para redactar automáticamente la documentación a medida que añades nuevas funcionalidades a tu producto.
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product`. Identify any new features, APIs, or other changes that require documentation.
-
-For each new addition, draft documentation updates that explain what it does, when to use it, and how to configure it. Include a code example where relevant.
-
-Success criteria: After reading any new or updated documentation, users understand what the feature is, if it applies to tasks they do, and how to use it.
-
-## Important
-
-- Only document changes that affect end users. Skip internal refactors or dependency updates.
-- Match the style and structure of existing docs pages.
-```
-
-
-### Auditoría de estilo
-
-
-**Trigger:** On push to `your-org/your-docs` (main branch)
-
-```text
-Review all MDX files changed in the last merged PR against the style guide at `path/to/style-guide`.
-
-Open a pull request to resolve any style violations that can be fixed automatically. For any edits that require judgment or nuance, note them in the PR body with the specific lines, rule violations, and suggested fixes.
-
-Success criteria:
-- All style violations have a proposed resolution.
-- No new style violations are introduced.
-
-## Important
-
-- Do not change content meaning. Only correct style violations.
-- Skip any files in language subdirectories (`es/`, `fr/`, `zh/`).
-```
-
-
-### Actualizar la referencia de la API
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product` for changes to API endpoints, parameters, response shapes, or error codes.
-
-Update the corresponding API specifications or pages in the docs to reflect the changes. Include updated parameter descriptions, type information, and examples where affected.
-
-Success criteria: All API specifications and pages are up to date with the changes in the product repository.
-
-## Important
-
-- If a parameter or endpoint was removed, mark it as deprecated rather than deleting it unless the code explicitly removes it with no deprecation period.
-- If no API changes were introduced, do nothing.
-```
-
-
-### Hacer seguimiento del desfase de traducción
-
-
-**Trigger:** Cron schedule `0 9 * * 3` (miércoles a las 9:00 AM UTC)
-
-Actualiza los subdirectorios de idioma de ejemplo (`es/`, `fr/`, `zh/`) a tus subdirectorios de idioma reales.
-
-```text
-Compare the English MDX files in the repo against their counterparts in the `es/`, `fr/`, and `zh/` subdirectories. Use git history to identify English files updated more recently than their translations.
-
-Open a pull request that lists pages that are out of sync, organized by language. For each page, include the date of the last English update and a brief summary of what changed so translators have context on what to update.
-
-Success criteria: Any discrepancies between the English and translated files are identified and listed in the pull request.
-
-## Important
-
-- If a translated file does not exist, flag it as missing rather than out of sync.
-- Group findings by language, then by how far out of date they are (most stale first).
-```
-
-
-### Auditoría de SEO y metadata
-
-
-**Trigger:** Cron schedule `0 9 * * 1` (lunes a las 9:00 AM UTC)
-
-```text
-Audit all MDX files in the docs for SEO and metadata quality. Check for:
-
-- Missing or empty `title` frontmatter
-- Titles that are too long (over 60 characters) — long titles are truncated in search result snippets
-- Titles that follow a boilerplate pattern like "PageType - Name" without describing the specific content of the page
-- Missing or empty `description` frontmatter (see OpenAPI pages below — do not treat as missing when an OpenAPI spec supplies the description)
-- Descriptions that are too short (under 130 characters) — short descriptions are frequently ignored by Google in favor of auto-generated snippets
-- Descriptions that are too long (over 160 characters)
-- Pages that share an identical description with other pages — each page needs a unique description
-
-Open a pull request with improvements for any issues found.
-
-When writing titles: be descriptive and specific about what the page covers. Avoid generic patterns like "Overview - Product Name". Target 50-60 characters.
-
-When writing descriptions: summarize what the specific page covers in plain language. Include 2-3 terms a user would actually search for. Never reuse the same description across pages. Target 130-155 characters.
-
-### Pages with `openapi:` in frontmatter (API reference from spec)
-
-The `openapi:` frontmatter value can be either an **operation reference** (e.g., `openapi: GET /users/{id}`) or a **file reference** (e.g., `openapi: ./openapi.yaml`). Only operation references supply per-page `summary` and `description` from the spec.
-
-For pages with an **operation reference**:
-- Read the referenced OpenAPI spec file to check whether the operation defines a `description`.
-- If the operation **has** a `description`: do not add a `description:` field to frontmatter. If one was incorrectly added, remove it so the metadata comes from the spec.
-- If the operation **has no** `description`: audit `description` frontmatter as normal — add one if missing or fix it if it fails the quality checks.
-- If the operation defines a `summary` and the page has no `title:` frontmatter, treat the title as present — do not add one.
-- Never edit the OpenAPI spec files themselves.
-
-For pages with a **file reference**, audit all frontmatter fields as normal.
-
-Success criteria:
-- Pages have a unique title under 60 characters that describes the specific content
-- Pages have a unique description between 130 and 160 characters (except for pages where the OpenAPI spec supplies the description)
-
-## Important
-
-- Only update frontmatter. Do not change page content or OpenAPI spec files.
-- If all pages have complete and reasonable metadata, do nothing.
-```
-
-
-### Registro de cambios con notificaciones
-
-
-**Trigger:** Cron schedule `0 9 * * 1` (lunes a las 9:00 AM UTC)
-**Context repos:** `your-org/your-product`
-**Slack notifications:** canal `documentation`, usuario `tech-writer`
-
-```text
-Review all merged PRs in `your-org/your-product` from the past week. Draft a changelog entry summarizing new features, bug fixes, and breaking changes.
-
-Success criteria: The changelog accurately reflects the week's changes and is ready for review.
-```
diff --git a/fr/agent/workflows.mdx b/fr/agent/workflows.mdx
deleted file mode 100644
index bb2994a0cd..0000000000
--- a/fr/agent/workflows.mdx
+++ /dev/null
@@ -1,346 +0,0 @@
----
-title: "Workflows"
-description: "Automatisez la maintenance de la documentation avec des tâches d'agent planifiées ou déclenchées par des événements via cron et webhooks."
-keywords: ["automation", "automate", "cron", "auto-update"]
----
-
-Les workflows exécutent automatiquement l'agent selon une planification ou lors d'une poussée vers un référentiel. Chaque workflow définit un prompt pour l'agent ainsi qu'un déclencheur indiquant quand l'exécuter. Les workflows prennent en charge les référentiels GitHub et GitLab.
-
-Lorsqu'un workflow s'exécute, l'agent clone tous les référentiels spécifiés comme contexte, suit le prompt, puis ouvre soit une pull request (ou merge request pour GitLab), soit pousse directement les modifications vers votre branche de déploiement.
-
-Chaque workflow peut s'exécuter jusqu'à 50 fois par jour. Les exécutions qui échouent ne sont pas comptabilisées dans cette limite.
-
-
-Utilisez des workflows qui s'exécutent selon une planification pour automatiser des tâches récurrentes, comme la publication de journaux des modifications ou la vérification des problèmes de grammaire et de style.
-
-Utilisez des workflows qui s'exécutent lors d'événements de poussée pour automatiser des tâches de maintenance réactive, comme la mise à jour des références d'API ou l'identification des mises à jour de documentation nécessaires pour de nouvelles fonctionnalités.
-
-
-
-## Créer un workflow
-
-
-1. Ouvrez la page [Workflows](https://dashboard.mintlify.com/products/workflows).
-2. Cliquez sur **New workflow**.
-3. Configurez le nom du workflow, le type de déclencheur, les référentiels et la planification.
-4. Rédigez les instructions de l'agent et choisissez si vous souhaitez fusionner automatiquement les pull requests.
-5. Facultatif : activez les notifications Slack pour lorsque le workflow se termine.
-6. Cliquez sur **Create workflow**.
-
-
-
-
-
-
-
-## Configuration
-
-
-| Champ | Obligatoire | Description |
-|-------|-------------|-------------|
-| **Name** | Oui | Nom d'affichage visible dans le dashboard. |
-| **Trigger** | Oui | Configuration du déclencheur. |
-| **Context** | Non | Référentiels clonés comme référence lors de l'exécution du workflow. |
-| **Automerge** | Non | Désactivé par défaut, ce qui ouvre une pull request pour révision. Si activé, ouvre une pull request et la fusionne automatiquement. |
-| **Notify** | Non | Configuration des notifications. Envoyez des messages Slack lorsque les workflows sont terminés. |
-
-Pour les référentiels GitHub, vous devez avoir installé la GitHub App Mintlify sur chaque référentiel répertorié dans les champs de contexte ou de déclencheur. Ajoutez de nouveaux référentiels sur la page [GitHub app](https://dashboard.mintlify.com/settings/organization/github-app) de votre dashboard Mintlify.
-
-Pour les référentiels GitLab, vous devez connecter votre compte GitLab sur la page [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) de votre dashboard Mintlify. Ajoutez ensuite les référentiels que vous souhaitez utiliser avec les workflows. Vous devez disposer au minimum du rôle Maintainer sur chaque projet pour connecter GitLab OAuth.
-
-
-
-
-
-
-
-### Déclencheurs
-
-
-Chaque workflow doit définir un seul déclencheur.
-
-
-#### Selon une planification (cron)
-
-
-Exécutez un workflow à intervalles réguliers à l'aide d'une expression cron. Toutes les planifications s'exécutent en UTC.
-
-Les workflows sont placés en file d'attente dans les 10 minutes suivant l'heure planifiée et leur exécution peut prendre jusqu'à 10 minutes.
-
-La valeur est une expression cron standard à 5 champs au format `minute hour day-of-month month day-of-week`. Utilisez un outil comme [crontab.guru](https://crontab.guru) pour définir et valider les programmations.
-
-| Expression | Planification |
-|------------|--------------|
-| `0 9 * * 1` | Chaque lundi à 9 h 00 UTC |
-| `0 0 1 * *` | Premier jour de chaque mois à 0 h 00 UTC |
-| `0 8 * * 1-5` | Du lundi au vendredi à 8 h 00 UTC |
-
-
-#### Lors des événements de type push
-
-
-Exécutez un workflow lorsque des modifications sont poussées vers un référentiel ou une branche spécifiques. Cela inclut les fusions de pull requests et les poussées directes vers la branche.
-
-Spécifiez chaque référentiel au format `owner/repo`. Vous pouvez optionnellement spécifier une branche à surveiller. Si vous ne spécifiez pas de branche, le workflow se déclenche lorsque des modifications sont poussées vers la branche par défaut du référentiel.
-
-Un workflow peut surveiller les poussées vers jusqu'à 10 référentiels ou branches.
-
-
-### Référentiels de contexte
-
-
-Les référentiels de contexte accordent à l'agent un accès en lecture à des référentiels supplémentaires lors de l'exécution du workflow. Cela est utile lorsque votre prompt doit examiner du code ou du contenu en dehors de votre référentiel de documentation. Vous pouvez spécifier jusqu'à cinq référentiels de contexte par workflow.
-
-
-### Fusion automatique des modifications
-
-
-Par défaut, l'agent ouvre une pull request pour chaque exécution de workflow afin que vous puissiez examiner les modifications avant leur mise en production. Activez la fusion automatique pour fusionner automatiquement la pull request sans approbation manuelle. Cela vous permet de conserver une trace des modifications dans l'historique des pull requests de votre référentiel tout en automatisant l'étape de fusion.
-
-
- Pour les référentiels GitHub, l'automerge nécessite que la GitHub App Mintlify dispose de permissions de contournement sur tous les ensembles de règles ciblant votre branche de déploiement, y compris les ensembles de règles définis au niveau de l'organisation et au niveau du dépôt. Consultez [Configurer l'automerge](/fr/guides/configure-automerge) pour les instructions de configuration.
-
- Pour les référentiels GitLab, l'automerge utilise la connexion GitLab OAuth configurée sur la page [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) de votre dashboard Mintlify. Vous devez disposer au minimum du rôle Maintainer sur chaque projet pour connecter GitLab OAuth.
-
-
-
-### Notifications Slack
-
-
-Envoyez des messages Slack lorsqu'un workflow se termine ou échoue. Les notifications incluent le statut du workflow, un lien vers la pull request et un résumé des changements.
-
-
-Les notifications Slack nécessitent l'application Mintlify Slack dans l'espace de travail Slack de votre organisation. Installez l'application Slack depuis votre [dashboard](https://dashboard.mintlify.com/products/agent).
-
-
-Lors de la création ou de la modification d'un workflow dans le dashboard, activez les notifications Slack via le bouton **Notify on completion** :
-
-1. Si vous n'avez pas encore connecté Slack, cliquez sur **Install Slack app**.
-2. Cliquez sur le bouton **Notify on completion**.
-3. Recherchez et sélectionnez les canaux que vous souhaitez notifier.
-4. Enregistrez votre workflow.
-
-
-## Gérer les workflows
-
-
-Modifiez, supprimez, désactivez ou déclenchez des workflows depuis la page [Workflows](https://dashboard.mintlify.com/products/workflows) de votre dashboard.
-
-
-### Déclencher un workflow manuellement
-
-
-Vous pouvez exécuter les workflows basés sur cron à la demande sans attendre la prochaine heure planifiée. Les exécutions déclenchées manuellement sont comptabilisées dans la limite quotidienne d'exécutions.
-
-1. Accédez à la page [Workflows](https://dashboard.mintlify.com/products/workflows) dans votre dashboard.
-2. Cliquez sur **View workflows** pour voir tous les workflows.
-3. Cliquez sur le workflow que vous souhaitez exécuter.
-4. Cliquez sur le bouton de déclenchement manuel du workflow pour l'exécuter.
-
-
-### Désactiver un workflow
-
-
-Désactivez un workflow pour l'arrêter temporairement sans le supprimer. Les workflows désactivés conservent leur configuration et leur historique d'exécutions, mais ne s'exécutent pas selon leur planification ni en réponse à des événements push. Vous ne pouvez pas déclencher manuellement un workflow désactivé.
-
-Pour activer ou désactiver un workflow :
-
-1. Accédez à la page [Workflows](https://dashboard.mintlify.com/products/workflows) dans votre dashboard.
-2. Cliquez sur **View workflows** pour voir tous les workflows.
-3. Cliquez sur le workflow que vous souhaitez désactiver ou activer.
-4. Cliquez sur le bouton bascule **Active** pour désactiver le workflow, ou activez-le pour le réactiver.
-5. Cliquez sur **Save changes**.
-
-Lorsque vous réactivez un workflow basé sur cron, Mintlify recalcule le prochain délai d'exécution à partir de l'heure actuelle.
-
-
-## Configuration GitLab
-
-
-Pour utiliser des référentiels GitLab dans un workflow, connectez chaque projet via l'intégration OAuth GitLab sur la page de configuration OAuth GitLab. Vous devez connecter tous les référentiels utilisés par le workflow, y compris votre référentiel de documentation et tous les référentiels de déclenchement ou de contexte.
-
-
- Les workflows nécessitent un forfait GitLab payant. L'agent utilise des jetons d'accès projet de courte durée pour accéder aux référentiels, ce que le plan gratuit de GitLab ne prend pas en charge.
-
-
-
-## Prompts
-
-
-Des prompts efficaces se concentrent sur une seule tâche et visent un résultat précis. Les workflows présentent toujours une certaine variabilité en raison de la nature non déterministe des agents, mais vous pouvez améliorer la cohérence des résultats des workflows en suivant ces bonnes pratiques.
-
-- Décrivez le résultat que vous souhaitez que l'agent produise.
-- Incluez des critères de réussite.
-- Précisez le contexte que vous voulez que l'agent utilise.
-- Divisez les tâches complexes en étapes ou en plusieurs workflows.
-
-
-### Environnement de l'agent
-
-
-L'agent s'exécute dans un sandbox isolé. Lorsque vous rédigez des prompts, faites uniquement référence aux outils dont l'agent dispose.
-
-- Utilitaires shell standard (`grep`, `sed`, `awk`, `curl`, entre autres)
-- `git` et la CLI GitHub (`gh`)
-- La CLI Mintlify (`mint`)
-- Node.js et Bun
-- **Recherche web** pour trouver des informations à jour en dehors de votre documentation
-- **Récupération web** pour récupérer et lire le contenu d'une page web
-
-L'agent ne peut pas installer de paquets ni d'outils supplémentaires au moment de l'exécution. Les registres de paquets ne sont pas accessibles depuis le sandbox.
-
-Les prompts qui demandent à l'agent d'exécuter des outils indisponibles peuvent produire des résultats inattendus ou échouer.
-
-
-## Exemples de prompts
-
-
-Ces exemples de prompts illustrent des modèles de workflows courants. Créez un workflow dans le dashboard et collez le prompt dans le champ d'instructions.
-
-
-### Brouillon de documentation pour les nouvelles fonctionnalités
-
-
-
- Si vous utilisez les suggestions de l'agent dans votre Dashboard, ce workflow reproduit ce comportement.
-
- Ajoutez ce workflow, en l'adaptant à votre projet, pour générer automatiquement des brouillons de documentation à mesure que vous ajoutez de nouvelles fonctionnalités à votre produit.
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product`. Identify any new features, APIs, or other changes that require documentation.
-
-For each new addition, draft documentation updates that explain what it does, when to use it, and how to configure it. Include a code example where relevant.
-
-Success criteria: After reading any new or updated documentation, users understand what the feature is, if it applies to tasks they do, and how to use it.
-
-## Important
-
-- Only document changes that affect end users. Skip internal refactors or dependency updates.
-- Match the style and structure of existing docs pages.
-```
-
-
-### Audit de style
-
-
-**Trigger:** On push to `your-org/your-docs` (main branch)
-
-```text
-Review all MDX files changed in the last merged PR against the style guide at `path/to/style-guide`.
-
-Open a pull request to resolve any style violations that can be fixed automatically. For any edits that require judgment or nuance, note them in the PR body with the specific lines, rule violations, and suggested fixes.
-
-Success criteria:
-- All style violations have a proposed resolution.
-- No new style violations are introduced.
-
-## Important
-
-- Do not change content meaning. Only correct style violations.
-- Skip any files in language subdirectories (`es/`, `fr/`, `zh/`).
-```
-
-
-### Mettre à jour la référence d'API
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product` for changes to API endpoints, parameters, response shapes, or error codes.
-
-Update the corresponding API specifications or pages in the docs to reflect the changes. Include updated parameter descriptions, type information, and examples where affected.
-
-Success criteria: All API specifications and pages are up to date with the changes in the product repository.
-
-## Important
-
-- If a parameter or endpoint was removed, mark it as deprecated rather than deleting it unless the code explicitly removes it with no deprecation period.
-- If no API changes were introduced, do nothing.
-```
-
-
-### Suivre le retard de traduction
-
-
-**Trigger:** Cron schedule `0 9 * * 3` (mercredis à 9 h 00 UTC)
-
-Mettez à jour les sous-répertoires de langue d'exemple (`es/`, `fr/`, `zh/`) avec vos sous-répertoires de langue réels.
-
-```text
-Compare the English MDX files in the repo against their counterparts in the `es/`, `fr/`, and `zh/` subdirectories. Use git history to identify English files updated more recently than their translations.
-
-Open a pull request that lists pages that are out of sync, organized by language. For each page, include the date of the last English update and a brief summary of what changed so translators have context on what to update.
-
-Success criteria: Any discrepancies between the English and translated files are identified and listed in the pull request.
-
-## Important
-
-- If a translated file does not exist, flag it as missing rather than out of sync.
-- Group findings by language, then by how far out of date they are (most stale first).
-```
-
-
-### Audit SEO et métadonnées
-
-
-**Trigger:** Cron schedule `0 9 * * 1` (lundis à 9 h 00 UTC)
-
-```text
-Audit all MDX files in the docs for SEO and metadata quality. Check for:
-
-- Missing or empty `title` frontmatter
-- Titles that are too long (over 60 characters) — long titles are truncated in search result snippets
-- Titles that follow a boilerplate pattern like "PageType - Name" without describing the specific content of the page
-- Missing or empty `description` frontmatter (see OpenAPI pages below — do not treat as missing when an OpenAPI spec supplies the description)
-- Descriptions that are too short (under 130 characters) — short descriptions are frequently ignored by Google in favor of auto-generated snippets
-- Descriptions that are too long (over 160 characters)
-- Pages that share an identical description with other pages — each page needs a unique description
-
-Open a pull request with improvements for any issues found.
-
-When writing titles: be descriptive and specific about what the page covers. Avoid generic patterns like "Overview - Product Name". Target 50-60 characters.
-
-When writing descriptions: summarize what the specific page covers in plain language. Include 2-3 terms a user would actually search for. Never reuse the same description across pages. Target 130-155 characters.
-
-### Pages with `openapi:` in frontmatter (API reference from spec)
-
-The `openapi:` frontmatter value can be either an **operation reference** (e.g., `openapi: GET /users/{id}`) or a **file reference** (e.g., `openapi: ./openapi.yaml`). Only operation references supply per-page `summary` and `description` from the spec.
-
-For pages with an **operation reference**:
-- Read the referenced OpenAPI spec file to check whether the operation defines a `description`.
-- If the operation **has** a `description`: do not add a `description:` field to frontmatter. If one was incorrectly added, remove it so the metadata comes from the spec.
-- If the operation **has no** `description`: audit `description` frontmatter as normal — add one if missing or fix it if it fails the quality checks.
-- If the operation defines a `summary` and the page has no `title:` frontmatter, treat the title as present — do not add one.
-- Never edit the OpenAPI spec files themselves.
-
-For pages with a **file reference**, audit all frontmatter fields as normal.
-
-Success criteria:
-- Pages have a unique title under 60 characters that describes the specific content
-- Pages have a unique description between 130 and 160 characters (except for pages where the OpenAPI spec supplies the description)
-
-## Important
-
-- Only update frontmatter. Do not change page content or OpenAPI spec files.
-- If all pages have complete and reasonable metadata, do nothing.
-```
-
-
-### Journal des modifications avec notifications
-
-
-**Trigger:** Cron schedule `0 9 * * 1` (lundis à 9 h 00 UTC)
-**Context repos:** `your-org/your-product`
-**Slack notifications:** canal `documentation`, utilisateur `tech-writer`
-
-```text
-Review all merged PRs in `your-org/your-product` from the past week. Draft a changelog entry summarizing new features, bug fixes, and breaking changes.
-
-Success criteria: The changelog accurately reflects the week's changes and is ready for review.
-```
diff --git a/redirects.json b/redirects.json
index 9a406341a0..f429a60b72 100644
--- a/redirects.json
+++ b/redirects.json
@@ -75,6 +75,10 @@
"source": "/fr/optimize/search-boost",
"destination": "/fr/optimize/search"
},
+ {
+ "source": "/zh/optimize/search-boost",
+ "destination": "/zh/optimize/search"
+ },
{
"source": "/ai/assistant",
"destination": "/assistant/index"
@@ -1247,10 +1251,34 @@
"source": "/agent/workflows",
"destination": "/automations/index"
},
+ {
+ "source": "/es/agent/workflows",
+ "destination": "/es/automations/index"
+ },
+ {
+ "source": "/fr/agent/workflows",
+ "destination": "/fr/automations/index"
+ },
+ {
+ "source": "/zh/agent/workflows",
+ "destination": "/zh/automations/index"
+ },
{
"source": "/agent/workflows/:page",
"destination": "/automations/:page"
},
+ {
+ "source": "/es/agent/workflows/:page",
+ "destination": "/es/automations/:page"
+ },
+ {
+ "source": "/fr/agent/workflows/:page",
+ "destination": "/fr/automations/:page"
+ },
+ {
+ "source": "/zh/agent/workflows/:page",
+ "destination": "/zh/automations/:page"
+ },
{
"source": "/agent/quickstart",
"destination": "/agent/index"
diff --git a/zh/agent/workflows.mdx b/zh/agent/workflows.mdx
deleted file mode 100644
index d615ea61e8..0000000000
--- a/zh/agent/workflows.mdx
+++ /dev/null
@@ -1,346 +0,0 @@
----
-title: "工作流"
-description: "通过定时或事件触发的 agent 任务自动维护文档，包括 cron 计划和基于 webhook 的自动化。"
-keywords: ["automation", "automate", "cron", "auto-update"]
----
-
-工作流会在预设的计划下，或在存储库发生 push 时自动运行 agent。每个工作流都会为 agent 定义一个提示词，以及一个触发执行的条件。工作流同时支持 GitHub 和 GitLab 存储库。
-
-当工作流运行时，agent 会将指定的存储库克隆为上下文，遵循提示词，并执行以下两种操作之一：要么创建一个拉取请求（或 GitLab 的合并请求），要么将更改直接推送到你的部署用分支。
-
-每个工作流每天最多可运行 50 次。运行失败不会计入此限制。
-
-
-使用按计划运行的工作流来自动化执行周期性任务，例如发布更新日志或检查语法和写作风格问题。
-
-使用在 push 事件上运行的工作流来自动化执行响应型维护任务，例如更新 API 参考文档，或识别新功能所需的文档更新。
-
-
-
-## 创建工作流
-
-
-1. 打开 [Workflows](https://dashboard.mintlify.com/products/workflows) 页面。
-2. 点击 **New workflow**。
-3. 配置工作流名称、触发器类型、存储库和计划。
-4. 编写 agent 指令，并选择是否自动合并拉取请求。
-5. 可选：启用 Slack 通知，以便在工作流完成时收到通知。
-6. 点击 **Create workflow**。
-
-
-
-
-
-
-
-## 配置
-
-
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| **Name** | 是 | 在控制台中显示的名称。 |
-| **Trigger** | 是 | 触发器配置。 |
-| **Context** | 否 | 工作流运行时作为参考克隆的存储库。 |
-| **Automerge** | 否 | 默认关闭，此时会打开一个拉取请求以供审查。如果启用，则会打开一个拉取请求并自动将其合并。 |
-| **Notify** | 否 | 通知配置。工作流完成时发送 Slack 消息。 |
-
-对于 GitHub 存储库，你必须在上下文或触发器字段中列出的每个存储库上安装 Mintlify GitHub App。请在 Mintlify 控制台的 [GitHub app](https://dashboard.mintlify.com/settings/organization/github-app) 页面中添加新的存储库。
-
-对于 GitLab 存储库，你必须在 Mintlify 控制台的 [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) 页面上连接你的 GitLab 账户。然后添加你想要与工作流一起使用的存储库。你必须在每个项目上至少拥有 Maintainer 角色才能连接 GitLab OAuth。
-
-
-
-
-
-
-
-### 触发器
-
-
-每个工作流必须定义一个触发器。
-
-
-#### 按计划 (cron)
-
-
-使用 cron 表达式按固定计划运行工作流。所有计划均使用 UTC 时间运行。
-
-工作流会在预定时间起的 10 分钟内进入队列，并且可能最多需要 10 分钟才能开始运行。
-
-该值是一个标准的 5 个字段的 cron 表达式，格式为 `minute hour day-of-month month day-of-week`。可以使用类似 [crontab.guru](https://crontab.guru) 这样的工具来构建和验证调度计划。
-
-| 表达式 | 计划 |
-|--------|------|
-| `0 9 * * 1` | 每周一 9:00 (UTC) |
-| `0 0 1 * *` | 每个月第一天的 00:00 (UTC，午夜) |
-| `0 8 * * 1-5` | 每个工作日 8:00 (UTC) |
-
-
-#### 在 push 事件时
-
-
-当更改被推送到指定存储库或特定 branch 时运行工作流。这包括拉取请求合并和直接推送到该 branch 的操作。
-
-以 `owner/repo` 格式指定每个存储库。可选指定要监控的 branch。如果你未指定 branch，则工作流会在更改推送到存储库默认 branch 时触发。
-
-一个工作流可以监控最多 10 个存储库或 branch 上的推送。
-
-
-### Context 存储库
-
-
-Context 存储库在工作流运行时为 agent 提供对其他存储库的只读访问权限。当你的提示词需要查看文档存储库之外的代码或内容时，这会很有用。每个工作流最多可以指定五个上下文存储库。
-
-
-### 自动合并更改
-
-
-默认情况下，agent 会为每次工作流运行创建一个拉取请求，以便你在更改上线之前进行审查。启用自动合并可自动合并该拉取请求，无需手动批准。这样一来，你既可以在存储库的拉取请求历史记录中保留更改记录，又能自动完成合并步骤。
-
-
- 对于 GitHub 存储库，自动合并要求 Mintlify GitHub 应用对所有针对你部署分支的规则集都拥有绕过权限，包括组织级和仓库级的规则集。请参阅[配置自动合并](/zh/guides/configure-automerge)了解设置说明。
-
- 对于 GitLab 存储库，自动合并使用在 Mintlify 控制台的 [GitLab OAuth](https://dashboard.mintlify.com/settings/organization/gitlab-oauth) 页面上配置的 GitLab OAuth 连接。你必须在每个项目上至少拥有 Maintainer 角色才能连接 GitLab OAuth。
-
-
-
-### Slack 通知
-
-
-在工作流完成或失败时发送 Slack 消息。通知内容包括工作流状态、拉取请求链接以及变更摘要。
-
-
-Slack 通知要求你的组织的 Slack 工作区中已安装 Mintlify Slack 应用。请从你的[控制台](https://dashboard.mintlify.com/products/agent)安装 Slack 应用。
-
-
-在控制台中创建或编辑工作流时，在 **Notify on completion** 开关下启用 Slack 通知：
-
-1. 如果你尚未连接 Slack，请点击 **Install Slack app**。
-2. 点击 **Notify on completion** 开关。
-3. 搜索并选择你想要通知的频道。
-4. 保存你的工作流。
-
-
-## 管理工作流
-
-
-从控制台的 [Workflows](https://dashboard.mintlify.com/products/workflows) 页面编辑、删除、禁用或触发工作流。
-
-
-### 手动触发工作流
-
-
-你可以按需运行基于 cron 的工作流，无需等待下一个计划时间。手动触发的运行会计入每日运行限制。
-
-1. 前往控制台中的 [Workflows](https://dashboard.mintlify.com/products/workflows) 页面。
-2. 点击 **View workflows** 查看所有工作流。
-3. 点击你要运行的工作流。
-4. 点击 手动触发工作流按钮来触发工作流。
-
-
-### 禁用工作流
-
-
-禁用工作流可以暂时停止其运行，而无需删除它。已禁用的工作流会保留其配置和运行历史，但不会按计划执行，也不会响应推送事件。你无法手动触发已禁用的工作流。
-
-切换工作流状态：
-
-1. 前往控制台中的 [Workflows](https://dashboard.mintlify.com/products/workflows) 页面。
-2. 点击 **View workflows** 查看所有工作流。
-3. 点击你要禁用或启用的工作流。
-4. 点击 **Active** 开关以禁用工作流，或将其打开以启用。
-5. 点击 **Save changes**。
-
-当你重新启用基于 cron 的工作流时，Mintlify 会从当前时间重新计算下次运行时间。
-
-
-## GitLab 设置
-
-
-要在工作流中使用 GitLab 存储库，请通过 GitLab OAuth 设置页面上的 GitLab OAuth 集成连接每个项目。你必须连接工作流涉及的所有存储库，包括你的文档存储库以及任何触发或上下文存储库。
-
-
- 工作流需要 GitLab 付费版本。Agent 使用短期项目访问令牌来访问存储库，而 GitLab 免费版不支持此功能。
-
-
-
-## 提示词
-
-
-有效的提示词会专注于单一任务，并有清晰的预期结果。由于 Agent 的非确定性特性，工作流总会存在一定差异，但你可以通过遵循以下最佳实践来提高工作流输出的一致性。
-
-- 描述你希望 Agent 达成的结果。
-- 包含衡量成功的标准。
-- 指定你希望 Agent 使用的 context。
-- 将复杂任务拆分为步骤或多个工作流。
-
-
-### Agent 环境
-
-
-agent 在隔离的沙箱中运行。编写提示时，只应提及 agent 可用的工具。
-
-- 标准 shell 实用工具 (`grep`、`sed`、`awk`、`curl` 等)
-- `git` 和 GitHub CLI (`gh`)
-- Mintlify CLI (`mint`)
-- Node.js 和 Bun
-- **网络搜索**，用于查找文档之外的最新信息
-- **网页获取**，用于检索和阅读网页内容
-
-agent 无法在运行时安装额外的软件包或工具。软件包注册表在沙箱中不可访问。
-
-要求 agent 运行不可用工具的提示可能会产生意外结果或失败。
-
-
-## 示例提示词
-
-
-以下示例提示词展示了常见的工作流模式。在控制台中创建工作流，并将提示词粘贴到指令字段中。
-
-
-### 新功能文档草稿
-
-
-
- 如果你在控制台中使用智能代理建议 (agent suggestions)，此工作流会复现相同的行为。
-
- 按项目需要对该工作流进行必要修改后添加，即可在为产品添加新功能时自动起草文档。
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product`. Identify any new features, APIs, or other changes that require documentation.
-
-For each new addition, draft documentation updates that explain what it does, when to use it, and how to configure it. Include a code example where relevant.
-
-Success criteria: After reading any new or updated documentation, users understand what the feature is, if it applies to tasks they do, and how to use it.
-
-## Important
-
-- Only document changes that affect end users. Skip internal refactors or dependency updates.
-- Match the style and structure of existing docs pages.
-```
-
-
-### 样式审查
-
-
-**Trigger:** On push to `your-org/your-docs` (main branch)
-
-```text
-Review all MDX files changed in the last merged PR against the style guide at `path/to/style-guide`.
-
-Open a pull request to resolve any style violations that can be fixed automatically. For any edits that require judgment or nuance, note them in the PR body with the specific lines, rule violations, and suggested fixes.
-
-Success criteria:
-- All style violations have a proposed resolution.
-- No new style violations are introduced.
-
-## Important
-
-- Do not change content meaning. Only correct style violations.
-- Skip any files in language subdirectories (`es/`, `fr/`, `zh/`).
-```
-
-
-### 更新 API 参考文档
-
-
-**Trigger:** On push to `your-org/your-product` (main branch)
-**Context repos:** `your-org/your-docs`
-
-```text
-Review the diff from the last merged PR in `your-org/your-product` for changes to API endpoints, parameters, response shapes, or error codes.
-
-Update the corresponding API specifications or pages in the docs to reflect the changes. Include updated parameter descriptions, type information, and examples where affected.
-
-Success criteria: All API specifications and pages are up to date with the changes in the product repository.
-
-## Important
-
-- If a parameter or endpoint was removed, mark it as deprecated rather than deleting it unless the code explicitly removes it with no deprecation period.
-- If no API changes were introduced, do nothing.
-```
-
-
-### 跟踪翻译进度滞后
-
-
-**Trigger:** Cron schedule `0 9 * * 3`（每周三 9:00 UTC）
-
-将示例语言子目录 (`es/`、`fr/`、`zh/`) 更新为你实际使用的语言子目录。
-
-```text
-Compare the English MDX files in the repo against their counterparts in the `es/`, `fr/`, and `zh/` subdirectories. Use git history to identify English files updated more recently than their translations.
-
-Open a pull request that lists pages that are out of sync, organized by language. For each page, include the date of the last English update and a brief summary of what changed so translators have context on what to update.
-
-Success criteria: Any discrepancies between the English and translated files are identified and listed in the pull request.
-
-## Important
-
-- If a translated file does not exist, flag it as missing rather than out of sync.
-- Group findings by language, then by how far out of date they are (most stale first).
-```
-
-
-### SEO 和 metadata 审核
-
-
-**Trigger:** Cron schedule `0 9 * * 1`（每周一 9:00 UTC）
-
-```text
-Audit all MDX files in the docs for SEO and metadata quality. Check for:
-
-- Missing or empty `title` frontmatter
-- Titles that are too long (over 60 characters) — long titles are truncated in search result snippets
-- Titles that follow a boilerplate pattern like "PageType - Name" without describing the specific content of the page
-- Missing or empty `description` frontmatter (see OpenAPI pages below — do not treat as missing when an OpenAPI spec supplies the description)
-- Descriptions that are too short (under 130 characters) — short descriptions are frequently ignored by Google in favor of auto-generated snippets
-- Descriptions that are too long (over 160 characters)
-- Pages that share an identical description with other pages — each page needs a unique description
-
-Open a pull request with improvements for any issues found.
-
-When writing titles: be descriptive and specific about what the page covers. Avoid generic patterns like "Overview - Product Name". Target 50-60 characters.
-
-When writing descriptions: summarize what the specific page covers in plain language. Include 2-3 terms a user would actually search for. Never reuse the same description across pages. Target 130-155 characters.
-
-### Pages with `openapi:` in frontmatter (API reference from spec)
-
-The `openapi:` frontmatter value can be either an **operation reference** (e.g., `openapi: GET /users/{id}`) or a **file reference** (e.g., `openapi: ./openapi.yaml`). Only operation references supply per-page `summary` and `description` from the spec.
-
-For pages with an **operation reference**:
-- Read the referenced OpenAPI spec file to check whether the operation defines a `description`.
-- If the operation **has** a `description`: do not add a `description:` field to frontmatter. If one was incorrectly added, remove it so the metadata comes from the spec.
-- If the operation **has no** `description`: audit `description` frontmatter as normal — add one if missing or fix it if it fails the quality checks.
-- If the operation defines a `summary` and the page has no `title:` frontmatter, treat the title as present — do not add one.
-- Never edit the OpenAPI spec files themselves.
-
-For pages with a **file reference**, audit all frontmatter fields as normal.
-
-Success criteria:
-- Pages have a unique title under 60 characters that describes the specific content
-- Pages have a unique description between 130 and 160 characters (except for pages where the OpenAPI spec supplies the description)
-
-## Important
-
-- Only update frontmatter. Do not change page content or OpenAPI spec files.
-- If all pages have complete and reasonable metadata, do nothing.
-```
-
-
-### 带通知的更新日志
-
-
-**Trigger:** Cron schedule `0 9 * * 1`（每周一 9:00 UTC）
-**Context repos:** `your-org/your-product`
-**Slack notifications:** `documentation` 频道，`tech-writer` 用户
-
-```text
-Review all merged PRs in `your-org/your-product` from the past week. Draft a changelog entry summarizing new features, bug fixes, and breaking changes.
-
-Success criteria: The changelog accurately reflects the week's changes and is ready for review.
-```
diff --git a/zh/optimize/search-boost.mdx b/zh/optimize/search-boost.mdx
deleted file mode 100644
index 5639b62928..0000000000
--- a/zh/optimize/search-boost.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: "搜索加权"
-description: "通过在页面 frontmatter 或 `docs.json` 导航中设置数值加权乘数，使你的文档站点内置搜索的排名向特定页面或章节倾斜。"
-keywords: ["搜索排名", "搜索加权", "加权", "搜索优先级"]
----
-
-使用 `boost` 让特定页面或章节在站内搜索中获得更高的排名权重。该值是一个应用于每个内容片段相关性得分的数值乘数：`boost: 3` 会使某个片段的相关性提升为没有加权时的三倍。
-
-`boost` 仅影响 Mintlify 托管的文档站点上的搜索栏。它不会改变外部搜索引擎对你页面的索引方式。
-
-
- ## 为单个页面加权
-
-
-在页面的 [frontmatter](/zh/organize/pages) 中设置 `boost`，可放大其搜索排名。
-
-```mdx
----
-title: "Custom domain"
-description: "Connect your custom domain to your Mintlify documentation."
-boost: 3
----
-```
-
-
- ## 为导航分组加权
-
-
-在 `docs.json` 导航中的某个分组上设置 `boost`，可将该乘数应用于其下的每个页面。
-
-```json
-{
- "navigation": {
- "groups": [
- {
- "group": "Get started",
- "boost": 5,
- "pages": [
- "quickstart",
- "concepts"
- ]
- }
- ]
- }
-}
-```
-
-页面会从最近一个设置了加权值的祖先那里继承加权因子。子页面或嵌套分组可以通过设置自己的 `boost` 值来覆盖继承的加权。页面 frontmatter 中的 `boost` 始终优先于从导航继承的值。
-
-
- ## 降低内容优先级
-
-
-使用小于 `1` 的值可将页面在搜索结果中下推。例如，`boost: 0.5` 会将页面的相关性得分相对于其他页面减半。`boost` 为 `1` 时等同于不加权。
-
-```mdx
----
-title: "Deprecated API"
-description: "Documentation for the deprecated v1 API."
-boost: 0.25
----
-```
-
-
- 加权因子会与已有的相关性得分相乘。请谨慎使用。过大的乘数会导致相关性较低的页面在搜索结果中占据主导地位，从而降低整体搜索质量。
-