工作流目前处于测试阶段。如需启用，请直接联系我们。
.mintlify/workflows/ 目录中创建 .md 文件。每个文件定义一个工作流。
工作流文件使用 YAML frontmatter 来配置工作流，后面跟一段提供给智能助手的 Markdown 提示词。
.mintlify/workflows/update-changelog.md
---
name: Update changelog
on:
cron: "0 9 * * 1"
context:
- repo: your-org/your-product
automerge: false
---
Review all changes since the last changelog update. Draft a new changelog post with any new features, bug fixes, or breaking changes.
Include information about what a change is and how it affects users.
Do not include any internal-only information or minor changes like bumping package versions or updating documentation.
Success criteria: Someone who reads the changelog knows the most up to date information about the product including what changed and whether or not it affects them.
| 字段 | 必填 | 说明 |
|---|
name | 是 | 在控制台中显示的名称。 |
on | 是 | 触发配置。 |
context | 否 | 在工作流运行时会被克隆作为参考的存储库。 |
automerge | 否 | 默认为 false，此时会打开一个拉取请求（PR；亦称“合并请求”/Merge Request）。如果为 true，则会将更改直接推送到你的部署用分支。 |
context 或 on.push.repo 字段中列出的每个存储库上安装 Mintlify GitHub 应用。请在 Mintlify 控制台的 GitHub 应用 页面添加新的存储库。
每个工作流必须在 on 字段中只定义一个触发器。
使用 cron 表达式按固定计划运行工作流。所有计划均使用 UTC 时间运行。
工作流会在预定时间起的 10 分钟内进入队列，并且可能最多需要 10 分钟才能开始运行。
该值是一个标准的 5 个字段的 cron 表达式，格式为 minute hour day-of-month month day-of-week。可以使用类似 crontab.guru 这样的工具来构建和验证调度计划。
| Expression | Schedule |
|---|
"0 9 * * 1" | 每周一 9:00（UTC） |
"0 0 1 * *" | 每个月第一天的 00:00（UTC，午夜） |
"0 8 * * 1-5" | 每个工作日 8:00（UTC） |
on:
push:
- repo: your-org/your-product
branch: main
repo: 以 owner/repo 格式指定的 GitHub 存储库。branch（可选）：要监控合并的 branch。如果你未指定 branch，则工作流会在更改合并到存储库默认 branch 时触发。
一个工作流可以监控多个存储库或多个 branch 上的合并。
on:
push:
- repo: your-org/your-product
- repo: your-org/another-repo
branch: release
context 在工作流运行时为代理程序提供对其他存储库的只读访问权限。当你的提示词需要查看文档存储库之外的代码或内容时，这会很有用。
context:
- repo: your-org/your-product
- repo: your-org/design-system
automerge 设置为 true，即可在不创建拉取请求的情况下，直接将更改推送到你的部署用分支。
有效的提示词会专注于单一任务，并有清晰的预期结果。由于 Agent 的非确定性特性，工作流总会存在一定差异，但你可以通过遵循以下最佳实践来提高工作流输出的一致性。
- 描述你希望 Agent 达成的结果。
- 包含衡量成功的标准。
- 指定你希望 Agent 使用的 context。
- 将复杂任务拆分为步骤或多个工作流。
在文档拉取请求（PR；亦称“合并请求”/Merge Request）合并时运行，用于在问题累积之前发现违反样式指南的情况。此示例工作流会自动修复样式指南违规，并在 PR 正文中列出所有仍需人工判断的违规项。
.mintlify/workflows/style-audit.md
---
name: Style audit
on:
push:
- repo: your-org/your-docs
branch: main
automerge: false
---
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/`).
.mintlify/workflows/draft-feature-docs.md
---
name: Draft docs for new features
on:
push:
- repo: your-org/your-product
branch: main
context:
- repo: your-org/your-docs
automerge: false
---
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.
.mintlify/workflows/update-api-reference.md
---
name: Update API reference
on:
push:
- repo: your-org/your-product
branch: main
context:
- repo: your-org/your-docs
automerge: false
---
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.
es/、fr/、zh/）更新为你实际使用的语言子目录。
.mintlify/workflows/translation-lag.md
---
name: 跟踪翻译滞后情况
on:
cron: "0 9 * * 3"
---
将仓库中的英文 MDX 文件与 `es/`、`fr/` 和 `zh/` 子目录中对应的翻译文件进行比较。使用 git 历史记录找出比其翻译版本更新的英文文件。
提交一个拉取请求（PR），列出未同步的页面，并按语言分类整理。对于每个页面，注明最后一次英文更新的日期，以及变更内容的简要说明，以便译者了解需要更新的内容。
成功标准：英文文件与翻译文件之间的所有差异均已识别并列于拉取请求（PR）中。
## 重要说明
- 如果翻译文件不存在，将其标记为缺失，而非未同步。
- 按语言对结果进行分组，再按滞后程度排序（最陈旧的排在最前面）。
description frontmatter 的页面。编辑该工作流，以检查你在文档中优先关注的其他 metadata 或内容相关问题。
.mintlify/workflows/seo-audit.md
---
name: SEO and metadata audit
on:
cron: "0 9 * * 1"
automerge: false
---
Audit all MDX files in the docs for SEO and metadata quality. Check for:
- Missing or empty `description` frontmatter
- Descriptions that are too short (under 50 characters) or too long (over 160 characters)
Open a pull request with improvements for any issues found. Write descriptions that accurately summarize the page content in plain language.
Success criteria: All pages have up to date descriptions that accurately summarize the page content in plain language.
## Important
- Only update frontmatter. Do not change page content.
- If all pages have complete and reasonable metadata, do nothing.
