Skip to main content
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 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. Local checks before you push: CI.md.

Greptile (AI review)

OpenSRE uses Greptile 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:
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 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.

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.

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 with the pull request link and what you are waiting on.