Pull Request Feedback

Grit-generated pull requests are not static: you can interact with them like any other pull request. You can comment on them, request changes, and approve them. Grit will update the pull request as you interact with it.

Grit will respond to any PR comment you prefix with @gritagent. Feedback can be provided through line-level comments or code suggestions. Grit will automatically apply your feedback to the codebase.

When Grit begins processing your feedback, it will react to each feedback comment with an 👀 emoji. Once it has processed the feedback, Grit will post a comment summarizing the changes made.

See an example of different comments here and Grit's changes here.

If a pull request is part of an ongoing migration, Grit will aggregate feedback across all pull requests in the migration on the "Feedback" tab of the migration dashboard. This gives migration owners a single place to review all developer feedback across repositories.

As a migration owner, you can choose to "promote" a comment to teach Grit that it should be applied to all pull requests in the migration. All open pull requests will be automatically updated to incorporate the feedback, and the feedback will also be used for future pull requests (but pull requests that were already merged will not be changed).

In addition to providing feedback through comments, you can also make manual edits to the pull request. Just push your changes to the branch—this won't affect Grit's ability to make changes to the codebase.

When a non-Grit commit is pushed to the branch, Grit will "pause" its work on the pull request to avoid conflicts with your changes. You can comment /grit continue to transfer the pull request back to Grit's control.

Any comments left on the pull request will be processed by Grit once it regains control.

Grit does not aim for real-time feedback. This is because all code modifications are done in ephemeral environments and tested before being committed. Instead, Grit batches up feedback and revised commits might take a few minutes to appear.

Once Grit has finished processing the feedback, it will post a comment on the pull request confirming it has incorporated the feedback and should be ready for another review.

• Grit works best if you batch up your feedback and provide it all at once. You should typically provide a full review, then come back to re-review Grit has incorporated your feedback. Treat Grit more like a coworker than a robot.
• Try to be precise with your feedback. Grit has context from other files, but significantly benefits from precise code suggestions.
• Grit will automatically make changes to other parts of the code if necessary. For example, if you request a change to a function signature, Grit will update all calls to that function—you don't need to request changes to each call site.
• Keep in mind that many of the changes Grit makes are required to ensure static analysis and unit tests pass. If you don't like a change Grit made, it is often helpful to suggest an alternative resolution.
• It is fine to check out the pull request locally and make your own changes. Grit will seamlessly incorporate your changes and will never overwrite your work.

In addition to the natural language feedback, Grit also supports precise slash commands to take specific actions.

When Grit has paused work on a pull request (to allow developer edits), you can use /grit continue to transfer the pull request back to Grit's control.

Rebase the pull request onto the base branch. Grit will automatically attempt to resolve any merge conflicts and push the changes to the pull request.

Create a new autoreview rule based on the comment contents. This should be used as an inline comment on a specific line of code.

If Grit fails to flag an issue with an existing rule, you can comment /grit report <url> on the pull request to improve the Grit AI. This will attach the line comment to the linked rule.