用途：统一该仓库内所有散文类技术文字的写作风格，适用于 Mintlify 文档页、OpenAPI 字段与端点描述、变更日志、README、PR 描述与评审意见。规则以 Google 开发者文档风格指南为基础并做了精简。限制：mintlify/legal/ 下的页面是法务提供的原文，不要改写，只能按指示逐字修改。
句子与用词：用主动语态并点明动作执行者，例如写 Grid retries the payout，而非被动式；当执行者无关时可用被动，例如 the quote expires after 30 seconds。指令用第二人称 you，不用 we 或 the user。用现在时。先写条件再写指令，链接同样如此，例如 For supported currencies, see X。一句一个意思，句子短但完整，不用碎片句。说过一次就停，删掉重复上句的句子。用平实词汇，直接点名端点、字段、状态、错误码或币种，不写 the system 或 the workflow。指令中不用 simply、just、easy、quickly；不用 please note、at this time、it's worth noting、keep in mind 等填充语；不用比喻和流行文化引用；术语只引入一次并保持一致，不轮换同义词。
格式：标题与各级标题用句首大写。只有有序步骤用编号列表，其余用项目符号，每条只写一个具体行为。使用连续逗号。端点、字段、值与命令用代码字体，界面元素用粗体。链接文字描述目标，例如 see the quote lifecycle，不用 click here 或裸 here。日期写明确，如 2026-08-19 或 August 19, 2026。不用感叹号，不用破折号，改用逗号、句号、括号或重组句子。
内容：面向没参加本次工作会话的读者，不用草稿中自造的简写或代号，把发生的事写清楚。不要记录未发布或未来的行为，只描述 API 今天的行为。在代码块中粘贴真实请求、响应体和错误负载，不要转述 API 返回内容。直接陈述取舍，说明选 X 而非 Y 是因为 Z，不模糊、不推销。结构跟随内容，确实有多个条目时才加标题或列表。先给结论或变更，再写背景。不写复述本页内容的摘要或结论段。
PR 描述与评审意见：PR 描述用完整句子说明改了什么和为什么，每条一个行为；测试计划写实际运行了什么。评审意见先点明要点，如 nit:、question:，并引用具体行或输出；每条评论只提一个问题；若作者可能知道你不知道的信息，用提问方式给出建议。
去 AI 化检查（每次草稿最后执行）：不用 AI 行话或宏大框架，如 first-class、end-to-end、robust、seamless、leverage、holistic、comprehensive、battle-tested；不用为效果而写的短促碎片句，如 No more X.、The result? Y.、Simple.；不用 It's not X, it's Y 句式、反问句或三连排比；如果一句话能作为产品博客开头，改写成事实陈述。