> ## Documentation Index
> Fetch the complete documentation index at: https://opensre.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Pull request review flow

> How Greptile, human review, and CI work on OpenSRE pull requests.

This page describes what happens after you open a pull request: Greptile
review, required CI, and maintainer review.

Greptile helps maintainers manage the queue. It does not replace maintainer
approval.

## Overview

1. Open a focused pull request with the
   [PR template](https://github.com/Tracer-Cloud/opensre/blob/main/.github/PULL_REQUEST_TEMPLATE.md)
   completed.
2. Leave **Allow edits from maintainers** enabled on fork pull requests.
3. Wait for CI. The required check is **CI Gate**.
4. Trigger Greptile and reach **Confidence Score: 5/5** with no unresolved
   threads.
5. A maintainer reviews and either merges or requests changes.

Contribution rules:
[CONTRIBUTING.md](https://github.com/Tracer-Cloud/opensre/blob/main/CONTRIBUTING.md).
Local checks before you push:
[CI.md](https://github.com/Tracer-Cloud/opensre/blob/main/CI.md).

## Greptile (AI review)

OpenSRE uses [Greptile](https://greptile.com) for automated review. Opening or
reopening a pull request posts a reminder comment. Treat Greptile as a human
gate: aim for **5/5** before asking a maintainer to merge.

Trigger a review with a pull request comment:

```text theme={null}
@greptile review
```

Reviews typically take 5–10 minutes (sometimes longer). Address the feedback,
resolve threads you have fixed, then comment `@greptile review` again until you
reach **5/5** with no open threads.

Optional: the [greploop skill](https://skills.sh/greptileai/skills/greploop)
can run that loop for you.

Treat Greptile comments like normal review comments. Reply and leave a thread
open only when you need a human decision.

## CI

Required checks must be green before merge. The branch-protection aggregator is
**CI Gate** (quality and unit tests). Some paths also run Interactive Shell Live
checks; those must pass when they are required for your change.

If CI is red, fix the branch before requesting another Greptile or maintainer
pass. Do not open a test-only or CI-only pull request solely to chase failures
that are already red on `main`, unless a maintainer requested that work — see
[CONTRIBUTING.md](https://github.com/Tracer-Cloud/opensre/blob/main/CONTRIBUTING.md).

## Human review

A maintainer decides when the pull request is ready. Greptile 5/5 and green CI
are necessary signals, not automatic approval to merge.

Maintainers typically review:

* Problem statement and evidence in the pull request body (demo, screenshot, or
  log)
* AI-usage disclosure when you used AI assistance
* Scope (one concern per pull request; avoid unrelated refactors)
* Tests for behavioral changes

Keep the pull request description current when the problem, solution, or
evidence changes. Comments are for discussion; the body is what reviewers
re-read.

For coordination help, ask in Discord
[#contribute](https://discord.gg/opensre).

## Improving a pull request during review

1. Treat Greptile and maintainer comments as the action list.
2. Push fixes; update the pull request description when the story or evidence
   changes.
3. Resolve threads you have addressed.
4. Re-run `@greptile review` only after the branch and description are current.
5. Keep discussion on the pull request when possible. Use Discord when you need
   maintainer coordination or believe automation is stuck.

## If progress stalls

* Greptile can take several minutes; do not spam `@greptile review`.
* If CI is pending, wait for the next green run.
* If the pull request is behind `main`, update the branch (or ask a
  maintainer), then wait for CI again.
* If a maintainer is actively editing the branch, let them finish before
  pushing competing commits.

If you remain blocked after CI is green and Greptile is 5/5, ping
[#contribute](https://discord.gg/opensre) with the pull request link and what
you are waiting on.