Skip to main content
Complete field reference for the three files in a .greptile/ folder. For how cascading works and monorepo examples, see .greptile/ Configuration.

config.json

Your review settings and structured rules. All fields are optional — only include what you want to configure.

Review Settings

FieldTypeDefaultDescription
strictness1 | 2 | 32Comment threshold. 1 = verbose (flags more issues), 3 = critical only (flags fewer issues)
commentTypesstring[]["syntax", "logic", "style", "info"]Which comment categories to include
fileChangeLimitnumberMaximum number of changed files to review
modelstringLLM model override

Filters

Control which PRs get reviewed.
FieldTypeDescription
labelsstring[]Only review PRs with these labels
disabledLabelsstring[]Skip review for PRs with these labels
includeAuthorsstring[]Only review PRs from these authors
excludeAuthorsstring[]Skip review for PRs from these authors
includeBranchesstring[]Only review PRs targeting these branches
excludeBranchesstring[]Skip review for PRs targeting these branches
includeKeywordsstringNewline-separated keywords. Only review PRs with these in title/description
ignoreKeywordsstringNewline-separated keywords. Skip PRs with these in title/description
ignorePatternsstringFile patterns to skip, using .gitignore syntax (newline-separated)

Behavior

FieldTypeDefaultDescription
triggerOnUpdatesbooleanfalseRe-run the review when the PR is updated
statusCheckbooleanfalsePost a GitHub status check with the review result
statusCommentsEnabledbooleanEnable status comments on PRs
skipReview"AUTOMATIC"Set to "AUTOMATIC" to skip review entirely for files in this directory
shouldUpdateDescriptionbooleanIf true, updates PR description instead of posting a review comment
updateExistingSummaryCommentbooleanUpdate existing review comment instead of creating a new one
updateSummaryOnlybooleanOnly update the summary, don’t post individual inline comments
fixWithAIbooleanAdd AI fix prompts to help AI coding assistants understand suggested fixes
hideFooterbooleanHide the Greptile footer from review comments
commentstringDisclaimer or prefix text added to every PR summary

Output Sections

Each section controls a part of the review output. All sub-fields are optional booleans.
FieldDescription
summarySectionPR summary at the top of the review
issuesTableSectionTable of all issues found
confidenceScoreSectionConfidence score for each comment
sequenceDiagramSectionSequence diagram of the changes
Each accepts an object with these sub-fields:
Sub-fieldTypeDescription
includedbooleanWhether to show this section
collapsiblebooleanWhether the section can be collapsed
defaultOpenbooleanWhether the section starts expanded

Instructions

FieldTypeDescription
instructionsstringFree-form instructions for the reviewer. When cascading, instructions from all parent configs are concatenated together.

Rules

Structured rules let you define what the reviewer should check for, with optional scoping and severity.
FieldTypeDescription
rulesRule[]Array of structured rules. See schema below.
disabledRulesstring[]IDs of rules inherited from parent configs that should not apply in this directory. See Disabling Inherited Rules.

Rule Schema

Each entry in the rules array:
FieldTypeRequiredDescription
rulestringYesThe rule instruction shown to the reviewer
idstringNoStable identifier. Required if a child config needs to disable this rule via disabledRules.
scopestring[]NoGlob patterns for files this rule applies to, relative to the .greptile/ directory. Avoid ../ patterns — rules should apply within their own directory tree.
severity"low" | "medium" | "high"NoSeverity level for violations
enabledbooleanNoWhether the rule is active. Default: true

Complete Example

.greptile/config.json
{
  "strictness": 2,
  "commentTypes": ["logic", "syntax"],
  "triggerOnUpdates": true,
  "ignorePatterns": "**/*.generated.*\ndist/**\nnode_modules/**",
  "summarySection": {
    "included": true,
    "collapsible": true,
    "defaultOpen": false
  },
  "instructions": "This is a TypeScript monorepo using pnpm workspaces. We use Prisma for database access and zod for validation.",
  "rules": [
    {
      "id": "no-console",
      "rule": "Do not use console.log in production code. Use the logger service instead.",
      "scope": ["src/**"],
      "severity": "medium"
    },
    {
      "rule": "All async functions must have error handling.",
      "severity": "high"
    }
  ],
  "disabledRules": []
}
The first rule has an id so it can be disabled by child configs. The second rule has no id — it applies everywhere and can’t be selectively turned off.

rules.md

Plain markdown passed to the reviewer as context. The entire file is scoped to the directory containing the .greptile/ folder — it applies to all files reviewed within that directory tree. There is no special syntax or parsing. Write standard markdown with headings, lists, code blocks, and any other formatting that helps communicate your rules clearly.

Example

.greptile/rules.md
# Code Review Rules

## Error Handling

All async functions must use try-catch blocks. Never swallow errors silently.
At minimum, log the error with context:

​```typescript
try {
  await operation();
} catch (error) {
  logger.error('Operation failed', { error, context });
  throw error;
}
​```

## SQL Injection Prevention

Always use parameterized queries. Never interpolate user input into SQL strings.

- Use prepared statements
- Validate input types before queries
- Use Prisma's query builder instead of raw SQL where possible

## API Input Validation

Validate all API inputs using zod schemas before processing. Define the schema
next to the route handler.

rules.md vs config.json rules

Both define review rules. The difference is structure and granularity:
rules.mdconfig.json rules
FormatFree-form markdownStructured JSON
ScopingEntire file applies to its directory treePer-rule scope via glob patterns
SeverityNot supportedlow / medium / high
Disable by IDNot supportedSupported via disabledRules
Best forProse explanations, code examples, guidelinesPrecise, individually scoped and disableable rules
You can use both in the same .greptile/ folder. They’re additive — the reviewer sees rules from both sources.

files.json

Points the reviewer to existing files in your repository that it should read for context — database schemas, API specs, architecture docs, or anything that helps the reviewer understand your codebase.

Schema

FieldTypeRequiredDescription
pathstringYesPath to the file, relative to the repository root
descriptionstringNoWhat the file contains and why it’s relevant to reviews
scopestring[]NoGlob patterns — only include this file when reviewing files matching these patterns. Patterns are relative to the .greptile/ directory; avoid ../ patterns.

Example

.greptile/files.json
{
  "files": [
    {
      "path": "prisma/schema.prisma",
      "description": "Database schema — reference for model relationships and field types"
    },
    {
      "path": "docs/api-contracts.yaml",
      "description": "OpenAPI specification for all public endpoints",
      "scope": ["src/api/**"]
    },
    {
      "path": "docs/auth-flow.md",
      "description": "Authentication and authorization flow documentation",
      "scope": ["src/auth/**", "src/middleware/auth*"]
    }
  ]
}
Files without a scope are included in every review within the directory tree. Files with a scope are only included when the file being reviewed matches one of the glob patterns. File references are accumulated from all parent configs — a child config doesn’t replace the parent’s file list, it adds to it.

What’s Next