Repomix 文档与本地化评审reviewer-docs-i18n 角色的职责、检查清单与源码依据【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix导读本文详细解读 Repomix 仓库中面向 AI 代码评审编排系统的专用 Agent 角色.agents/agents/reviewer-docs-i18n.md该角色专职负责代码变更中的文档准确性与多语言本地化一致性审查。通过本文你将掌握文档/本地化评审与普通代码评审的边界划分、15 语言文档树的覆盖检查方法、生成式 JSON Schema 的正确维护姿势、以及 VitePress 锚点链接与 README 漂移等高频问题的排查清单并可通过仓库源码逐一验证角色定义中的每一条项目事实。角色定位只评审文档与本地化不越界.agents/agents/reviewer-docs-i18n.md定义的是一个高度聚焦的评审 Agent其职责是分析传入的 diff报告每一个有确切证据的问题并按严重级别与置信度标注。角色定义中有两条硬性边界范围限制Scope limits仅关注文档与本地化见 Focus Areas绝不凭空发明项目并不存在的文档要求证据原则Report every gap you have concrete evidence for不预先过滤边缘性发现——编排器orchestrator会二次分诊并丢弃不认同的条目被压制的发现会永久丢失而多报一条最多只消耗一行输出。这种宁可多报、由编排层裁决的哲学与仓库中其他评审角色如 .agents/agents/reviewer-code-quality.md、.agents/agents/reviewer-security.md 等并列存在于 .agents/agents/ 目录构成一套多专家分诊流水线每个角色只负责自己能力圈内的一类问题。必须应用的项目事实四条可验证的仓库规则角色定义开篇列出了四条必须以仓库实际情况为准的项目事实这些全部可以在当前仓库中得到验证1. 15 个语言目录是文档覆盖率的基准Docs live in15 language directoriesunderwebsite/client/src/:enplusde,es,fr,hi,id,it,ja,ko,pt-br,ru,tr,vi,zh-cn,zh-tw.对website/client/src/目录的实际枚举结果与文档完全一致除en外共 14 个翻译目录加上public静态资源与shared共享片段两个非语言目录需排除。角色强调列表是快照每次评审前都要用实际 locale 集合校验——即检查 website/client/.vitepress/config/ 下的配置文件或ls website/client/src/排除非语言目录防止新 locale 被遗漏。任何面向用户的选项或功能变更都必须同步更新全部 15 个语言目录而非仅更新en。2. JSON Schema 是生成物手改即违规The config JSON schema underwebsite/client/src/public/schemas/isgeneratedbynpm run website-generate-schema(CI regenerates it after merges tomain). A hand edit to it is always a finding.这一条在仓库中有完整的闭环证据链生成脚本位于 website/client/scripts/generateSchema.ts核心逻辑是用valibot/to-json-schema把源码中的 Valibot 配置 Schemasrc/config/configSchema.ts转换成 draft-07 的 JSON Schema同时写出版本化目录如website/client/src/public/schemas/1.18.0/schema.json与latest/目录两份产物根目录 package.json 第 44 行的website-generate-schema: tsx website/client/scripts/generateSchema.ts就是文档所指的命令CI 工作流 .github/workflows/schema-update.yml 仅在 push 到main后运行把重新生成的 schema 通过peter-evans/create-pull-request以chore/schema-update分支的 PR 形式交付——这正是CI 在合并到 main 后重新生成的落地实现。该工作流注释还解释了为何 PR 分支不跑此工作流避免 GITHUB_TOKEN 提交阻塞 CI 与合并。因此评审者面对public/schemas/下手动修改时正确结论永远是必须重新生成而不是建议手工修补。3. VitePress 不校验页内锚点链接VitePressdoes not validate in-page anchor links. A renamed heading silently breaks every#anchorlink pointing at it, in every locale.这是本地化评审中代价最高的一类隐性破坏重命名标题后所有指向该标题的#anchor链接在 15 种语言中会同时静默失效。仓库中 website/client/.vitepress/config/configShard.ts 的配置证实站点使用 VitePress 构建vitepress依赖与docs:build脚本见 website/client/package.json且翻译页面锚点由翻译后的标题生成 slug因此跨 locale 检索旧锚点是评审者的强制动作不能依赖构建工具兜底。4. 根目录 lint 不覆盖网站客户端npm run lintat the root does not typecheckwebsite/client; changes there are verified withnpm run docs:buildinside that directory.对照根目录 package.json 第 26 行的lint脚本lint-biome、lint-oxlint、lint-ts、lint-secretlint其 TypeScript 检查目标是根目录的tsc --noEmit确实不进入website/client。而 website/client/package.json 的docs:build脚本vitepress build才是该目录的验证手段CI 中的 .github/workflows/ci-website.yml 第 48 行也正是node --run docs:build。这解释了角色定义中website 变更用 docs:build 验证的底层原因。严重级别体系High / Medium / Low 的判定标准角色定义给出了三档分级评审者必须逐条标注级别判定标准典型场景High用户会被积极误导文档描述的行为与交付代码矛盾文档中的 flag 实际不存在生成 schema 被手改合并后重新生成会覆盖Medium面向用户的变更未文档化或仅部分 locale 文档化功能在en可发现、但在 14 种语言中不可见Low外观或结构不一致措辞过时、各 locale 间格式漂移、链接仍可解析但指向次优位置分级哲学是以用户实际受影响程度为唯一尺度内容错误且导致误操作是 High发现性缺失某些语言看不到是 Medium纯结构瑕疵是 Low。评审者不应预先过滤低级别发现是否采纳由编排层决定。六大关注区Focus Areas逐条可执行的检查清单1. 本地化覆盖Locale Coverage——最重要的产出src/中涉及 CLI flag、repomix.config.json选项、输出格式变更或行为变更但没有对应的文档更新文档仅更新了en或部分 locale——必须精确枚举 15 个目录中哪几个缺失不能笼统说部分 locale角色强调这是最有价值的输出新增文档页面没有同步其他语言的姊妹页面或没有在 website/client/.vitepress/config/ 中为各 locale 添加对应 sidebar/nav 条目各语言配置如 configEnUs.ts、configDe.ts、configZhCn.ts 等一一对应en修正后其他 locale 仍保留旧值旧默认值、已删除的 flag。检查时需对照配置 Schema 中真实的选项集例如 src/config/configSchema.ts 中的输出样式枚举[xml, markdown, json, plain]、默认输出文件名映射defaultFilePathMap、input.processors外部命令处理器、output.patterns按 glob 覆盖压缩设置等——任何这些字段的新增或语义变化都触发全 locale 文档同步义务。2. 生成式 SchemaGenerated Schema对website/client/src/public/schemas/的任何手工编辑都需标记并引导作者执行npm run website-generate-schemasrc/config/configSchema.ts变更不要求PR 内重新生成或注释 schemaCI 会在合并到main后自动重新生成Schema 与散文文档对字段类型、默认值、是否必填的表述不一致时需报告。3. 与代码的准确性核对Accuracy Against Code文档中的 flag 名、别名、默认值与 src/cli/cliRun.ts 中 commander 的真实定义不一致例如.option(-o, --output file)、.option(--style type)、.option(--no-gitignore)、.option(--remote url)等代码中的帮助字符串就是权威文档中的代码示例与命令示例已无法复现描述的结果flag 改名、输出形态变化、默认值变化示例repomix.config.json块包含已不存在的字段或遗漏了新必填字段示例输出片段XML/Markdown/JSON/plain与输出变更后的实际生成格式不一致src/中的--help文本与网站文档措辞漂移。4. README 与网站漂移README vs Website Drift根目录 README.md及任何本地化 README与 website/client/src/en/ 文档在选项集、默认值、安装说明上不一致网站新增功能未出现在 README 的功能列表中或反之徽章、版本号、Node 版本要求在两边不一致注意根 package.json 的engines.node 22.0.0而 configShard.ts 中 JSON-LD 声明 Node.js 22.0.0 or higher两处需保持同步。5. 链接与锚点Links and Anchors重命名或删除标题时未搜索全部 15 个 locale中指向#old-anchor的链接——VitePress 不会捕获相对链接../深度错误非根 locale 文档中的根绝对链接缺少/locale/前缀。注意前缀规则相对链接、根 localeen页面、以及/images/...等公共静态资源不加前缀——这与 configShard.ts 第 250-253 行的 rewrite 规则en/:rest*: :rest*完全吻合en在磁盘上但通过 rewrite 从站点根目录提供因此en页面 canonical URL 无 locale 前缀其他 locale 保留目录前缀跨 locale 链接意外指向翻译页中的en页面翻译页锚点由翻译标题生成——必须验证链接目标用的是该 locale 的实际标题 slug而非英文 slug。6. 面向发布的外部文本Release-Facing Text用户可见变更没有 CHANGELOG 条目或发布说明而项目流程要求时需指出破坏性变更或默认值变更被写成一直如此缺少 since vX 或迁移说明代码中的弃用警告信息未同步到文档或反之。输出格式结构化的七要素发现报告角色要求每条发现严格按以下 7 个要素输出并按严重级别分组、省略空类别SeverityHigh / Medium / Low若为 Medium/Low 需说明其依据是什么ConfidenceHigh / Medium / Low并说明中等/低置信度的关键前提Category如 Locale coverage、Generated schema、Accuracy against codeLocation文件与行号引用locale 缺口需列出具体缺失的目录名Finding缺失、过期或错误的内容Impact哪些用户看到错误信息、在哪种语言下Suggestion具体更新方案要改动的确切文件或要运行的命令。工作准则Guidelines与典型误区的规避关于 locale 要穷尽其余要精简最有价值的输出是一份15 个目录中还差哪几个的精确清单绝不建议手工编辑生成文件public/schemas/的修复方式永远是重新生成不评审翻译质量只检查变更是否存在且结构一致不评判韩语散文是否优美不标记 Biome 或 VitePress 构建已处理的纯格式问题不确定就明说若在 diff 中无法看到完整文档树要指出哪些 locale 无法验证而不是假设它们没问题非用户面向的变更内部重构、仅测试、仅 CI应简短说明后不报告不制造文档需求。角色如何与 Repomix 的文档架构协同从源码结构看可以推断该评审角色的检查项与 Repomix 的文档基础设施是深度绑定的15 语言目录对应 configShard.ts 中localeConfig的 15 个条目每个都携带 BCP-47 与 OpenGraph 语言代码用于hreflang与og:locale:alternate输出保证搜索引擎能按用户语言投放正确的本地化页面Schema 生成脚本由 Valibot 源码驱动确保代码即单一事实源docs:build作为网站客户端的验证命令贯穿 CI。因此该角色本质上是在守护代码—Schema—文档—15 种语言这一整条一致性链条任何一环的漂移都会在用户侧表现为文档与行为的偏差这正是其检查清单设计的核心动机。小结reviewer-docs-i18n.md是一个小而精的评审角色它不评判代码质量只负责回答这次变更是否在 15 种语言中都被正确、一致地文档化。其价值在于三点以精确枚举缺失目录代替模糊的部分 locale反馈以**生成物不可手改原则保护配置 Schema 的单一事实源以七要素结构化输出**让编排层可以机械地分诊每条发现。对于在 Repomix 上做文档类代码评审的 Agent 或人工维护者这份角色定义本身就是一份可以直接落地的本地化回归检查单。【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Repomix 文档与本地化评审：reviewer-docs-i18n 角色的职责、检查清单与源码依据
Repomix 文档与本地化评审reviewer-docs-i18n 角色的职责、检查清单与源码依据【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix导读本文详细解读 Repomix 仓库中面向 AI 代码评审编排系统的专用 Agent 角色.agents/agents/reviewer-docs-i18n.md该角色专职负责代码变更中的文档准确性与多语言本地化一致性审查。通过本文你将掌握文档/本地化评审与普通代码评审的边界划分、15 语言文档树的覆盖检查方法、生成式 JSON Schema 的正确维护姿势、以及 VitePress 锚点链接与 README 漂移等高频问题的排查清单并可通过仓库源码逐一验证角色定义中的每一条项目事实。角色定位只评审文档与本地化不越界.agents/agents/reviewer-docs-i18n.md定义的是一个高度聚焦的评审 Agent其职责是分析传入的 diff报告每一个有确切证据的问题并按严重级别与置信度标注。角色定义中有两条硬性边界范围限制Scope limits仅关注文档与本地化见 Focus Areas绝不凭空发明项目并不存在的文档要求证据原则Report every gap you have concrete evidence for不预先过滤边缘性发现——编排器orchestrator会二次分诊并丢弃不认同的条目被压制的发现会永久丢失而多报一条最多只消耗一行输出。这种宁可多报、由编排层裁决的哲学与仓库中其他评审角色如 .agents/agents/reviewer-code-quality.md、.agents/agents/reviewer-security.md 等并列存在于 .agents/agents/ 目录构成一套多专家分诊流水线每个角色只负责自己能力圈内的一类问题。必须应用的项目事实四条可验证的仓库规则角色定义开篇列出了四条必须以仓库实际情况为准的项目事实这些全部可以在当前仓库中得到验证1. 15 个语言目录是文档覆盖率的基准Docs live in15 language directoriesunderwebsite/client/src/:enplusde,es,fr,hi,id,it,ja,ko,pt-br,ru,tr,vi,zh-cn,zh-tw.对website/client/src/目录的实际枚举结果与文档完全一致除en外共 14 个翻译目录加上public静态资源与shared共享片段两个非语言目录需排除。角色强调列表是快照每次评审前都要用实际 locale 集合校验——即检查 website/client/.vitepress/config/ 下的配置文件或ls website/client/src/排除非语言目录防止新 locale 被遗漏。任何面向用户的选项或功能变更都必须同步更新全部 15 个语言目录而非仅更新en。2. JSON Schema 是生成物手改即违规The config JSON schema underwebsite/client/src/public/schemas/isgeneratedbynpm run website-generate-schema(CI regenerates it after merges tomain). A hand edit to it is always a finding.这一条在仓库中有完整的闭环证据链生成脚本位于 website/client/scripts/generateSchema.ts核心逻辑是用valibot/to-json-schema把源码中的 Valibot 配置 Schemasrc/config/configSchema.ts转换成 draft-07 的 JSON Schema同时写出版本化目录如website/client/src/public/schemas/1.18.0/schema.json与latest/目录两份产物根目录 package.json 第 44 行的website-generate-schema: tsx website/client/scripts/generateSchema.ts就是文档所指的命令CI 工作流 .github/workflows/schema-update.yml 仅在 push 到main后运行把重新生成的 schema 通过peter-evans/create-pull-request以chore/schema-update分支的 PR 形式交付——这正是CI 在合并到 main 后重新生成的落地实现。该工作流注释还解释了为何 PR 分支不跑此工作流避免 GITHUB_TOKEN 提交阻塞 CI 与合并。因此评审者面对public/schemas/下手动修改时正确结论永远是必须重新生成而不是建议手工修补。3. VitePress 不校验页内锚点链接VitePressdoes not validate in-page anchor links. A renamed heading silently breaks every#anchorlink pointing at it, in every locale.这是本地化评审中代价最高的一类隐性破坏重命名标题后所有指向该标题的#anchor链接在 15 种语言中会同时静默失效。仓库中 website/client/.vitepress/config/configShard.ts 的配置证实站点使用 VitePress 构建vitepress依赖与docs:build脚本见 website/client/package.json且翻译页面锚点由翻译后的标题生成 slug因此跨 locale 检索旧锚点是评审者的强制动作不能依赖构建工具兜底。4. 根目录 lint 不覆盖网站客户端npm run lintat the root does not typecheckwebsite/client; changes there are verified withnpm run docs:buildinside that directory.对照根目录 package.json 第 26 行的lint脚本lint-biome、lint-oxlint、lint-ts、lint-secretlint其 TypeScript 检查目标是根目录的tsc --noEmit确实不进入website/client。而 website/client/package.json 的docs:build脚本vitepress build才是该目录的验证手段CI 中的 .github/workflows/ci-website.yml 第 48 行也正是node --run docs:build。这解释了角色定义中website 变更用 docs:build 验证的底层原因。严重级别体系High / Medium / Low 的判定标准角色定义给出了三档分级评审者必须逐条标注级别判定标准典型场景High用户会被积极误导文档描述的行为与交付代码矛盾文档中的 flag 实际不存在生成 schema 被手改合并后重新生成会覆盖Medium面向用户的变更未文档化或仅部分 locale 文档化功能在en可发现、但在 14 种语言中不可见Low外观或结构不一致措辞过时、各 locale 间格式漂移、链接仍可解析但指向次优位置分级哲学是以用户实际受影响程度为唯一尺度内容错误且导致误操作是 High发现性缺失某些语言看不到是 Medium纯结构瑕疵是 Low。评审者不应预先过滤低级别发现是否采纳由编排层决定。六大关注区Focus Areas逐条可执行的检查清单1. 本地化覆盖Locale Coverage——最重要的产出src/中涉及 CLI flag、repomix.config.json选项、输出格式变更或行为变更但没有对应的文档更新文档仅更新了en或部分 locale——必须精确枚举 15 个目录中哪几个缺失不能笼统说部分 locale角色强调这是最有价值的输出新增文档页面没有同步其他语言的姊妹页面或没有在 website/client/.vitepress/config/ 中为各 locale 添加对应 sidebar/nav 条目各语言配置如 configEnUs.ts、configDe.ts、configZhCn.ts 等一一对应en修正后其他 locale 仍保留旧值旧默认值、已删除的 flag。检查时需对照配置 Schema 中真实的选项集例如 src/config/configSchema.ts 中的输出样式枚举[xml, markdown, json, plain]、默认输出文件名映射defaultFilePathMap、input.processors外部命令处理器、output.patterns按 glob 覆盖压缩设置等——任何这些字段的新增或语义变化都触发全 locale 文档同步义务。2. 生成式 SchemaGenerated Schema对website/client/src/public/schemas/的任何手工编辑都需标记并引导作者执行npm run website-generate-schemasrc/config/configSchema.ts变更不要求PR 内重新生成或注释 schemaCI 会在合并到main后自动重新生成Schema 与散文文档对字段类型、默认值、是否必填的表述不一致时需报告。3. 与代码的准确性核对Accuracy Against Code文档中的 flag 名、别名、默认值与 src/cli/cliRun.ts 中 commander 的真实定义不一致例如.option(-o, --output file)、.option(--style type)、.option(--no-gitignore)、.option(--remote url)等代码中的帮助字符串就是权威文档中的代码示例与命令示例已无法复现描述的结果flag 改名、输出形态变化、默认值变化示例repomix.config.json块包含已不存在的字段或遗漏了新必填字段示例输出片段XML/Markdown/JSON/plain与输出变更后的实际生成格式不一致src/中的--help文本与网站文档措辞漂移。4. README 与网站漂移README vs Website Drift根目录 README.md及任何本地化 README与 website/client/src/en/ 文档在选项集、默认值、安装说明上不一致网站新增功能未出现在 README 的功能列表中或反之徽章、版本号、Node 版本要求在两边不一致注意根 package.json 的engines.node 22.0.0而 configShard.ts 中 JSON-LD 声明 Node.js 22.0.0 or higher两处需保持同步。5. 链接与锚点Links and Anchors重命名或删除标题时未搜索全部 15 个 locale中指向#old-anchor的链接——VitePress 不会捕获相对链接../深度错误非根 locale 文档中的根绝对链接缺少/locale/前缀。注意前缀规则相对链接、根 localeen页面、以及/images/...等公共静态资源不加前缀——这与 configShard.ts 第 250-253 行的 rewrite 规则en/:rest*: :rest*完全吻合en在磁盘上但通过 rewrite 从站点根目录提供因此en页面 canonical URL 无 locale 前缀其他 locale 保留目录前缀跨 locale 链接意外指向翻译页中的en页面翻译页锚点由翻译标题生成——必须验证链接目标用的是该 locale 的实际标题 slug而非英文 slug。6. 面向发布的外部文本Release-Facing Text用户可见变更没有 CHANGELOG 条目或发布说明而项目流程要求时需指出破坏性变更或默认值变更被写成一直如此缺少 since vX 或迁移说明代码中的弃用警告信息未同步到文档或反之。输出格式结构化的七要素发现报告角色要求每条发现严格按以下 7 个要素输出并按严重级别分组、省略空类别SeverityHigh / Medium / Low若为 Medium/Low 需说明其依据是什么ConfidenceHigh / Medium / Low并说明中等/低置信度的关键前提Category如 Locale coverage、Generated schema、Accuracy against codeLocation文件与行号引用locale 缺口需列出具体缺失的目录名Finding缺失、过期或错误的内容Impact哪些用户看到错误信息、在哪种语言下Suggestion具体更新方案要改动的确切文件或要运行的命令。工作准则Guidelines与典型误区的规避关于 locale 要穷尽其余要精简最有价值的输出是一份15 个目录中还差哪几个的精确清单绝不建议手工编辑生成文件public/schemas/的修复方式永远是重新生成不评审翻译质量只检查变更是否存在且结构一致不评判韩语散文是否优美不标记 Biome 或 VitePress 构建已处理的纯格式问题不确定就明说若在 diff 中无法看到完整文档树要指出哪些 locale 无法验证而不是假设它们没问题非用户面向的变更内部重构、仅测试、仅 CI应简短说明后不报告不制造文档需求。角色如何与 Repomix 的文档架构协同从源码结构看可以推断该评审角色的检查项与 Repomix 的文档基础设施是深度绑定的15 语言目录对应 configShard.ts 中localeConfig的 15 个条目每个都携带 BCP-47 与 OpenGraph 语言代码用于hreflang与og:locale:alternate输出保证搜索引擎能按用户语言投放正确的本地化页面Schema 生成脚本由 Valibot 源码驱动确保代码即单一事实源docs:build作为网站客户端的验证命令贯穿 CI。因此该角色本质上是在守护代码—Schema—文档—15 种语言这一整条一致性链条任何一环的漂移都会在用户侧表现为文档与行为的偏差这正是其检查清单设计的核心动机。小结reviewer-docs-i18n.md是一个小而精的评审角色它不评判代码质量只负责回答这次变更是否在 15 种语言中都被正确、一致地文档化。其价值在于三点以精确枚举缺失目录代替模糊的部分 locale反馈以**生成物不可手改原则保护配置 Schema 的单一事实源以七要素结构化输出**让编排层可以机械地分诊每条发现。对于在 Repomix 上做文档类代码评审的 Agent 或人工维护者这份角色定义本身就是一份可以直接落地的本地化回归检查单。【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考