Otto/Docs
← Otto

Ticket to PR

This page describes Otto Builder, Otto's ticket-driven workflows that work from Linear or Jira tickets. It is separate from Otto Detective, the pull request reviewer, which never commits, pushes, or merges. Start with the Introduction for Otto Detective.

The most common use case for Otto: automatically converting Linear tickets into working pull requests.

How It Works

When you move a ticket to "In Progress", Otto:

  1. Reads the ticket — Parses the title, description, and any comments
  2. Clarifies requirements — Posts questions if anything is unclear
  3. Creates a plan — Outlines the implementation approach
  4. Writes code — Generates the necessary changes
  5. Opens a PR — Creates a pull request linked to the ticket

Best Practices

Write Clear Tickets

Otto works best with well-defined tickets:

## Add user avatar upload

**Acceptance Criteria:**

- User can upload JPG/PNG images up to 5MB
- Images are resized to 200x200px
- Stored in S3 bucket `user-avatars`
- Display on profile page

**Technical Notes:**

- Use existing S3 service in `libs/storage`
- Add new endpoint: POST /api/users/avatar

Include Technical Context

If your ticket involves specific patterns or constraints, include them:

  • Which files/modules to modify
  • API conventions to follow
  • Testing requirements
  • Dependencies to use (or avoid)

Use Labels

Set up triggers based on labels for more control:

  • otto:implement — Full implementation
  • otto:plan-only — Just create a plan, don't code
  • otto:bug-fix — Focus on fixing a specific issue

Example

Here's a real example of Otto turning a ticket into a PR:

Linear Ticket:

Add pagination to the users list endpoint. Should support page and limit query params with a max limit of 100.

Otto's PR:

  • Added PaginationDto with validation
  • Updated UsersController with query params
  • Modified UsersService to support pagination
  • Added tests for edge cases
  • Updated API documentation

Limitations

Otto works best when:

  • Requirements are clear and specific
  • The codebase has consistent patterns
  • Changes are scoped to a few files

Consider breaking large features into smaller tickets for better results.