用途：为仓库生成可直接使用的 Greptile AI 代码审查配置。Greptile 是接入 GitHub/GitLab PR 的 AI 审查代理，会索引整个代码库、读取源分支上的配置文件，并用大模型做语义理解后发布行内评论、摘要、置信度与状态检查。它不是 linter，规则应利用语义理解，而非正则或 ESLint 能覆盖的内容。
主要能力：按五个阶段工作。一、探索仓库：识别单仓或多仓结构、语言框架 ORM 与测试工具、构建产物与生成代码、已有文档、现有 lint/格式化工具链、团队约定。二、决定配置策略：多包多服务用 .greptile/ 目录并支持按目录级联覆盖，单服务仓库推荐 .greptile/ 目录；严格度分 1 冗长、2 平衡、3 仅关键，多仓可在根设 2 并对支付、认证等关键路径覆盖为 1。评论类型从 logic、syntax 起步，无 Prettier/ESLint 才加 style。三、编写规则：每条规则需具体、可度量、有 scope 数组、可操作、语义化且带唯一 id，覆盖安全、架构、错误处理、API 契约、依赖、性能、命名、迁移、合规等类别。四、映射上下文文件：将架构文档、OpenAPI 规范、数据库 schema、ADR、风格指南等按目录限定作用域。五、生成并校验：产出 .greptile/config.json，必要时加 rules.md、files.json 及子目录 config.json。
使用方式：按上述五阶段顺序执行，输出文件树、完整有效 JSON、决策理由、验证步骤与迁移说明。校验要点包括 JSON 合法、scope 为字符串数组、ignorePatterns 为换行分隔字符串、strictness 为 1/2/3、severity 仅 high/medium/low、patternRepositories 用 org/repo 格式、fileChangeLimit 不小于 1、files.json 路径真实存在、避免 .greptile/ 与 greptile.json 共存。
限制与注意：配置从 PR 源分支读取，改动仅对后续 PR 生效；ignorePatterns 只跳过审查，文件仍被索引；includeAuthors 为空数组表示全部作者；fileChangeLimit 为 0 会跳过所有 PR；约 10 个 PR 后 Greptile 会自动建议规则，可能出现重复。具体参数细节、反模式与示例场景需查阅其 references 文件。