greptile-config

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Greptile Configuration Generator

Greptile配置生成器

Generate optimal Greptile AI code review configuration by analyzing the actual repository — its structure, tech stack, patterns, documentation, and team conventions — then producing tailored

.greptile/

configuration files.

通过分析仓库的实际结构、技术栈、模式、文档和团队约定，生成最优的Greptile AI代码审查配置，进而生成定制化的

.greptile/

配置文件。

What Greptile Is

什么是Greptile

Greptile is an AI code review agent that hooks into GitHub/GitLab PRs. It indexes the full codebase, reads configuration files on each PR (from the source branch), reviews changed files using LLM-powered semantic understanding, and posts inline comments, summaries, confidence scores, and status checks.

The critical insight: Greptile is not a linter. It uses LLMs to understand intent, architecture, and cross-file implications. Write rules that leverage semantic understanding — not rules a regex or ESLint could handle. "Service methods must not call HTTP endpoints directly — use the gateway client" is a great Greptile rule. "Use semicolons" is not.

Greptile是一款可接入GitHub/GitLab PR的AI代码审查Agent。它会索引整个代码库，在每次PR时读取（源分支的）配置文件，利用LLM驱动的语义理解审查变更文件，并发布行内评论、摘要、置信度评分和状态检查。

核心要点：Greptile不是代码检查工具（linter）。它使用LLM来理解代码意图、架构和跨文件影响。编写规则时要利用语义理解能力——而非正则或ESLint就能处理的规则。例如，“服务方法不得直接调用HTTP端点——请使用网关客户端”就是一个优秀的Greptile规则，而“使用分号”则不是。

Workflow

工作流程

Follow these five phases in order. Do not skip any phase.

请按顺序完成以下五个阶段，不得跳过任何阶段。

Phase 1: Explore the Repository

阶段1：探索仓库

Before writing a single line of config, map the territory. Use tools to answer:

Structure — Is this a monorepo or single-service? What are the top-level directories?
```
Run: ls -la at root, look for packages/, apps/, services/, src/
```

Tech stack — What languages, frameworks, ORMs, and testing tools are in use?

Check: package.json, requirements.txt, go.mod, Cargo.toml, build.gradle, etc.
Look at: tsconfig.json, .eslintrc, prettier config, Dockerfile

Build artifacts & generated code — What should be ignored?

Look for: dist/, build/, .next/, out/, __generated__/, migrations/
Check .gitignore for patterns to mirror in ignorePatterns

Existing documentation — What context files can the reviewer use?

Search for: docs/, architecture.md, ADRs, openapi/, swagger/, prisma/schema.prisma,
CONTRIBUTING.md, style guides, API specs

Existing linting & formatting — What does the toolchain already cover?

Check: .eslintrc, .prettierrc, stylelint, rubocop, flake8, golangci-lint
If strong linting exists → drop "style" from commentTypes

Team conventions — Look at recent commits and PR patterns

Check: branch naming, commit message style, test patterns, code organization

在编写任何配置之前，先梳理仓库情况。使用工具回答以下问题：

结构——这是单体仓库还是单一服务仓库？顶级目录有哪些？
```
Run: ls -la at root, look for packages/, apps/, services/, src/
```

技术栈——使用了哪些语言、框架、ORM和测试工具？

Check: package.json, requirements.txt, go.mod, Cargo.toml, build.gradle, etc.
Look at: tsconfig.json, .eslintrc, prettier config, Dockerfile

构建产物与生成代码——哪些内容应该被忽略？

Look for: dist/, build/, .next/, out/, __generated__/, migrations/
Check .gitignore for patterns to mirror in ignorePatterns

现有文档——审查者可以参考哪些上下文文件？

Search for: docs/, architecture.md, ADRs, openapi/, swagger/, prisma/schema.prisma,
CONTRIBUTING.md, style guides, API specs

现有代码检查与格式化工具——工具链已覆盖哪些内容？

Check: .eslintrc, .prettierrc, stylelint, rubocop, flake8, golangci-lint
If strong linting exists → drop "style" from commentTypes

团队约定——查看近期提交和PR模式

Check: branch naming, commit message style, test patterns, code organization

Phase 2: Decide Configuration Strategy

阶段2：确定配置策略

Which config method?

Situation	Method
Monorepo with multiple packages/services	`.greptile/` folder with cascading per-directory overrides
Single-service repo	`.greptile/` folder (recommended)
Different directories need different strictness	Root `.greptile/` + child `.greptile/config.json` in subdirectories

Always prefer

.greptile/

folder over

greptile.json

. If a

greptile.json

already exists, plan to migrate and delete it (

.greptile/

silently overrides

greptile.json

when both exist).

Strictness calibration:

Level	When to use
`1` (Verbose)	Security-critical code, junior-heavy teams, onboarding, early-stage projects
`2` (Balanced)	Most production codebases, mixed-seniority teams — start here
`3` (Critical only)	Senior teams, strong existing linting, pre-release hardening

For monorepos: set

at root, override to

in critical paths (payments, auth), override to

in low-risk areas (internal tools, scripts).

Comment types:

Start with

["logic", "syntax"]

. Add

"style"

only if no Prettier/ESLint. Add

"info"

only if the team wants educational comments (onboarding, junior devs).

选择哪种配置方式？

场景	方式
包含多个包/服务的单体仓库	使用 `.greptile/` 文件夹，支持按目录级联覆盖
单一服务仓库	使用 `.greptile/` 文件夹（推荐）
不同目录需要不同严格度	根目录 `.greptile/` + 子目录中的 `.greptile/config.json`

始终优先使用

.greptile/

文件夹而非

greptile.json

。如果已存在

greptile.json

，计划迁移并删除它（当两者同时存在时，

.greptile/

会静默覆盖

greptile.json

）。

严格度校准：

级别	使用场景
`1` （详细）	安全关键代码、新人较多的团队、新成员入职、早期项目
`2` （平衡）	大多数生产代码库、混合资历的团队——从此级别开始
`3` （仅关键问题）	资深团队、已有完善代码检查工具、预发布强化阶段

对于单体仓库：在根目录设置

，在关键路径（支付、认证）覆盖为

，在低风险区域（内部工具、脚本）覆盖为

。

评论类型：

从

["logic", "syntax"]

开始。仅当没有Prettier/ESLint时才添加

"style"

。仅当团队需要教育性评论（新成员入职、新人开发）时才添加

"info"

。

Phase 3: Engineer the Rules

阶段3：设计规则

This is the highest-leverage step. Every rule must be:

Specific — "Functions must not exceed 50 lines" not "Keep functions short"
Measurable — Pass/fail criteria must be unambiguous
Scoped — Every rule gets a
```
scope
```
array targeting relevant directories. A database rule should not fire on frontend components
Actionable — The developer must know exactly what to change
Semantic — Rules that require understanding, not pattern matching. If ESLint can catch it, ESLint should catch it
Identifiable — Every rule gets a unique
```
id
```
so child directories can disable it

Rule categories to scan for (check which apply to the repo):

Category	Signal to look for
Security	SQL queries, user input handling, auth code, PII
Architecture	Controller/service/repository layers, module boundaries
Error handling	try-catch patterns, error logging, error response shapes
API contracts	OpenAPI specs, shared API types, cross-service calls
Dependencies	Shared libraries, internal packages, design systems
Performance	Database queries in loops, N+1 patterns, unbounded fetches
Naming	Component naming, hook prefixes, file naming conventions
Migration	JS→TS migration, legacy patterns being phased out
Compliance	PII handling, logging restrictions, audit requirements
Tauri IPC	`#[tauri::command]` handlers, invoke calls, capability/permission scoping, state management with Mutex/RwLock
Tauri Security	CSP config, shell plugin usage, filesystem scope, input validation in command handlers, no panics in commands
MCP Protocol	Tool/resource/prompt handler compliance, input schema validation with Zod, structured error responses, transport correctness
MCP Security	Command injection prevention in tool handlers, file system access controls, secrets not logged, timeout enforcement
mcp-use Framework	MCPClient/MCPAgent session lifecycle, async context managers, tool call error handling, multi-server routing, connection cleanup
Next.js Website	Server Component boundaries, metadata/SEO, ISR/revalidation, image optimization, Core Web Vitals, structured data
Next.js Dashboard	Auth middleware on protected routes, server action input validation, role-based access, data table pagination, error boundaries
Next.js Shared	Server vs client component misuse, environment variable exposure, route handler authentication, CSRF via server actions

For each rule you write, explain why it exists by referencing what you found in the repo. Generic rules without repo-specific justification are noise.

这是价值最高的步骤。每条规则必须满足：

具体——例如“函数不得超过50行”而非“保持函数简短”
可衡量——通过/失败的标准必须明确
有范围——每条规则都要有
```
scope
```
数组，指向相关目录。数据库规则不应在前端组件上触发
可操作——开发者必须明确知道需要修改什么
语义化——需要理解代码意图的规则，而非模式匹配。如果ESLint可以检测到，就应该让ESLint来处理
可识别——每条规则都要有唯一的
```
id
```
，以便子目录可以禁用它

需要排查的规则类别（检查哪些适用于当前仓库）：

类别	关注信号
安全	SQL查询、用户输入处理、认证代码、个人可识别信息（PII）
架构	控制器/服务/仓储层、模块边界
错误处理	try-catch模式、错误日志、错误响应格式
API契约	OpenAPI规范、共享API类型、跨服务调用
依赖	共享库、内部包、设计系统
性能	循环中的数据库查询、N+1查询模式、无限制的数据获取
命名	组件命名、Hook前缀、文件命名约定
迁移	JS→TS迁移、逐步淘汰的旧模式
合规	PII处理、日志限制、审计要求
Tauri IPC	`#[tauri::command]` 处理器、调用、权限范围、Mutex/RwLock状态管理
Tauri安全	CSP配置、shell插件使用、文件系统范围、命令处理器中的输入验证、命令中避免panic
MCP协议	工具/资源/提示处理器合规性、使用Zod进行输入 schema 验证、结构化错误响应、传输正确性
MCP安全	工具处理器中的命令注入防护、文件系统访问控制、不记录敏感信息、超时强制执行
mcp-use框架	MCPClient/MCPAgent会话生命周期、异步上下文管理器、工具调用错误处理、多服务器路由、连接清理
Next.js网站	服务器组件边界、元数据/SEO、ISR/重新验证、图片优化、核心Web指标、结构化数据
Next.js仪表盘	受保护路由的认证中间件、服务器动作输入验证、基于角色的访问控制、数据表格分页、错误边界
Next.js共享	服务器与客户端组件误用、环境变量暴露、路由处理器认证、服务器动作CSRF防护

对于每条编写的规则，请参考在仓库中发现的内容解释其存在的原因。没有仓库特定依据的通用规则是无效的。

Phase 4: Map Context Files

阶段4：映射上下文文件

Scan the repo for documentation that would help the reviewer:

File type	What it provides	Example scope
Architecture docs	System boundaries, service topology	All files
API specs (OpenAPI/Swagger)	Endpoint contracts	`src/api/` , `src/routes/`
Database schemas (Prisma, migrations)	Model relationships	`src/db/` , `src/models/`
ADRs	Decision rationale	All files
Style/contribution guides	Team conventions	All files
Type definitions / shared contracts	Cross-service types	Service-specific

Scope context files to relevant directories. A Prisma schema is useless context when reviewing React components.

扫描仓库，找出对审查者有帮助的文档：

文件类型	提供的信息	示例范围
架构文档	系统边界、服务拓扑	所有文件
API规范（OpenAPI/Swagger）	端点契约	`src/api/` , `src/routes/`
数据库 schema（Prisma、迁移文件）	模型关系	`src/db/` , `src/models/`
ADR（架构决策记录）	决策依据	所有文件
风格/贡献指南	团队约定	所有文件
类型定义/共享契约	跨服务类型	特定服务

为上下文文件设置相关目录范围。Prisma schema在审查React组件时是无用的上下文。

Phase 5: Generate and Validate

阶段5：生成与验证

Generate the configuration files, then run the validation checklist before outputting.

Files to generate:

```
.greptile/config.json
```
— Primary configuration (review behavior, rules, filters, output format)
```
.greptile/rules.md
```
— Prose rules with code examples (only if rules need narrative context)
```
.greptile/files.json
```
— Context file mappings (only if documentation exists to reference)
Child
```
.greptile/config.json
```
files — For monorepo subdirectories that need different settings

Validation checklist — run before every output:

All JSON is syntactically valid (no trailing commas, no comments)
Every
```
scope
```
is an array of strings, never a comma-separated string
```
ignorePatterns
```
is a newline-separated string (
```
\n
```
), never an array
```
strictness
```
is integer 1, 2, or 3

commentTypes

only contains:

"logic"

"syntax"

"style"

"info"

```
severity
```
values only:
```
"high"
```
,
```
"medium"
```
,
```
"low"
```
```
patternRepositories
```
use
```
org/repo
```
format, never full URLs
Every disableable rule has a unique
```
id
```
Every rule is specific and measurable — no vague platitudes
Every high-noise rule has a
```
scope
```
```
fileChangeLimit
```
is >= 1 (0 skips all PRs)
```
files.json
```
paths point to files that actually exist in the repo
No
```
.greptile/
```
and
```
greptile.json
```
coexistence (if migrating, note to delete old)

Output format:

For every configuration you produce, include:

File tree showing exactly which files go where
Each config file as a complete, valid JSON (or markdown) code block
Reasoning annotations after each file explaining WHY each major decision was made, referencing specific repo context
Canary test — a simple verification step to confirm the config is working
Migration notes if moving from
```
greptile.json
```
to
```
.greptile/
```

生成配置文件，然后在输出前运行验证清单。

需要生成的文件：

```
.greptile/config.json
```
——主配置（审查行为、规则、过滤器、输出格式）
```
.greptile/rules.md
```
——带代码示例的规则说明文档（仅当规则需要叙事上下文时）
```
.greptile/files.json
```
——上下文文件映射（仅当存在可参考的文档时）
子目录的
```
.greptile/config.json
```
文件——用于需要不同设置的单体仓库子目录

验证清单——每次输出前运行：

所有JSON语法有效（无尾随逗号、无注释）
每个
```
scope
```
都是字符串数组，而非逗号分隔的字符串
```
ignorePatterns
```
是换行分隔的字符串（
```
\n
```
），而非数组
```
strictness
```
是整数1、2或3

commentTypes

仅包含：

"logic"

"syntax"

"style"

"info"

```
severity
```
值仅为：
```
"high"
```
,
```
"medium"
```
,
```
"low"
```
```
patternRepositories
```
使用
```
org/repo
```
格式，而非完整URL
每个可禁用的规则都有唯一的
```
id
```
每条规则都具体且可衡量——无模糊表述
每条高噪音规则都有
```
scope
```
```
fileChangeLimit
```
>= 1（0表示跳过所有PR）
```
files.json
```
中的路径指向仓库中实际存在的文件
避免
```
.greptile/
```
与
```
greptile.json
```
共存（如果迁移，需注明删除旧文件）

输出格式：

对于生成的每个配置，需包含：

文件树，明确显示每个文件的位置
每个配置文件，作为完整有效的JSON（或Markdown）代码块
推理注释，在每个文件后解释每个主要决策的原因，并引用具体的仓库上下文
验证测试——一个简单的验证步骤，确认配置正常工作
迁移说明（如果从
```
greptile.json
```
迁移到
```
.greptile/
```
）

Reference Files

参考文件

Read these when you need detailed specifications:

references/config-spec.md
— Complete parameter reference for all config files, data types, cascading behavior, and monorepo inheritance rules. Read this when you need to check a specific parameter's format or understand how child configs interact with parent configs.
references/anti-patterns.md
— Common mistakes, the troubleshooting reasoning chain, and the testing/verification protocol. Read this before finalizing any output to catch errors. Also useful when debugging why a Greptile config isn't working.
references/scenarios.md
— Complete example configurations for TypeScript backend, React frontend, and monorepo setups. Read these for inspiration, but never copy them verbatim — every rule must be justified by the actual repository context.

当需要详细规范时，请阅读以下文件：

references/config-spec.md
——所有配置文件的完整参数参考、数据类型、级联行为和单体仓库继承规则。当需要检查特定参数的格式，或理解子配置与父配置的交互时，请阅读此文件。
references/anti-patterns.md
——常见错误、故障排除推理链和测试/验证协议。在最终确定任何输出前，请阅读此文件以发现错误。当调试Greptile配置无法工作的原因时也很有用。
references/scenarios.md
——TypeScript后端、React前端和单体仓库设置的完整示例配置。这些示例可作为灵感来源，但切勿直接复制——每条规则都必须有实际仓库上下文的依据。

Key Gotchas (Keep in Mind)

关键注意事项（请牢记）

Config is read from the source branch of the PR, not the target branch
Changes take effect on the next PR, not retroactively
```
ignorePatterns
```
skips review only — files are still indexed
```
includeAuthors: []
```
means all authors (not none)
```
fileChangeLimit: 0
```
means skip all PRs (minimum is 1)
To suppress "X files reviewed, no comments" messages, use
```
statusCheck: true
```
(not
```
statusCommentsEnabled: false
```
)
After ~10 PRs, Greptile auto-suggests rules — duplicates of existing rules may appear (this is normal)

配置从PR的源分支读取，而非目标分支
更改在下一个PR生效，不会追溯应用
```
ignorePatterns
```
仅跳过审查——文件仍会被索引
```
includeAuthors: []
```
表示所有作者（而非无作者）
```
fileChangeLimit: 0
```
表示跳过所有PR（最小值为1）
要抑制“已审查X个文件，无评论”的消息，请使用
```
statusCheck: true
```
（而非
```
statusCommentsEnabled: false
```
）
约10个PR后，Greptile会自动建议规则——可能会出现与现有规则重复的情况（这是正常的）