Back to Details

devin-review-init

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Devin Review Configuration Generator

Devin Review配置生成器

Generate optimal 
REVIEW.md
and optionally 
AGENTS.md
files by analyzing the actual repository — its structure, tech stack, patterns, documentation, and team conventions — then producing tailored review instruction files that make Devin's Bug Catcher catch real issues.
通过分析实际仓库的结构、技术栈、模式、文档和团队约定，生成最优的
REVIEW.md
（可选生成
AGENTS.md
）文件，定制化的审查指令文件可让Devin的Bug Catcher精准发现真实问题。

What Devin Review Is

什么是Devin Review

Devin Review is an AI code review platform that hooks into GitHub PRs. It:
  1. Reads instruction files in the repo (
    REVIEW.md
    , 
    AGENTS.md
    , 
    CLAUDE.md
    , 
    CONTRIBUTING.md
    , 
    .cursorrules
    , 
    .windsurfrules
    , 
    *.rules
    , 
    *.mdc
    )
  2. Analyzes diffs with the Bug Catcher, classifying findings as Bugs (severe/non-severe) or Flags (investigate/informational)
  3. Posts reviews with smart diff organization, copy/move detection, and inline comments synced to GitHub
  4. Supports auto-review on PR open, push, and ready-for-review events
The critical insight: 
REVIEW.md
is the primary mechanism for customizing what Devin's Bug Catcher looks for. Well-written review guidelines make the difference between noise and catching real bugs. Devin reads 
REVIEW.md
at any directory level (
**/REVIEW.md
), so you can scope guidelines to subdirectories in monorepos.
Devin Review是一款对接GitHub PR的AI代码审查平台，具备以下功能：
  1. 读取仓库中的指令文件（
    REVIEW.md
    、
    AGENTS.md
    、
    CLAUDE.md
    、
    CONTRIBUTING.md
    、
    .cursorrules
    、
    .windsurfrules
    、
    *.rules
    、
    *.mdc
    ）
  2. 使用Bug Catcher分析差异，将发现的问题分类为Bug（严重/非严重）或Flag（需调查/信息性）
  3. 发布审查结果，包含智能差异组织、复制/移动检测，以及与GitHub同步的行内评论
  4. 支持自动审查，在PR打开、推送和标记为可审查事件时触发
核心要点：
REVIEW.md
是自定义Devin的Bug Catcher检查范围的主要机制。编写精良的审查指南是区分无效噪音与真实Bug的关键。Devin会读取任意目录层级的
REVIEW.md
（
**/REVIEW.md
），因此你可以在单体仓库中为子目录设置专属审查规则。

What Makes a Good REVIEW.md

优质REVIEW.md的标准

Devin's Bug Catcher uses instruction files as context when analyzing PRs. The more specific and actionable your guidelines are, the more precise the Bug Catcher becomes. Key principles:
  1. Specific over vague — "All API endpoints must validate request body with Zod" beats "validate inputs"
  2. Actionable — The developer reading a flag should know exactly what to fix
  3. Prioritized — Lead with critical areas (security, auth, data integrity) so the Bug Catcher weighs them higher
  4. Code examples help — Good/bad patterns in fenced code blocks let the Bug Catcher match against actual anti-patterns
  5. Keep it under 500 lines — Overly verbose files dilute signal and slow AI parsing
  6. Flat structure — Use H2/H3 headers and bullet lists. Deep nesting reduces parsing accuracy
Devin的Bug Catcher在分析PR时会以指令文件为上下文参考。你的指南越具体、可执行，Bug Catcher的检测精度就越高。核心原则：
  1. 具体优先于模糊 —— “所有API端点必须使用Zod验证请求体”优于“验证输入”
  2. 具备可执行性 —— 开发人员看到Flag时应明确知道需要修复什么
  3. 区分优先级 —— 优先列出关键领域（安全、认证、数据完整性），让Bug Catcher重点关注
  4. 代码示例辅助 —— 在代码块中提供正确/错误的模式示例，帮助Bug Catcher匹配反模式
  5. 控制在500行以内 —— 过于冗长的文件会稀释有效信息，降低AI解析效率
  6. 扁平化结构 —— 使用H2/H3标题和项目符号列表，深层嵌套会降低解析准确性

Workflow

工作流程

Follow these four phases in order.
按以下四个阶段依次执行。

Phase 1: Explore the Repository

阶段1：探索仓库

Before writing anything, map the territory. Use tools to answer:
  1. Structure — Monorepo or single-service? What are the top-level directories? 
    Run: ls -la at root, look for packages/, apps/, services/, src/
  2. Tech stack — Languages, frameworks, ORMs, testing tools? 
    Check: package.json, requirements.txt, go.mod, Cargo.toml, pyproject.toml
Look at: tsconfig.json, .eslintrc, prettier config, Dockerfile
  3. Existing instruction files — Does the repo already have REVIEW.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, .cursorrules? 
    Search for: REVIEW.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, .cursorrules, .windsurfrules
If they exist, read them — you'll extend rather than replace
  4. Documentation — What context files exist? 
    Search for: docs/, architecture.md, ADRs, openapi/, swagger/, prisma/schema.prisma
  5. Existing linting & CI — What does the toolchain already catch? 
    Check: .eslintrc, .prettierrc, CI configs, pre-commit hooks
Don't duplicate what linters already enforce
  6. Pain points — Look at recent PRs, issues, and git history for patterns 
    Check: common bug patterns, frequently reverted commits, security incidents
在编写任何内容之前，先梳理仓库情况。使用工具解答以下问题：
  1. 结构 —— 是单体仓库还是单服务仓库？顶级目录有哪些？ 
    执行：在根目录运行ls -la，查看是否有packages/、apps/、services/、src/
  2. 技术栈 —— 使用的语言、框架、ORM、测试工具是什么？ 
    查看：package.json、requirements.txt、go.mod、Cargo.toml、pyproject.toml
检查：tsconfig.json、.eslintrc、prettier配置、Dockerfile
  3. 现有指令文件 —— 仓库中是否已存在REVIEW.md、AGENTS.md、CLAUDE.md、CONTRIBUTING.md、.cursorrules？ 
    搜索：REVIEW.md、AGENTS.md、CLAUDE.md、CONTRIBUTING.md、.cursorrules、.windsurfrules
若已存在，需阅读这些文件——你需要扩展而非替换它们
  4. 文档 —— 存在哪些上下文文件？ 
    搜索：docs/、architecture.md、ADRs、openapi/、swagger/、prisma/schema.prisma
  5. 现有 lint 与CI —— 工具链已能检测哪些问题？ 
    检查：.eslintrc、.prettierrc、CI配置、pre-commit钩子
不要重复实现linters已有的规则
  6. 痛点 —— 查看近期PR、问题和Git历史中的模式 
    检查：常见Bug模式、频繁回滚的提交、安全事件

Phase 2: Decide File Strategy

阶段2：确定文件策略

Which files to generate:
SituationFiles
Single-service repoRoot 
REVIEW.md
Monorepo with different review needs per packageRoot 
REVIEW.md
+ scoped 
REVIEW.md
in subdirectories
Team using Devin for task execution tooRoot 
REVIEW.md
+ 
AGENTS.md
Repo already has CLAUDE.md or .cursorrulesRoot 
REVIEW.md
(complement, don't duplicate existing files)
REVIEW.md vs AGENTS.md:
  • REVIEW.md
    — Review-specific guidelines: what to check, what to flag, what to ignore. Read by Bug Catcher during PR analysis.
  • AGENTS.md
    — Agent behavior instructions: coding style, architecture decisions, workflow patterns. Read by Devin during task execution (not just reviews).
If the user only mentions review/PR setup, generate 
REVIEW.md
only. If they mention Devin task execution or agent behavior, also generate 
AGENTS.md
.
需要生成哪些文件：
场景文件
单服务仓库根目录
REVIEW.md
单体仓库，不同包有不同审查需求根目录
REVIEW.md
+ 子目录专属
REVIEW.md
团队同时使用Devin执行任务根目录
REVIEW.md
+ 
AGENTS.md
仓库已存在CLAUDE.md或.cursorrules根目录
REVIEW.md
（补充而非重复现有文件内容）
REVIEW.md vs AGENTS.md：
  • REVIEW.md
    —— 审查专属指南：需要检查什么、标记什么、忽略什么。Bug Catcher在分析PR时会读取此文件。
  • AGENTS.md
    —— Agent行为指令：编码风格、架构决策、工作流模式。Devin在执行任务时（不仅是审查）会读取此文件。
如果用户仅提及审查/PR设置，仅生成
REVIEW.md
。如果用户提及Devin任务执行或Agent行为，同时生成
AGENTS.md
。

Phase 3: Write the REVIEW.md

阶段3：编写REVIEW.md

Structure the file using these sections. Include only sections relevant to the repo — don't pad with generic filler.
Recommended section order (the Bug Catcher weighs content near the top higher):
使用以下结构组织文件内容，仅保留与仓库相关的部分——不要添加通用填充内容。
推荐的章节顺序（Bug Catcher会优先处理顶部内容）：

1. Critical Areas (always include)

1. 关键领域（必须包含）

What parts of the codebase need extra scrutiny. Be specific about paths and why.
markdown
undefined
代码库中需要额外审查的部分。明确说明路径及原因。
markdown
undefined

Critical Areas

关键领域

  • All changes to 
    src/auth/
    must be reviewed for security implications — this handles JWT validation and session management.
  • Database migration files in 
    prisma/migrations/
    should be checked for backward compatibility and data loss risk.
  • Payment processing in 
    src/billing/
    requires review for PCI compliance — no PII in logs, idempotent mutations.
undefined
  • 所有对
    src/auth/
    的修改必须审查安全影响——该目录处理JWT验证和会话管理。
  • prisma/migrations/
    中的数据库迁移文件需检查向后兼容性和数据丢失风险。
  • src/billing/
    中的支付处理逻辑需审查PCI合规性——日志中不得包含PII，需实现幂等变更。
undefined

2. Conventions (always include)

2. 约定规范（必须包含）

Project-specific rules the Bug Catcher should enforce. These are the highest-value rules — make them specific and measurable.
markdown
undefined
Bug Catcher需要强制执行的项目专属规则。这些是最高价值的规则——需具体且可衡量。
markdown
undefined

Conventions

约定规范

  • API endpoints must validate request bodies using Zod schemas from 
    src/schemas/
    .
  • All public functions require explicit TypeScript return types — do not use 
    any
    or implicit returns.
  • React components must be functional components with hooks, not class components.
  • Use 
    next/image
    for all images — never raw 
    <img>
    tags.
undefined
  • API端点必须使用
    src/schemas/
    中的Zod schema验证请求体。
  • 所有公共函数必须显式声明TypeScript返回类型——禁止使用
    any
    或隐式返回。
  • React组件必须是使用hooks的函数式组件，而非类组件。
  • 所有图片必须使用
    next/image
    ——禁止使用原生
    <img>
    标签。
undefined

3. Security (include if the repo handles auth, user data, or external APIs)

3. 安全（若仓库涉及认证、用户数据或外部API则包含）

Security-specific rules that the Bug Catcher should flag as severe bugs.
markdown
undefined
Bug Catcher需标记为严重Bug的安全专属规则。
markdown
undefined

Security

安全

  • Never interpolate user input into SQL queries. Use parameterized queries via Prisma.
  • API keys and secrets must never appear in source code — use environment variables.
  • All API routes must check authentication. Never rely on client-side auth alone.
  • Sanitize HTML output to prevent XSS. Use DOMPurify for user-generated content.
undefined
  • 禁止将用户输入直接插入SQL查询，需使用Prisma的参数化查询。
  • API密钥和机密信息不得出现在源代码中——需使用环境变量。
  • 所有API路由必须检查认证状态，不得仅依赖客户端认证。
  • 清理HTML输出以防止XSS攻击，对用户生成内容使用DOMPurify。
undefined

4. Performance (include if performance-sensitive)

4. 性能（若仓库对性能敏感则包含）

Patterns to flag as investigate-level warnings.
markdown
undefined
需标记为需调查级警告的模式。
markdown
undefined

Performance

性能

  • Flag any database queries inside loops — use batch operations instead.
  • Watch for N+1 query patterns in API resolvers and serializers.
  • Large datasets must be paginated server-side, not fetched all at once.
undefined
  • 标记循环内的数据库查询——需使用批量操作替代。
  • 注意API解析器和序列化器中的N+1查询模式。
  • 大型数据集必须在服务端分页，不得一次性全部获取。
undefined

5. Patterns (include code examples when the convention isn't obvious)

5. 代码模式（若约定规范不明确则包含代码示例）

Good/bad code examples that the Bug Catcher can match against. Use fenced code blocks with clear labels.
markdown
undefined
Bug Catcher可匹配的正确/错误代码示例。使用代码块并添加清晰标签。
markdown
undefined

Patterns

代码模式

Error Handling

错误处理

Every async function must handle errors explicitly.
Good: ```typescript async function getUser(id: string): Promise<User> { try { return await db.user.findUniqueOrThrow({ where: { id } }); } catch (error) { logger.error('getUser failed', { id, error }); throw new AppError('USER_NOT_FOUND', { cause: error }); } } ```
Bad: ```typescript async function getUser(id: string) { return await db.user.findUnique({ where: { id } }); // no error handling, implicit any return } ```
undefined
所有异步函数必须显式处理错误。
正确示例： ```typescript async function getUser(id: string): Promise<User> { try { return await db.user.findUniqueOrThrow({ where: { id } }); } catch (error) { logger.error('getUser failed', { id, error }); throw new AppError('USER_NOT_FOUND', { cause: error }); } } ```
错误示例： ```typescript async function getUser(id: string) { return await db.user.findUnique({ where: { id } }); // 无错误处理，隐式any返回 } ```
undefined

6. Ignore (include to reduce noise)

6. 忽略规则（用于减少噪音）

Files the Bug Catcher should skip.
markdown
undefined
Bug Catcher需要跳过的文件。
markdown
undefined

Ignore

忽略规则

  • Auto-generated files in 
    src/generated/
    do not need review.
  • Lock files (package-lock.json, yarn.lock, pnpm-lock.yaml) can be skipped unless dependencies changed.
  • Migration files in 
    prisma/migrations/
    are auto-generated — only review the schema changes.
  • Test snapshots in 
    __snapshots__/
    don't need review.
undefined
  • src/generated/
    中的自动生成文件无需审查。
  • 锁文件（package-lock.json、yarn.lock、pnpm-lock.yaml）可跳过，除非依赖项发生变更。
  • prisma/migrations/
    中的迁移文件为自动生成——仅需审查schema变更。
  • __snapshots__/
    中的测试快照无需审查。
undefined

7. Testing (include if the repo has test requirements)

7. 测试（若仓库有测试要求则包含）

Testing conventions and coverage expectations.
markdown
undefined
测试约定规范和覆盖率要求。
markdown
undefined

Testing

测试

  • All new API endpoints must have integration tests.
  • Utility functions must have unit tests with edge cases.
  • Test files must be co-located with source files (e.g., 
    utils.test.ts
    next to 
    utils.ts
    ).
undefined
  • 所有新API端点必须有集成测试。
  • 工具函数必须包含边界情况的单元测试。
  • 测试文件必须与源文件同目录存放（例如
    utils.test.ts
    与
    utils.ts
    相邻）。
undefined

Phase 4: Validate and Output

阶段4：验证与输出

Before outputting, verify:
  • REVIEW.md
    is under 500 lines (ideally 100-300)
  • No duplicate rules that existing linters already catch
  • Rules are specific and measurable, not vague platitudes
  • Critical/security sections are near the top
  • Code examples use the repo's actual language and framework patterns
  • Ignore patterns match the repo's actual generated/build directories
  • If CLAUDE.md or .cursorrules exist, REVIEW.md doesn't repeat their content
  • Monorepo subdirectory REVIEW.md files don't repeat root-level rules
Output format:
For every configuration you produce, include:
  1. File tree showing exactly which files go where and what each is for
  2. Each file as a complete markdown code block
  3. Reasoning annotations after each file explaining WHY each major section was included, referencing specific repo context
  4. Verification step — how to test the config works (open a test PR, use 
    @greptileai review
    equivalent, or check the Devin Review dashboard)
输出前需验证：
  • REVIEW.md
    控制在500行以内（理想范围100-300行）
  • 无与现有linters重复的规则
  • 规则具体且可衡量，而非模糊的套话
  • 关键/安全章节位于文件顶部
  • 代码示例使用仓库实际的语言和框架模式
  • 忽略规则匹配仓库实际的生成/构建目录
  • 若仓库存在CLAUDE.md或.cursorrules，REVIEW.md不重复其内容
  • 单体仓库子目录的REVIEW.md不重复根目录规则
输出格式：
对于生成的每个配置，需包含：
  1. 文件树，明确说明各文件的存放位置及用途
  2. 完整文件内容，以完整的Markdown代码块形式呈现
  3. 推理注释，在每个文件后解释主要章节的添加原因，并参考具体仓库上下文
  4. 验证步骤 —— 如何测试配置是否生效（打开测试PR、使用
    @greptileai review
    等效命令，或检查Devin Review仪表盘）

Reference Files

参考文件

Read these when you need detailed specifications or examples:
  • references/review-spec.md
     — Complete reference for REVIEW.md format, AGENTS.md format, all instruction files Devin reads, auto-review configuration, and Bug Catcher behavior. Read this when you need to check what Devin supports or how findings are classified.
  • references/scenarios.md
     — Complete example REVIEW.md files for different stack types (TypeScript backend, Next.js, Python Django, Tauri, MCP server, monorepo). Read these for inspiration, but always adapt to the actual repository — never copy verbatim.
当需要详细规范或示例时，可参考以下文件：
  • references/review-spec.md
     —— REVIEW.md格式、AGENTS.md格式、Devin读取的所有指令文件、自动审查配置及Bug Catcher行为的完整参考文档。当需要确认Devin支持的功能或问题分类方式时，可阅读此文件。
  • references/scenarios.md
     —— 针对不同技术栈（TypeScript后端、Next.js、Python Django、Tauri、MCP服务器、单体仓库）的完整REVIEW.md示例文件。可作为参考灵感，但需始终根据实际仓库调整——切勿直接复制。

Key Gotchas

关键注意事项

  • REVIEW.md
    is read from any directory level (
    **/REVIEW.md
    ) — use this for monorepo scoping
  • Devin also reads 
    AGENTS.md
    , 
    CLAUDE.md
    , 
    CONTRIBUTING.md
    , 
    .cursorrules
    , 
    .windsurfrules
    , 
    *.rules
    , 
    *.mdc
    — check for conflicts
  • Auto-review triggers on PR open, push to PR, and when a draft is marked ready
  • The Bug Catcher classifies findings as: Bugs (severe, non-severe) and Flags (investigate, informational)
  • Keep REVIEW.md focused on review concerns — put coding/architecture standards in AGENTS.md or CLAUDE.md instead
  • Custom review rule file paths can be configured in Settings > Review, but 
    **/REVIEW.md
    is always read by default
  • REVIEW.md
    可在任意目录层级读取（
    **/REVIEW.md
    ）——可利用此特性在单体仓库中设置专属规则
  • Devin也会读取
    AGENTS.md
    、
    CLAUDE.md
    、
    CONTRIBUTING.md
    、
    .cursorrules
    、
    .windsurfrules
    、
    *.rules
    、
    *.mdc
    ——需检查内容冲突
  • 自动审查在PR打开、推送到PR、以及草稿标记为可审查时触发
  • Bug Catcher将发现的问题分类为：Bug（严重、非严重）和Flag（需调查、信息性）
  • 保持REVIEW.md聚焦于审查相关内容——编码/架构标准应放在AGENTS.md或CLAUDE.md中
  • 可在设置>审查中配置自定义审查规则文件路径，但
    **/REVIEW.md
    始终会被默认读取