Skip to main content
Otto doesn’t stop at opening a pull request. When someone leaves a review comment on a PR Otto opened, Otto:
  1. Reads the feedback and works out the question or request.
  2. Makes the change, or adds a clarifying code comment.
  3. Pushes a new commit to the PR.
  4. Replies inline with what changed and why.

​
Example

Otto replying to a review comment on its own pull request Here a reviewer asked whether execution needed an early return. Otto explained why execution must continue (to set flags and store IDs), then added a code comment in a follow-up commit to prevent future confusion.

​
What Otto handles well

  • Questions about logic: why something was implemented a certain way, with references to the code.
  • Code improvements: null checks, validation, early returns, extracting helpers, off-by-one fixes.
  • Conventions: naming, types, and patterns used elsewhere in the codebase.
  • Bug fixes: edge cases, wrong error codes, race conditions.

​
Getting the best results

  • Be specific. “Validate the email with the existing isEmail helper” beats “add validation”.
  • One topic per comment. Split complex feedback into separate comments.
  • Use suggestions. Otto applies GitHub suggested changes directly.
  • Ask why. Otto can explain its choices.
For large changes, such as an architectural refactor or a new feature, create a new ticket instead. The lifecycle handles substantial work better than review comments.