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在大型开源项目中命名风格、模块组织、API 设计等软性约定往往无法被 lint 工具强制约束却又直接影响代码库的长期可维护性。Repomix 仓库在其多 Agent 审查体系中内置了一名专职的约定审查者conventions reviewer它以 reviewer-conventions.md 为角色定义专门负责发现 linter 抓不到的语义不一致。本文以这份角色文档为主体结合 Repomix 仓库中真实的项目规则.agents/rules/base.md、审查编排命令review-loop.md与 pr-review.md完整解析约定审查者的方法论、输出规范与落地实践。读完本文你将掌握一套可复制的发现约定 → 检查语义一致性 → 权衡改进 → 输出分级报告审查流程并能直接套用到自己项目的 Agent 审查体系设计中。一、背景Repomix 的多 Agent 代码审查体系Repomix 是一个将整个代码仓库打包为单一 AI 友好文件的工具支持 XML、Markdown、JSON 与纯文本输出格式。其.agents/目录下搭建了一套完整的 Agent 化开发协作体系其中审查review环节采用多审查者并行 编排者过滤的架构。从 .agents/commands/code/review-loop.md 可以看到审查循环的核心流程对当前分支相对main的变更并行启动 6 个专职审查者 Agent最多迭代 3 轮reviewer-code-quality代码质量reviewer-security安全reviewer-performance性能reviewer-test-coverage测试覆盖reviewer-conventions约定一致性reviewer-holistic整体影响而在 pr-review.md 的 PR 审查场景中审查者列表进一步扩展为 8 名并给出了按变更内容选择审查者的映射规则其中约定审查者的触发条件是新文件、新增/重命名 API、或结构性变更new files, new/renamed APIs, or structural changes且明确要求拿不准就启动该 Agentwhen in doubt, spawn the agent。所有审查者遵循同一条设计哲学不做预先过滤报告每一条有证据支撑的发现并标注严重度severity与置信度confidence。编排者orchestrator才是过滤器——被压制的发现会丢失而被拒绝的发现只是多花一行代价。这条原则决定了约定审查者的报告策略宁可多报不可漏报。二、约定审查者的角色定位与职责边界reviewer-conventions.md 在 frontmatter 中明确了角色属性model: sonnet职责描述为Review code changes for adherence to project conventions, naming, and structure审查代码变更对项目约定、命名与结构的遵守情况。该角色的核心定义包含三点范围限制仍然适用引用的每一条约定都必须在项目中真实存在见下文发现约定绝不发明约定聚焦自动化工具抓不到的问题语义一致性、架构模式、API 设计连贯性、命名清晰度与兄弟审查者互补代码质量审查者负责 bug 与逻辑错误安全审查者负责注入与路径穿越等漏洞而约定审查者专司规范符合度。与 linter 的分工边界biome.json 表明 Repomix 使用 Biome 作为代码风格与格式检查工具。约定审查者的第一条准则是只标记 linter 抓不到的问题——格式化、导入排序、分号、缩进等都属于 linter 的领地一律不重复报告。这条边界保证了审查产出全部落在格式正确但语义不一致的空白地带。与兄弟审查者的分工.agents/agents/reviewer-holistic.md 明确列出了各审查者的领地划分代码风格、命名、目录结构、提交格式归约定审查者bug、逻辑错误、类型安全归代码质量审查者注入、密钥、输入校验归安全审查者。约定审查者不得重复报告其他审查角度的发现。三、审查方法论三步走第一步发现约定Discover Conventions在标记偏差之前必须先建立基线baseline。文档给出了三条证据获取路径读取项目规则文件.agents/rules/、CLAUDE.md、CONTRIBUTING.md等文件中的显式约定。Repomix 的 .agents/rules/base.md 正是这类规则的典型——它规定了仓库布局src/、tests/、website/、browser/的职责划分、编码规范、提交信息格式与 PR 指南考察同一模块/功能区域的现有代码寻找隐式模式implicit patterns记录项目的依赖注入模式、错误处理风格、文件组织与命名习惯。以 Repomix 为例base.md 中有一条极具项目特色的依赖注入约定依赖必须通过deps对象参数注入以便测试。规则文件给出了标准写法export const functionName async ( param1: Type1, param2: Type2, deps { defaultFunction1, defaultFunction2, } ) { // Use deps.defaultFunction1() instead of direct call };并配套两条测试约定通过deps对象传入测试替身test doubles进行 mock仅当依赖注入不可行时才使用vi.mock()。约定审查者在检查新增代码时就可以据此核对新功能是否沿用了deps注入模式还是引入了直接调用依赖的反模式。第二步检查语义一致性Check Semantic Consistency这是方法论的核心文档将其细分为五个检查维度1. 命名清晰度Naming clarity——超越 linter 的命名检查名称是否准确描述代码行为例如一个名为getUser却可能返回null的函数应当改为findUser或让返回类型显式可空相似概念是否命名一致不要在不同模块间混用remove/delete/destroy表示同一操作布尔命名是否自然可读应当使用isValid、hasPermission、shouldRetry而非valid、permission、retry缩写是否与既有代码一致若代码库用config就不要引入cfg。2. API 设计一致性API design consistency新函数是否遵循既有参数顺序约定错误上报风格是否一致throw 与返回 null 与 Result 类型不混用新选项/配置是否与既有项保持相同的结构与命名3. 结构模式Structural patterns变更是否符合项目的模块组织模式新文件是否放在合适的 feature 目录文件大小是否超出项目限制Repomix 的 base.md 对此有明确规定以约 250 行为关注信号——当文件混杂多项职责时才拆分若长度来自单一内聚关注点如大型数据/配置表则保持原样新依赖是否遵循依赖注入模式4. 文档准确性Documentation accuracyJSDoc 注释、函数描述、行内注释在变更后是否仍与代码匹配param、returns、throws注解对已变更签名是否仍然准确README 章节或帮助文本是否描述了已改变的行为标记过时注释——那些描述代码过去行为而非现在行为的注释。5. 导出与公共 API 一致性Export and public API consistency新导出是否遵循既有命名与分组模式新增模块时 barrel 文件index.ts是否一致更新可见性级别是否合适不应导出本应内部使用的成员第三步权衡一致性与改进Consistency vs Improvement Tension方法论中一个值得注意的辩证视角并非所有偏差都是缺陷。当一个变更引入了明显比既有约定更好的模式时将其标记为讨论点discussion而非缺陷deviation注明这偏离了既有模式 X。如果这是有意为之且团队更偏好新方案考虑更新约定并迁移既有代码以保持一致。不要因一个内部自洽的风格改进而阻塞 PR。这条规则让审查者在维持一致性与拥抱进步之间取得平衡避免审查沦为对创新的压制。四、输出格式结构化的分级报告reviewer-conventions.md 为每条发现规定了七字段的规范化输出格式这也是编排者进行 triage分流的数据基础字段说明Typedeviation破坏既有约定或discussion更好但当前不一致SeverityHigh / Medium / Low按影响权重评级ConfidenceHigh / Medium / Low——并说明 Medium/Low 的置信度取决于什么Convention受影响的具体约定注明来源规则文件或模块 X 中的既有模式Location文件与行号引用Finding不一致的具体描述Suggestion如何对齐或说明为何值得更新约定配合 review-loop.md 中的编排逻辑这些报告会经过编排者二次过滤保留低置信度/低严重度的发现需编排者亲自对照代码确认幸存者再分类为Fix明确缺陷必须修复或Skip风格、吹毛求疵、范围蔓延。这种审查者全量上报、编排者过滤的二级漏斗结构最大化避免了漏报。五、指导原则让报告可信、可执行文档最后给出了六条操作准则它们是约定审查者保持专业水准的关键只标记 linter 遗漏的问题——格式化、导入排序、分号、缩进归 linter约定必须有证据——不发明项目中不存在的约定注明约定来源每条偏差记一条而非每处出现记一条——若变更相对代码库其余部分采用了不同模式这值得一条记录而不是每个文件/每行各记一条按影响加权——不一致的错误处理 不一致的公共 API 不一致的命名 不一致的文件组织 不一致的注释风格提交与 PR 约定检查——若项目有显式提交信息或 PR 约定如 Conventional Commits、必需的 scope当 diff 包含提交时应检查其符合度。Repomix 的 base.md 正要求提交信息遵循 Conventional Commits 格式type(scope): Description例如feat(cli): Add new --no-progress flag并对 scope 与 Description 的大小写有明确要求变更与约定高度一致时应简要说明——不要为了凑数而发明偏差。六、在 Repomix 仓库中的真实落地约定审查者并非纸上谈兵其背后有 Repomix 项目真实的、可对照的约定体系。以下是从 .agents/rules/base.md 中提炼的、约定审查者在 Repomix 中会实际核对的清单编码规范遵循biome.json强制的代码标准npm run lint与npm run test是提交前验证命令文件内聚性约 250 行为信号但仅在混杂多职责时拆分注释语言非显而易见的逻辑用英语注释测试配套新功能必须提供对应单元测试依赖注入通过deps对象注入依赖见上文代码示例vi.mock()仅作最后手段约定陷阱website/client/src/public/schemas/下的 JSON schema 是自动生成的npm run website-generate-schema严禁手工编辑面向用户的选项变更必须同步更新 15 种语言的文档目录website/client/src/下en加 14 个翻译 locale根目录npm run lint不检查 website client 的类型需在website/client目录下用npm run docs:build验证GitHub Actions 步骤必须固定到完整 commit SHA 并附版本注释提交信息Conventional Commits 加 scopePR 指南遵循 pull_request_template 对应模板引用 issue 使用#issue-number将同区域小变更合并为一个 PR。约定审查者正是拿着这样一份约定基线再叠加从模块现有代码中提炼的隐式模式才能对 diff 做出有证据支撑的一致性判断。反过来Repomix 的src/源码中大量出现的deps { ... }注入写法如 configLoad.ts、fileCollect.ts也印证了这些约定是真实执行、而非停留在文档层面的。七、延伸约定审查在完整工作流中的位置约定审查者只是多 Agent 审查体系中的一环。从 review-loop.md 与 pr-review.md 可以看到完整闭环日常审查循环review-loop并行启动 6 个审查者 → 编排者 triage保留值得注意的发现分 Fix/Skip→ 只修 Fix 项 →npm run lint与npm run test验证 → 仅对新改动行重新审查 → 无 Fix 项或达 3 轮后停止输出修复/跳过摘要。PR 审查pr-review先gh pr diff浏览 diff再按变更内容启动相关审查者约定审查者聚焦新文件、新/重命名 API、结构性变更。此外还会对既有 AI bot如gemini-code-assist[bot]、coderabbitai[bot]的行内评论进行优先级评判Required / Recommended / Not needed并回复降低维护者的认知负担。值得注意的是审查者的职责还有横向扩展同目录下的 reviewer-cross-platform.md 专注 Windows/macOS/Linux 的路径分隔符、glob 反斜杠转义等平台陷阱该文档甚至引用了 Repomix 历史上真实的 Windows 专属 bug——globby在.gitignore规则含反斜杠时崩溃的 issue #1765说明这套审查体系在约定之外还以同样严谨的结构覆盖了跨平台、性能、安全、测试覆盖等多个专业维度。约定审查者的方法论——发现基线、逐维度核对、分级上报、证据驱动——正是这一整套体系得以运转的通用范式。八、总结Repomix 的约定审查者角色文档展示了一套完整的语义级规范审查方法论先通过规则文件与现有代码建立约定基线再沿命名、API 设计、结构、文档、导出五个维度逐项核对用deviation/discussion区分破坏约定与值得讨论的改进最后以七字段结构化格式输出、交由编排者分流。其核心原则——只标记 linter 抓不到的、每条约定必须有证据、按影响加权、不发明偏差——保证了审查产出兼具广度与可信度。对于希望为自身项目搭建 Agent 审查体系的团队这份角色文档连同.agents/agents/下的其余七份审查者定义与 base.md 的项目规则就是一份可直接参照的完整模板。【免费下载链接】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 代码约定审查 Agent 实战指南：构建语义级规范一致性审查体系
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在大型开源项目中命名风格、模块组织、API 设计等软性约定往往无法被 lint 工具强制约束却又直接影响代码库的长期可维护性。Repomix 仓库在其多 Agent 审查体系中内置了一名专职的约定审查者conventions reviewer它以 reviewer-conventions.md 为角色定义专门负责发现 linter 抓不到的语义不一致。本文以这份角色文档为主体结合 Repomix 仓库中真实的项目规则.agents/rules/base.md、审查编排命令review-loop.md与 pr-review.md完整解析约定审查者的方法论、输出规范与落地实践。读完本文你将掌握一套可复制的发现约定 → 检查语义一致性 → 权衡改进 → 输出分级报告审查流程并能直接套用到自己项目的 Agent 审查体系设计中。一、背景Repomix 的多 Agent 代码审查体系Repomix 是一个将整个代码仓库打包为单一 AI 友好文件的工具支持 XML、Markdown、JSON 与纯文本输出格式。其.agents/目录下搭建了一套完整的 Agent 化开发协作体系其中审查review环节采用多审查者并行 编排者过滤的架构。从 .agents/commands/code/review-loop.md 可以看到审查循环的核心流程对当前分支相对main的变更并行启动 6 个专职审查者 Agent最多迭代 3 轮reviewer-code-quality代码质量reviewer-security安全reviewer-performance性能reviewer-test-coverage测试覆盖reviewer-conventions约定一致性reviewer-holistic整体影响而在 pr-review.md 的 PR 审查场景中审查者列表进一步扩展为 8 名并给出了按变更内容选择审查者的映射规则其中约定审查者的触发条件是新文件、新增/重命名 API、或结构性变更new files, new/renamed APIs, or structural changes且明确要求拿不准就启动该 Agentwhen in doubt, spawn the agent。所有审查者遵循同一条设计哲学不做预先过滤报告每一条有证据支撑的发现并标注严重度severity与置信度confidence。编排者orchestrator才是过滤器——被压制的发现会丢失而被拒绝的发现只是多花一行代价。这条原则决定了约定审查者的报告策略宁可多报不可漏报。二、约定审查者的角色定位与职责边界reviewer-conventions.md 在 frontmatter 中明确了角色属性model: sonnet职责描述为Review code changes for adherence to project conventions, naming, and structure审查代码变更对项目约定、命名与结构的遵守情况。该角色的核心定义包含三点范围限制仍然适用引用的每一条约定都必须在项目中真实存在见下文发现约定绝不发明约定聚焦自动化工具抓不到的问题语义一致性、架构模式、API 设计连贯性、命名清晰度与兄弟审查者互补代码质量审查者负责 bug 与逻辑错误安全审查者负责注入与路径穿越等漏洞而约定审查者专司规范符合度。与 linter 的分工边界biome.json 表明 Repomix 使用 Biome 作为代码风格与格式检查工具。约定审查者的第一条准则是只标记 linter 抓不到的问题——格式化、导入排序、分号、缩进等都属于 linter 的领地一律不重复报告。这条边界保证了审查产出全部落在格式正确但语义不一致的空白地带。与兄弟审查者的分工.agents/agents/reviewer-holistic.md 明确列出了各审查者的领地划分代码风格、命名、目录结构、提交格式归约定审查者bug、逻辑错误、类型安全归代码质量审查者注入、密钥、输入校验归安全审查者。约定审查者不得重复报告其他审查角度的发现。三、审查方法论三步走第一步发现约定Discover Conventions在标记偏差之前必须先建立基线baseline。文档给出了三条证据获取路径读取项目规则文件.agents/rules/、CLAUDE.md、CONTRIBUTING.md等文件中的显式约定。Repomix 的 .agents/rules/base.md 正是这类规则的典型——它规定了仓库布局src/、tests/、website/、browser/的职责划分、编码规范、提交信息格式与 PR 指南考察同一模块/功能区域的现有代码寻找隐式模式implicit patterns记录项目的依赖注入模式、错误处理风格、文件组织与命名习惯。以 Repomix 为例base.md 中有一条极具项目特色的依赖注入约定依赖必须通过deps对象参数注入以便测试。规则文件给出了标准写法export const functionName async ( param1: Type1, param2: Type2, deps { defaultFunction1, defaultFunction2, } ) { // Use deps.defaultFunction1() instead of direct call };并配套两条测试约定通过deps对象传入测试替身test doubles进行 mock仅当依赖注入不可行时才使用vi.mock()。约定审查者在检查新增代码时就可以据此核对新功能是否沿用了deps注入模式还是引入了直接调用依赖的反模式。第二步检查语义一致性Check Semantic Consistency这是方法论的核心文档将其细分为五个检查维度1. 命名清晰度Naming clarity——超越 linter 的命名检查名称是否准确描述代码行为例如一个名为getUser却可能返回null的函数应当改为findUser或让返回类型显式可空相似概念是否命名一致不要在不同模块间混用remove/delete/destroy表示同一操作布尔命名是否自然可读应当使用isValid、hasPermission、shouldRetry而非valid、permission、retry缩写是否与既有代码一致若代码库用config就不要引入cfg。2. API 设计一致性API design consistency新函数是否遵循既有参数顺序约定错误上报风格是否一致throw 与返回 null 与 Result 类型不混用新选项/配置是否与既有项保持相同的结构与命名3. 结构模式Structural patterns变更是否符合项目的模块组织模式新文件是否放在合适的 feature 目录文件大小是否超出项目限制Repomix 的 base.md 对此有明确规定以约 250 行为关注信号——当文件混杂多项职责时才拆分若长度来自单一内聚关注点如大型数据/配置表则保持原样新依赖是否遵循依赖注入模式4. 文档准确性Documentation accuracyJSDoc 注释、函数描述、行内注释在变更后是否仍与代码匹配param、returns、throws注解对已变更签名是否仍然准确README 章节或帮助文本是否描述了已改变的行为标记过时注释——那些描述代码过去行为而非现在行为的注释。5. 导出与公共 API 一致性Export and public API consistency新导出是否遵循既有命名与分组模式新增模块时 barrel 文件index.ts是否一致更新可见性级别是否合适不应导出本应内部使用的成员第三步权衡一致性与改进Consistency vs Improvement Tension方法论中一个值得注意的辩证视角并非所有偏差都是缺陷。当一个变更引入了明显比既有约定更好的模式时将其标记为讨论点discussion而非缺陷deviation注明这偏离了既有模式 X。如果这是有意为之且团队更偏好新方案考虑更新约定并迁移既有代码以保持一致。不要因一个内部自洽的风格改进而阻塞 PR。这条规则让审查者在维持一致性与拥抱进步之间取得平衡避免审查沦为对创新的压制。四、输出格式结构化的分级报告reviewer-conventions.md 为每条发现规定了七字段的规范化输出格式这也是编排者进行 triage分流的数据基础字段说明Typedeviation破坏既有约定或discussion更好但当前不一致SeverityHigh / Medium / Low按影响权重评级ConfidenceHigh / Medium / Low——并说明 Medium/Low 的置信度取决于什么Convention受影响的具体约定注明来源规则文件或模块 X 中的既有模式Location文件与行号引用Finding不一致的具体描述Suggestion如何对齐或说明为何值得更新约定配合 review-loop.md 中的编排逻辑这些报告会经过编排者二次过滤保留低置信度/低严重度的发现需编排者亲自对照代码确认幸存者再分类为Fix明确缺陷必须修复或Skip风格、吹毛求疵、范围蔓延。这种审查者全量上报、编排者过滤的二级漏斗结构最大化避免了漏报。五、指导原则让报告可信、可执行文档最后给出了六条操作准则它们是约定审查者保持专业水准的关键只标记 linter 遗漏的问题——格式化、导入排序、分号、缩进归 linter约定必须有证据——不发明项目中不存在的约定注明约定来源每条偏差记一条而非每处出现记一条——若变更相对代码库其余部分采用了不同模式这值得一条记录而不是每个文件/每行各记一条按影响加权——不一致的错误处理 不一致的公共 API 不一致的命名 不一致的文件组织 不一致的注释风格提交与 PR 约定检查——若项目有显式提交信息或 PR 约定如 Conventional Commits、必需的 scope当 diff 包含提交时应检查其符合度。Repomix 的 base.md 正要求提交信息遵循 Conventional Commits 格式type(scope): Description例如feat(cli): Add new --no-progress flag并对 scope 与 Description 的大小写有明确要求变更与约定高度一致时应简要说明——不要为了凑数而发明偏差。六、在 Repomix 仓库中的真实落地约定审查者并非纸上谈兵其背后有 Repomix 项目真实的、可对照的约定体系。以下是从 .agents/rules/base.md 中提炼的、约定审查者在 Repomix 中会实际核对的清单编码规范遵循biome.json强制的代码标准npm run lint与npm run test是提交前验证命令文件内聚性约 250 行为信号但仅在混杂多职责时拆分注释语言非显而易见的逻辑用英语注释测试配套新功能必须提供对应单元测试依赖注入通过deps对象注入依赖见上文代码示例vi.mock()仅作最后手段约定陷阱website/client/src/public/schemas/下的 JSON schema 是自动生成的npm run website-generate-schema严禁手工编辑面向用户的选项变更必须同步更新 15 种语言的文档目录website/client/src/下en加 14 个翻译 locale根目录npm run lint不检查 website client 的类型需在website/client目录下用npm run docs:build验证GitHub Actions 步骤必须固定到完整 commit SHA 并附版本注释提交信息Conventional Commits 加 scopePR 指南遵循 pull_request_template 对应模板引用 issue 使用#issue-number将同区域小变更合并为一个 PR。约定审查者正是拿着这样一份约定基线再叠加从模块现有代码中提炼的隐式模式才能对 diff 做出有证据支撑的一致性判断。反过来Repomix 的src/源码中大量出现的deps { ... }注入写法如 configLoad.ts、fileCollect.ts也印证了这些约定是真实执行、而非停留在文档层面的。七、延伸约定审查在完整工作流中的位置约定审查者只是多 Agent 审查体系中的一环。从 review-loop.md 与 pr-review.md 可以看到完整闭环日常审查循环review-loop并行启动 6 个审查者 → 编排者 triage保留值得注意的发现分 Fix/Skip→ 只修 Fix 项 →npm run lint与npm run test验证 → 仅对新改动行重新审查 → 无 Fix 项或达 3 轮后停止输出修复/跳过摘要。PR 审查pr-review先gh pr diff浏览 diff再按变更内容启动相关审查者约定审查者聚焦新文件、新/重命名 API、结构性变更。此外还会对既有 AI bot如gemini-code-assist[bot]、coderabbitai[bot]的行内评论进行优先级评判Required / Recommended / Not needed并回复降低维护者的认知负担。值得注意的是审查者的职责还有横向扩展同目录下的 reviewer-cross-platform.md 专注 Windows/macOS/Linux 的路径分隔符、glob 反斜杠转义等平台陷阱该文档甚至引用了 Repomix 历史上真实的 Windows 专属 bug——globby在.gitignore规则含反斜杠时崩溃的 issue #1765说明这套审查体系在约定之外还以同样严谨的结构覆盖了跨平台、性能、安全、测试覆盖等多个专业维度。约定审查者的方法论——发现基线、逐维度核对、分级上报、证据驱动——正是这一整套体系得以运转的通用范式。八、总结Repomix 的约定审查者角色文档展示了一套完整的语义级规范审查方法论先通过规则文件与现有代码建立约定基线再沿命名、API 设计、结构、文档、导出五个维度逐项核对用deviation/discussion区分破坏约定与值得讨论的改进最后以七字段结构化格式输出、交由编排者分流。其核心原则——只标记 linter 抓不到的、每条约定必须有证据、按影响加权、不发明偏差——保证了审查产出兼具广度与可信度。对于希望为自身项目搭建 Agent 审查体系的团队这份角色文档连同.agents/agents/下的其余七份审查者定义与 base.md 的项目规则就是一份可直接参照的完整模板。【免费下载链接】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），仅供参考